Introduction
As information security threats evolve, so does the requirement to ensure that your business can continue to protect itself. A security operations function is critical to this; but in a large corporate environment, how do you ensure everyone stays well-versed and up to date on what is almost constant change?
Project deliveries of today require a careful balance between business agility and security and migrations to the cloud considerably widen your attack surface. Lack of visibility is one of the biggest challenges for many security operations centres (SOCs) and your company may be handling thousands of programmes and projects simultaneously, across multiple environments. As such, it’s easy for your security operations teams to be left behind - impairing visibility and reducing their ability to handle threats correctly.
The fundamentals
Think about this for a second. Imagine your business acquires a new property. You could deploy appropriate physical security controls: intruder alarms, CCTV, card readers; every door in the building may have a card reader on it. Now imagine the door access system is linked to your SOC, with every entry and exit through all doors logged.
Without a building schematic or a level of understanding, how can your SOC make an appropriate decision on an event? Of course, you may tell them which doors you are most concerned about, perhaps you’d label them accordingly on the system. But without a reasonable level of understanding, say for example a schematic, your security operations team will struggle to assess the exact level of threat.
Now imagine you are opening new buildings, adding doors to existing locations and running thousands of projects at once. Whilst you can send them all the logs in the world, you can see how an operational security team could easily lose touch - and as a result their effectiveness nosedives.
But that’s why we have threat modelling!
Threat modelling, risk assessments and attack trees do work, particularly to discover and understand security risks and potential outcomes. Methodologies such as STRIDE and PASTA have been around for years and are very much still appropriate, particularly when integrated with more modern frameworks like MITRE ATT&CK. However, threats are changing fast and becoming more dynamic.
Let’s use another scenario: imagine you are rolling out a complex network with multiple tenants. You can quite easily make reasonable assumptions as to how, where, when and why threats can occur as part of an assessment exercise. You can then put relevant controls in place with your security teams to ensure these are monitored.
You may have compliance requirements - for example, what if you see failed login attempts or connectivity to or from a country in which you don’t operate? These examples can be broadly applied to almost any system or network. However, understanding the depth and breadth of an attack requires an understanding of the platform itself, particularly during the investigation phase.
How are IP addresses allocated? Where are the firewalls in relation to the servers? What does that box actually do? This is where an element of ‘contextual awareness’ is required.
Documentation overload
In an ideal world, every project would have a representative from your SOC engaged throughout delivery. Realistically, this is unlikely. So, how do you overcome this challenge? Ensuring appropriate design documentation such as a security operations (SecOps) manual, in conjunction with proactive and reactive risk and threat assessment exercises can ensure a reliable project handover for your SOC.
This ensures that new deployments are monitored correctly and there is a level of knowledge transfer. Compliance may always be checked, but without an inherent understanding of how a system functions and what does and doesn’t seem right, it is unlikely you will be efficiently watching for threats.
As always, there is a balance. Having reams and reams of documentation for every single platform is going to significantly affect your mean-time-to-respond (MTTR). If your teams are having to trawl through paperwork to understand the context around a suspicious event, this is counter-productive!
A SecOps manual should be relatively brief. It should contain the detail around any proactive threat modelling exercises, along with a high-level explanation as to what and how the platform works, as well as the services it provides. High level diagrams including basic networking detail also assist.
There is no ‘one size fits all’ here, so work closely with your SOC on the level of detail required in a SecOps manual. You don’t need to do this for every single manual; just work with the team on a template which can be used by projects across the business, regardless of what they are trying to achieve.
Getting the right level of detail is a challenge and takes time, but when you’ve got it, you’ll really notice a difference in your operational effectiveness - and your analysts will be grateful too! Your SecOps manuals should allow them to react to events realistically and holistically gauge the level of risk ‘on the fly’.
They can also feed directly into your incident response processes. It is imperative if you take this approach, to ensure that SecOps creation and handover is defined a mandatory task during design and transition project phases.
Business as usual
Day-to-day change as part of business as usual, for example also poses inherent challenges for your SOC. Something as simple as connecting two networks together or adding to a server cluster can adversely change the perception of threats. Quite often these smaller changes may not be communicated to operational teams and, before you know it, they are receiving additional data. If this is not processed or understood correctly, valuable information could be lost.
This is where reactive threat assessments come into play, and regular SecOps documentation reviews. The reviews should be completed across impacted teams - the examples above would typically include engagement with your network architects and system admins. The SecOps mentality brings your security teams closer with other operations teams.
A similar common frustration are alerts generated by legitimate, project-based activity. A perfect example is a simple relocation of a network device. Engineers may log into the device using the local administration credentials, inadvertently causing an event that your SOC then need to investigate. Not only is there an importance to understand context and a comprehensive handover, but also communication when change occurs.
Summary
Resource constraints in security are a challenge in most organisations. Taking operational analysts away from their day jobs and engaging them in projects is less than ideal. At the same time, there is a real requirement to ensure your SOC are kept informed of change in your environment.
Threat modelling exercises need to be driven throughout the design, transition and operation phases of a project, with a clear handover available for the SOC - for example in the form of a SecOps manual. In a large organisation, your SOC will potentially be dealing with hundreds, even thousands of events a day, a lot of which is probably noise. Are they understanding the level of risk correctly? Keeping them well versed in project activities should make the process a little easier.
Sufficient contextual awareness and familiarity ensures they can make appropriate decisions on suspicious activity; thus maintaining visibility across the board. Your team can then use their understanding to create correlation rules to detect the likes of advanced persistent threats (APTs), reduce fatigue and free up resources to concentrate on the real risks posed to your organisation.
A contextual understanding even assists with the likes of threat hunting. Don’t forget to schedule regular reviews and complete threat assessments to ensure your SOC keeps up to date with new trends. Providing your SOC with an inherent understanding of the platforms they are protecting, helps them to protect you.
