Security Operations the Final Frontier – Part III

Security Operations, as a capability, was discussed in the first article of this series: Security Operations the Final Frontier. This was a response to media coverage of a other operations in which information was compromised and data assets were stolen - Operation Shady RAT, Operation Aurora and Operation Night Dragon.

We then discussed the technologies that would be required to establish a fully functional Security Operations Centre (SOC) in a follow up article, Security Operations the Final Frontier – Part II. But a successful SOC requires more than just technology.

Since that article was published, another high profile hack was revealed. This time, defence contractor Mitsubishi Heavy Industries was the target. It recently confirmed network information such as IP addresses may have been leaked, but offered no confirmation of any leaks regarding its products or technologies. While all of the events above this took place during the year or so, there are so many more examples that go either undetected, or unreported. The last article in this series is, quite appropriately, a discussion on the operating processes required to establish a robust Security Operations Model (SOM).

There are a number of helpful vendor articles are out there, including a few from analyst firms Gartner and Forester that talk specifically about the processes required to develop a SOC, but not many talk about which processes are required to ensure that the SOC works as a defined organisational unit - or ensure that it is part of an organisation’s Security Operations Model. The organisational security operations model includes the full gamut of people, process and technology.

So what are the processes required to establish and operate a successful SOC? I normally break them down into three layers - Diagnostic Processes, Operational Processes and Governance Processes. For those of us who love the three letter acronyms (TLAs) here is another one; SOM DOG. (Consider this my contribution to the world of information security.) Security Operations Model (SOM) utilizing Diagnostic, Operational and Governance (DOG) Processes.

Level 1:

Diagnostic processes in my experience are the front-line, level-one processes, including:

• Incident Management
• Event Monitoring and Detection
• Intrusion Detection and Prevention Analysis (IDPA)

I would not go into too much detail here, because there is already a lot of good material available that you can access freely - some that I have found useful include the NIST Incident Handling Guide and the Carnegie Mellon Defining Incident Management Processes for CSIRTs: A Work in Progress, guide.

Event Monitoring and Detection is self-explanatory and IDPA has been around forever. I have even seen security managers gloat about how many intrusions their systems blocked; great, excellent, but do you know what got in and more so, what did you do when it got in.

I often hear silence at the end of that conversation, followed by finger pointing and mutterings about the lack of management support and funding. The point here being, we need to step back from the daily grind and think that maybe, if we establish good first-level analytical processes, management of security operations would be a lot easier when disaster strikes.

Level 2:

At level-two are processes supporting the operational management of a SOC. They are linked to level one processes yet are distinct.

• Threat Management
• Access Management and Rights Administration
• Forensics Management

In my view, Threat Management is a process that is really a container process or parent process for other operational processes such as patch management, preventative controls implementation, and anti-virus updates, which ensure infrastructure elements across the enterprise.

Access Management and Rights Administration is a SOC process which ensures that users are appropriately provisioned and de-provisioned. This should further provide for mechanisms whereby access controls lists on critical systems (and more importantly on sensitive file systems) are regularly checked and anomalies managed.

Forensic Management processes start with a live response to an incident and ensure that the areas of Evidence Collection, Analysis and Case Management are appropriately addressed.

Level 3:

Level three is probably the most important level within a SOC and is, in my view, the cornerstone of a security operations model. Governing Security Operations

Governance of security operations ensures that the infrastructure assets of your organization are appropriately managed and that measurable metrics can quantify operational effectiveness. The following metrics are from the Centre for Internet Security (CIS).

For any organisation, the following 10 operational security metrics would be a good starting point for managing information security governance. If your organisation can deliver continuously on these metrics, it will help drive a security operations model and establish the backbone of a security operations centre.

• Number of systems with outstanding patches and vulnerabilities
• Mean time between security incidents
• Mean time to recover from security incidents
• Percentage of systems configured to approved standards
• Percentage of systems patched to policy
• Percentage of systems with anti-virus protection
• Percentage of business applications that underwent risk assessment
• Percentage of business applications that underwent penetration or vulnerability assessment
• Percentage of application code that underwent security assessment
• Number of code reviews prior to production deployment

This is the final instalment of my thoughts on how to establish a security operation centre and security operations model.

Hope it helps. If nothing else, remember SOM DOG.