Pierluigi Paganini
January 28, 2017
Now that we have gotten over from new year’s greetings– let’s get to the basics to refresh as what is required in terms of achieving maturity within your organisations. There is no doubt that this year will bring more sophisticated & coordinated attacks aimed specifically towards the supply chain. Organisations must integrate the concept of business-driven security where security is seen as business enabler rather than operational hindrance. The investment from preventive measures need to move swiftly towards pre-empted and intelligence driven response.
In the journey towards business-driven security one of the niche weapon (if we are allowed to say this) is the roadmap to Advanced Security Operations Centre (ASOC).
Most large organisations nowadays have some level of security monitoring for their networks; even SME’s have security staff although, they tend to be IT Operations staff wearing two hats. If you are managing a Security Operations Centre or are a board member considering their security organisation, there are a few fundamental questions that you must ask yourself.
These are the sort of questions which will generate some of the answers you are looking to drive the Advanced Security Operations Centre program.
So just what is an ASOC? Is it just a marketing term to get organisations to buy more equipment or is it more of a shift in the way we do our day to day business and Incident Response? I guess for us it is one’s understanding of the difference between a SOC and an ASOC.
A SOC is designed to detect and respond to threats against a network. Put a couple of IDS boxes and Logging/SIEM in place with staff to monitor it and you have a SOC. An Advanced Security Operations Centre is more of a program where every piece of the defence of the organisations networks is reviewed, understood and proactive appropriate controls, procedures, training (hunting capability) and management are put in place to protect an organisation. In fact it is a whole operational security life cycle for an organisation.
Another term which has been labeled against an ‘ASOC’ is that of an Intelligence Driven SOC. This is mainly because of the interpretation of Intelligence Analysts and use of the information gained to assist with their SOC program. Another popular interpretation is that all their Security Infrastructure is integrated and the SOC is taking a proactive approach to their security. These statements are partially correct, but they don’t form the whole picture. This blog aims to pull all of the pieces together into one (hopefully) holistic view (bed time story book for the new year )
So let’s take a look at an ASOC program which will give us our new build.
The key to an ASOC is understanding both the Business Requirements (which include regulatory considerations), and the Business Risk. These two elements drive everything else within an ASOC program. Once the Business issues have been identified, the Mission for the ASOC can be drafted which will frame all of the other activities which will drive the program.
Next we have to identify the assets we are looking to protect. Whilst a portion of this will have been identified in the Business Risk assessment we are now looking at exactly where we have to place our detection capability. In most cases this is going to involve some level of IDS/IPS or Full Packet Capture (FPC) at the network Gateway(s) (preferably on the inside of the network – although an additional feed from the outside is desirable to identify what threats are “knocking on the door”) and at pinch points within our Enterprise network. We should also identify the log sources and Netflow required for detection Use Cases.
Having identified the technical detection capabilities which are required to initialise a monitoring capability the next step is putting the “Advanced” into the Advanced Security Operations Centre. This is done by taking our Business Risk and Requirements and using them to define a Threat Centric approach to our Business Security Monitoring. To do so we must:
Whilst we covered off Use Cases in an earlier blog post (which gave the individual requirements to build your Use Case) we will focus here on the Library itself.
Building Use Case Library enables us to identify the required data sources. This may sound trivial and be viewed as a typical requirement for building any SOC however, in taking a view of the entire library we are building, it enables us to identify where we have weaknesses in our detection capability (and as such where we should invest in new equipment or controls). In the example below we can see that Use Case 4 is capable of being deployed with all required data sources available, however to deploy Use Case 3 we require DHCP and VPN logs neither of which is available to the Security Operations Centre at this time. Use Cases 1 and 2 also have a requirement for DHCP and VPN logs but have additional detection capabilities and whilst not ideal can be deployed without DHCP and VPN Logs. Mapping out all of the Use Cases in this way will identify to Management just where our detection capability is compromised and what must be implemented/purchased to resolve these issues.
Having built the Library and now having alerts flow into the ASOC we must turn to our staffing and this is by far the most important differentiator between a SOC and an ASOC. Typically SOC’s are reactive in their posture whereas ASOC’s are actively looking to develop their detection and hunting capability at all times. To do this a number of traditional SOC roles are utilised but with an addition set of staff and hunters:
Whilst all of these roles do not have to be deployed to give us a greater increase in our detection and response capability, the more that are, the better the Advanced Security Operations Centre service will be. For instance Malware and Forensic Analysis could be outsourced whilst keeping the Content Engineers and Threat Intelligence analysts as an internal resource (focused on the specific threats to our organisation). As to when to hire these individuals that would be established in the Target Operating Model (TOM).
The TOM acts as a visual representation of an organisations ASOC and its continuing design decisions. The focus of the TOM is upon the day to day structure of the Advanced Security Operations Centre, how it is managed and governed. It acts as a roadmap for the development of the services as it is gapped at (typically) 6 months, 12 months, 18 months and 24 months with key development aims mapped out over the months and years. Portions of the TOM include:
Technology is a defining factor in any Security Operations Centre but to take this all together and deliver an Advanced package we must look at working smarter, and by that delivering all our tools into “One Single Pane of Glass”. To do so we would use an Incident Management tool which will pull all of our Alert and Incident Information into one centralised location (allowing a global view of the ASOC program (depending on the User Access rights)). Using a centralised tool also allows us to create Incident Response Procedures aligned against the detection rules (as part of our defined Use Cases) which will automatically be added to a new Incident for our analysts to follow. The other advantages of a centralised IM tool are:
A word of warning though; No IM is disastrous, but a badly managed IM is even worse! Make sure that when planning your Use Cases that you identify just how many “typical” Incidents are expected. Implementing an IM which replicates every single alert you have is a recipe for failure (and an expensive one at that). Plan your ASOC and hire new staff as is required for your Use Cases and TOM.
However no single tool is ever going to be our “Silver Bullet” and even if it was we still have to make sure that our staff will utilise it in the manner that we as managers are expecting. Which brings us onto our Policies and Procedures. Now just asking one of your technical staff to write a procedure will make their face go ashen “ OH Paperwork!!!!”. To enable our ASOC to work in a standard and repeatable fashion we must lay out our Standard Operating Procedures which cover everything from turning on the lights in the morning to procedures for Malware Analysis and Forensics. Having these documents pre-produced will allow the ASOC staff to function more effectively and in a targeted fashion to the perceived threats to the organisation. This will also allow smooth on-boarding of new team members and harmonisation among staff with different skillsets and experience. The requirement date for production of these documents can also be aligned in the TOM.
Next we have to look into constantly improving our ASOC and the results that are being given to the company. Metrics play a large part in an ASOC (which any manager or C Level executive will be glad to hear!). Peter Drucker once wrote “What’s measured improves” and this is entirely true of an ASOC. In an age where the one metric everyone wants to know “Have my systems been compromised? Yes/No” you can bet that there are going to be a lot more requests for data if the answer is yes! And rest assured that the answer is always yes!
Just before we get into the sort of things we would look to add to any ASOC Metrics program lets have a look at why we need good metrics:
And the best bit about all of this……. When you require investment for future enhancements in your Security Program you have all of your historical evidence to back it up.
Below are the main subsections for a Metrics program you would require with a few of the typical metric types included:
The above are just a little introduction to what Metrics would be required as part of an ASOC program (we will delve further into this in a later blog post).
And that is your basic introduction to an ASOC (or at least what we can fit into a Blog post!). We will dig into this subject in greater depth over our forthcoming book. https://www.amazon.co.uk/d/Books/Advanced-Cyber-Security-Intelligence-Corporate/1118997646 ( Dave Gray is the contributing author around threat intelligence and use cases framework). Please remember that Planning out your ASOC build is crucial. To quote an old RAF phrase “Prior Planning Prevents P*ss Poor Performance”.
Azeem Aleem Director RSA Advanced Cyber Defence Practice EMEA
An experienced information security executive with over 15 years of practitioner experience in cyber defense technologies, security operations, counter threat intelligence, data analytics and behavioral classification of cyber criminal. As a subject matter expert, he has made frequent appearance on regional television and radio programs as an expert on cyber threats. A published book author and academic criminologist, he has also authored several periodical on advanced security threats in peer-reviewed journals and security magazines. He is an eminent plenary conference guest speaker both at the national and international level.
Dave Gray: Senior Consultant RSA Advanced Cyber Defence Practice EMEA
David has been in the security business all his adult life having started in the Royal Air Force as his first job. He has worked in the cyber security field for over 10 years now in various cyber defence positions including Network, Malware and Forensic Analysis before leading teams himself.
He has co-developed an open framework for implementing Use Cases into any Security Operations Centre and spoken at a number of International Security Conferences including RSAC and SANS on various cyber-related security topics. David currently works as a Team Leader for RSA ACD deploying security programs and Advanced SOC/CIRC designs to customers in EMEA.
[adrotate banner=”9″]
(Security Affairs – Advanced Security Operations Centre, cyber security)
