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.”
My last post on this topic focused on the operational considerations. Now let’s look at what your security operations should consider from a security intelligence and technical perspective, gleaned from Security Advisory Services business and experience in designing and building and operating SOCs.
Protecting Your Perimeter
One problem a nascent Operational Security team will face is tracking the business’ assets. Whilst hopefully your organisation will have some existing asset management capability that you can leverage, at the very least, I would ensure that you can quickly and accurately understand and control your perimeter. In particular, the Operational Security team ought to know who operates the following externally exposed assets and how to reach them in an emergency:
- Internet connection
- DNS
- Web
It’s surprising how many organisations get caught out by incidents related to assets they didn’t know they had when incidents strike!
Then, presuming you know what your assets are, what does it take to keep them safe? This is a place where we at Cisco can quickly help you. At a bare minimum, any Operational Security team must have access to the following defensive tooling capabilities feeding into their alerting system:
- The ability to monitor and filter DNS
- The confidence to stop spending 24x7x365 worrying about mail
- Integration across security products and threat intelligence sources, to accelerate critical security operations functions
- Multi-factor authentication to stop employees being phished
My next recommendation is that the Operational Security team should set up and staff (by rota) an alerts mailbox or list. Alerts should be the lifeblood of your team, informing you of the health or otherwise of your organisation. It’s not uncommon to see alerts come in and for them to be ignored but if you’re not responding to basic alerts then the bad guys will have an immediate advantage.
Managing Alerts
Depending on the cadence and type of alerts that you’re seeing and the defensive tools you use, I recommend at the very minimum an Operational Security team ought to have a Start of Day process. This is a great place for juniors to learn, performing the initial triage and then escalating to more senior colleagues where further action is required. Start of Day processes build muscle memory, requiring that the Operational Security team treat each potential incident seriously. Your team will be better prepared when an alert is ultimately does trigger, indicative of an active threat to your organisation. A good Start of Day procedure should account for both triage and reporting, so encourage the team to record the work in a central tracking system rather so that you’re not reliant on an obscure email thread in a team member’s inbox.
Security Intelligence
For my penultimate piece of advice, I would strongly recommend that you investigate some of the excellent free intelligence resources out there which aim to give insight into the current health of your network. Whether it’s the UK’s CISP platform, Sh0dan or VirusTotal, there’s a good deal of useful threat intelligence that Operational Security team’s ought to be leveraging as part of their work flows.
Aligning Operations for Security
Of course, all of these recommendations naturally lead us to my next piece of advice: How to bring it all together. Too often the Operational Security team, asset management folks and others work for different reporting lines and politics naturally emerge. Here I can honestly say that the best advice is to use the same tools as your developers and ops folks. Leverage your existing asset and change management tools and wherever codify as much of your operational procedure as possible. You don’t need a team of senior developers, but having the ability to understand and write scripting logic, perhaps using PowerShell or bash will help your team scale that much faster. In particular, I’m a big fan of using something like GitHub to store your tools. Any security team (big or small) needs to be able to share both within the team and with the wider organisation. Developing scripts to deal with repetitive tasks and storing them centrally will reduce errors and allow complicated tasks to be broken down and distributed, allowing junior team members to be upskilled and freeing up more senior members of the team to focus on the next fire fight coming your way.
Hopefully the recommendations in this post will prove useful. If you’re doing everything mentioned in this post, you’ve already read the Cisco Press book “Security Operations Center: Building, Operating, and Maintaining your SOC”, and you’re ready to continue your SOC journey, then come speak to Cisco :).
CONNECT WITH US