Introduction
Security Operation Centre (SOC) comes in different forms (e.g. In-House, Outsourced, Hybrid etc) and sizes, depending on multiple factors such as the objectives and functions that the SOC is meant to serve, as well as the intended scale of monitoring. However, in almost all SOCs, there will always be a SIEM, which basically acts as the brain of the SOC to pick up anomalies by correlating and performing sense-making on the information coming in from various packet and log sources. More than often, the efficiency of your SOC in being able to detect potential breaches in a timely manner, depends very much on the SIEM itself, which includes from having the correct sizing and configuration, being integrated with the relevant data sources, to having the right Use Cases deployed, among others. In this post, we will be focusing on the strategy to plan and develop Use Cases that will lead to effective monitoring and detection in your SOC.
Prioritise your Use Case Development by Road-mapping
When you are first starting out on your SOC journey, there will be many Use Cases which may come to mind that would cater to different threat scenarios. Most of the SOCs would typically make use of the Out-Of-The-Box (OOTB) Use Cases that are available as a start, however, this will not be sufficient in the long run. Hence, there is a need to also develop your own Use Cases on top of the OOTB ones. The fact is that Use Case development is a lengthy and on-going process, from identifying the problem statement to finetuning the Use Cases, and also coupled with the fact that the threat landscape is constantly evolving. Therefore, it is always important to be able to prioritise which Use Cases to be developed first and one of the best ways to do so, is to come up with a roadmap.
When it comes to road-mapping for your Use Case development, there are many good open-source references available, such as the MITRE ATT&CK Framework and THE VERIS Framework, which are useful resources to aid you in your roadmap planning, further information can be found in the following URLs - MITRE ATT&CK https://attack.mitre.org/, THE VERIS http://veriscommunity.net/. However, it is important to note that while such frameworks form good references, they should not be taken wholesale when it comes to planning for your organisation’s Use Case development roadmap, reason being all organisations are unique and therefore not all areas are applicable. Prior to planning for the roadmap, it will be worthwhile to first perform a Priority Analysis, where you can identify the priority areas in which the Use Cases should be focused upon, based on factors such as the following:
- Existing threat profile including top known threats,
- Critical Assets and Services (note: It is extremely important for an organisation to have in place a well-defined methodology to regularly and systematically identify Critical Assets and Services as the outputs from such identification exercises are integral to many other parts of your security operations e.g. from deciding on the level of monitoring of an asset to assigning the appropriate severity level to an incident.)
- Critical Impact Areas to the organisation e.g. Financial, Reputation, Regulatory etc.
With the Priority Analysis being performed, you will then be able to identify which are your “Crown Jewels” and prioritise the protection efforts by developing the relevant Use Cases around them.
The Development Lifecycle
Once the priority areas have been identified, the next step will be to brainstorm for relevant Use Cases in these areas, before developing and finally deploying them into the SIEM. The following summarises the phases in a typical Use Case development lifecycle:
- Define Problem Statement. This highlights the “problem” that you wish to solve (i.e. the threat that you wish to detect) by having the Use Case, and give rises to the objective of the Use Case which you are planning to develop. It is important to note that in planning which Use Case to be developed, the relevancy of a Use Case should not be determined solely based on presence of indicators from the past logs of the environment, because it does not mean that an incident (e.g. breach) that have not happened before will not occur in the future (Refer to the Priority Analysis explained in the previous section for recap on how to identify relevant Use Cases).
- Develop High Level Logic. Once the objective of the Use Case is clear, the next step will be to develop the high-level logic of the Use Case using pseudo code. This includes identifying the necessary parameters such as the length of the “view” or “window” and the number of counts required to trigger the Use Case. Try to avoid focusing too much on the actual syntax at this stage as this may cloud your thinking and increase the chances of introducing errors into your logic design.
- Identify Data Requirements. Identify the packet and/ or log sources that are required as inputs into the Use Case and check their availability in the production environment.
- Check Live Resource or Internal Library. Based on the high-level logic developed, always try to look for similar and existing Use Cases that are available in the Live Resource (more information at: https://community.rsa.com/docs/DOC-79978), community platforms or your own internal Use Case library, instead of developing them from scratch, as this would help to potentially minimize the efforts on development and at the same time reduce chances of human errors.
- Development. Proceed to develop the Use Case in syntax form by either making modifications from existing references or develop from scratch if there are no other alternatives.
- Test & Deploy. Deploy the Use Case in a test or staging environment where possible, and simulate the threat scenario which the Use Case is intended to detect to confirm that the Use Case is functioning correctly, before proceeding to deploy it in the production environment. Note that there is an option in NetWitness to deploy the Use Case as a Trial Rule, more information can be found at: https://community.rsa.com/docs/DOC-78667.
- Monitor False Positive & False Negative Rates. Once the rule has been successfully deployed into the SIEM, set up the necessary metrics to monitor the False Positive and False Negative rates.
- A high False Positive rate is likely to take a toll on the SOC operations in the long run, as unnecessary human resources and efforts would be spent on triaging all the false positives.
- Do note that while False Positives can be determined following triage, it is much more challenging to determine and obtain an accurate picture of the False Negative rate, as this is only possible when you happened to learn of an actual breach and where the relevant Use Case failed to trigger in your environment i.e. you do not know what you do not know. In many instances, breaches could go undetected for a prolonged period of time, hence making False Negative rate an extremely difficult metric to be measured. Therefore, it is important to properly test out the Use Case where possible, following initial deployment.
- Finetune. Now, should you stop yourself from deploying a particular Use Case for fear of introducing a potentially high False Positive rate? We all know that high false positive rates are one of the nightmares for an analyst, however, we should not be stopping ourselves from deploying a particular Use Case into the environment simply because of this, reason being the Use Case serves to exist in the first place because of the “problem” that you need to solve (as defined in your Problem Statement). Rather, we should look to deploy, monitor and fine tune the Use Case to reduce the False Positive rate over time. At this point, we have to caution that this is not a one-time process and may require several iterations of review and finetuning over time to eventually stabilise the False Positive rate to an acceptable level.
- Regular Review. Again, as the threat landscape evolves constantly, we should look to put in place a process to conduct regular reviews of the existing Use Cases, finetune or even retire them if they are no longer relevant, in order to maintain the overall detection efficiency of the SIEM.
Playbook
Now that the Use Case has been deployed into the environment, what is the next step? While the monitoring and detection part of the cycle has been taken care of, it is equally important to also ensure that we have a robust incident response mechanism in place. Apart from the Incident Response Framework which spells out the high-level response process, it is recommended to go into the second order of details to put in place the relevant Playbooks, which are step-by-step response procedures with tasks tagged to individual SOC roles and specific to different threat scenarios. As a good practice, such Playbooks should also be tagged to the relevant Use Cases that are deployed in your SOC. The following diagram summarises how we can make use of the playbooks during the Incident Response cycle depending on the maturity level of the SOC:
- Printed Procedures. This is the least mature method to operate the Playbooks and is generally not recommended unless there are no other suitable alternatives.
- Shared Spreadsheet. This is suitable for small scaled or newly set-up SOCs which are not ready to invest in a SIRP or SOAR yet. For each new case, the relevant playbook template can be pulled out and populated onto an excel spreadsheet (or equivalent) and have it deposited into a shared drive available to all the SOC members, where analysts could update the incident response actions that they have taken while the SOC Manager, Incident Handler or Analyst Team Lead could track the status of the open cases through these spreadsheets.
- SIRP. This is basically an Incident Management Platform which allow the analysts to easily apply the relevant playbooks and update the status of the incidents in a centralised platform. As compared to the spreadsheet method, the SIRP allows for a stricter access control in terms of being able to define and enforce different level of permissions across different roles in the platform, as well as the ability to maintain an audit trail.
- SOAR. This Orchestrator provides a greater degree of automation in the incident response as compared to SIRP, which could potentially cut down the response time and increase the overall efficiency of the analysts.
Conclusion
To conclude, there is no one-size-fit-all solution when it comes to developing the Use Cases in your organisation and one of the recommended ways is to define a short-to-medium term roadmap customised to your environment for Use Case development. The roadmap should also be reviewed and revised from time-to-time to ensure that it stays relevant to the constantly evolving threat landscape. In general, your SOC should have adequate coverage (in terms of monitoring, detection and response) across different phases in the Cyber Kill Chain as shown below:
We hope that you find this useful in planning for the Use Cases to be developed in your organisation and happy building!
