So You Want to Build a SOC: Foundations for Your Security Operations Team (Part 1)

As security consultants, we go into an extraordinary array of organisations’ security environments, all with very differing levels of maturity. Our clients consistently state a common desire:   “We need a SOC.”

Building a SOC doesn’t present a problem for Cisco’ Security Advisory Services business. We have decades of experience in designing and building and operating SOCs (we literally wrote the book). But, in practice, building a SOC is hard and can take a significant amount of planning and investment to get right. If all you’ve been doing until now is commissioning penetration testing and panicking when incidents arise, you might appreciate a few tips for improving your security operations. Our consultants have identified some of the steps you can take now as you set off down the path to effectively monitoring, detecting and responding to the threats that your organization will doubtless face:

• Understanding an effective Operational Security Team
• Know your Weaknesses
• Document, Document, Document

Understanding an effective Operational Security Team

The best starting point for me is the understanding of an Operational Security team. It may seem like there’s no difference between a SOC and an Operational Security team but I tend to find there is less pressure without the SOC tag, that an Operational Security team can be more agile and if you do it right, you may be able to get closer to both your business and your engineers.

To build an effective Operational Security team, you first need to define some principles. Notably, you need to pick the aspects of operational security that you want to focus on. SOCs are multi-faceted beasts. You need to prepare yourself for the idea that an Operational Security team might not be able to do everything that you’d like it to on day one. As you are starting up your operations program, start with your teams’ existing areas of strength and build a plan for improving those strengths. With each service you intend to offer, define KPIs that you can track. If you want to persuade the senior leadership that the business is ready to operate a SOC, the business case for that investment is always going to look better if you can already demonstrate improvement.

Know Your Weaknesses

Strengths can always be improved but it’s often smarter to delegate your weaknesses. A key aspect to running a successful Operational Security team is knowing your team’s weaknesses. A great example of this is setting principles for how systems should be architected and then allowing platform owners across the business to define how they choose to align with your goals. In the past, a secure organisation needed to develop their own policies and processes for every aspect of security from the ground up. These days, the smart money is spent navigating resources like NIST, the UK and Dutch NCSC, or other national security web sites. Many governments now publish great practical advice covering all manner of security topics. Likewise, learn to value reliable IaaS, PaaS, SaaS providers. In the days leading up to Christmas holidays, Microsoft were able to patch the entire Kubernetes estate for all of their customers against a serious 0-day with minimal disruption. Security responses like this take significant engineering and it’s often more cost-effective to delegate at least some of this to a more experienced provider rather than build your own capability from the tin up.

Document, Document, Document

Whilst these first two steps are important, you might argue that they’re more recommendations on culture than practice. So how can an Operational Security team ensure that they are effective?

In my opinion, the number one requirement is to choose an appropriate tool to document your operational practices. Too many organisations rely on the presence of informal processes to defend them. Moreover, in many cases the definition of policies and processes moves at snail’s pace. If your organisation already has an agreed document management system, then adopt that (it will help you integrate with your users). If you don’t have an existing system, consider using a wiki. A wiki will enable all of the team to contribute, documenting what they’re working on early and often.

The ability of the team to grow is going to be vastly diminished if you can’t provide accurate and concise guidance to junior members of the Operational Security team to help them take on more responsibilities. Better still, I would argue, once you start documenting your practices, you are better able to baseline your expectations for operations.  Your expectations will be clear to the business and your engineers, empowering your engineers to make decisions while also making it clear who is responsible and who is accountable for the outcomes.

I hope these recommendations inspire you to find ways to optimize and evolve your security operations. In my next post on the subject of building a SOC, I’ll explore recommendations about security intelligence and technology.  In the meantime, if you are interested in getting help from experts, please explore our Security Services portfolio.

Share