A Cyber Security Operations Centre, or CSOC is increasingly recognized as being an essential part of a defence-in-depth approach to cybersecurity, where multiple layers of security controls permeate the IT landscape providing diverse measures that;
- Identify assets and the risks and threats they are exposed to,
- Protect assets and data from the above,
- Detect threats and attacks,
- Respond to such attacks,
- Recover from attacks.
Key factors when deploying a CSOC
Our experience with building our own CSOC as well as assisting companies in building their internal CSOCs have shown that there are some key factors to consider when planning for and executing a CSOC Services deployment, namely;
- Understand the engagement requirements of a CSOC,
- Have a good view of the device and application landscape (sizing, critical assets),
- Management of third-party resources,
- Stakeholder understanding of the project,
- Understand what a CSOC service will NOT deliver,
- Integrating the CSOC service into existing processes,
- Risk management,
- Start small and scale-up,
- “More” is not “Better” when it comes to the number of use cases deployed.
1. Understand the engagement requirements of a CSOC
There is still a belief in some quarters that security is a black box which can be bought and bolted on. Even security devices which are marketed as being fast and easy to deploy still need to be configured, monitored and maintained by competent resources.
A CSOC is a good example of how the quality of the service will be reflected by the level of business engagement in the deployment project. The strength of the relationship between the business and the CSOC service provider (regardless of whether the CSOC is provided by an MSSP or an in-house team) is key. Understanding this at the outset of a CSOC implementation pays dividends not only in the project but throughout the subsequent CSOC lifetime.
In order to monitor devices, their logs must be identified, prioritized against asset risk levels and integrated into a SIEM (Security Incident and Event Management) platform. SIEM rules run against the incoming logs to look for signs of security incidents, which the CSOC team will then react to.
If you consider the scope of “log sources” in your organization, these will include servers, firewalls, virtual infrastructure, active directory, applications, databases and many more. Each one is a potential target for malicious actors, seeking to exploit a vulnerability within your environment in order to visit some degree of harm to your business and reputation.
In order to analyze these logs, we must first find all of them. This first task often presents a significant challenge to the business as technical resources must provide the necessary inventory.
The business is also responsible for making sure each log source is configured to forward the logs to the SIEM for processing.
Finally, knowledgeable resources will also be called upon to help tune the SIEM rules. Tuning is essential to eliminate false positive alerts and to ensure the rules are tailored to the unique needs of the business. This requires input from those who can provide real-life scenarios to input into the tuning process
As you can see, the level of engagement from the business must not be underestimated, but an investment of effort at this stage will result in fewer project delays and a higher quality service.
2. Have a good view of the device and application landscape (sizing, critical assets)
There is an old adage that a device can only be managed if you know that it exists. Nowhere is this truer than in the case of a CSOC.
Keeping point number 1 in mind, the first task of a CSOC project is to establish the scope of devices that will be onboarded. What type are they, where are they, how many are there etc. The dream for any MSSP is to be shown a mature and up-to-date CMDB, which provides an immediate, accurate view of the devices to be integrated into the SIEM. Sadly, this rarely happens and a lot of effort must be put into gathering inventory information from diverse sources.
The launch of a CSOC project is often a catalyst to reopen discussions around that CMDB project which keeps getting postponed. If only we had a system which could provide us with an up-to-date asset inventory.
If you do have such a CMDB, you can congratulate yourself knowing that you are in the minority and that the first steps in your CSOC project should go pretty smoothly.
For better or worse, it is possible that the world’s most popular CMDB is Microsoft Excel. For those starting with an empty spreadsheet, at the very least, your new IT asset inventory should record details such as asset name, id, type (e.g. firewall, application or server), technology (e.g. Windows or Cisco), version, IP address and location.
Other projects will certainly benefit from this type of inventory, so the aim should be to move away from taking snapshots of asset scope but to industrialize the maintenance of the inventory. Maybe, at some time in the future, that CMDB will become a reality.
3. Management of third-party resources
The days when a business held all of their IT infrastructures under their own roof, managed by their own resources are long gone for many businesses. The need for rapid flexibility and scalability has resulted in more third-party partnerships to address IT hosting and management.
More recently there has been a rush towards the cloud, which has commoditized IT consumption, where CPU and storage are viewed as an abstraction from the underlying hardware.
These paradigm shifts have added complexity to both the CSOC implementation and subsequent CSOC services.
An IT Management Business Partner needs to be engaged as early as possible to ensure their commitment to log source integration, tuning and post-project activities. You should also think about questions such as; Will your Partner provide you with the log files of the devices he manages for you and what contractual considerations are there?
4. Stakeholder understanding of the CSOC project
As well as managing Third Parties, it is important to ensure that all stakeholders are kept informed as part of a communication strategy. This strategy needs to be driven by C-level engagement to push the message that a CSOC will deliver significant benefits and raise the security posture of the business.
The importance of technical resources with knowledge of the underlying devices has been mentioned above.
Development teams can work with the CSOC to adapt their log files to include content to identify security anomalies in their applications.
The Service Desk is a key part of the chain in the event of a security incident and needs to be trained accordingly.
Unions / Staff Delegations could have questions about the data that is collected and how it is used. The project needs to address all such queries to inform and reassure stakeholders.
Clearly, your new CSOC service has wide-reaching implications across the business and certain diplomacy is required in the communication around the project.
5. Understand what a CSOC service will NOT deliver
“I have a CSOC, but we still had a data leak, how is this possible?”. I have personally heard this lament from a distraught IT professional, struggling with the fallout of a security incident.
This point is linked to the previous one as it relates to understanding what the project is about. Equally important is understanding what a CSOC Service will NOT deliver.
Referring to the introduction above, the defence-in-depth approach to cyber security covers Identify, Protect, Detect, Respond and Recover activities and the cybersecurity maturity of a business can be determined by how well these points have been addressed. Whilst a CSOC service is a valuable component of cybersecurity measures, it does not address all of the points.
You can consider a CSOC service as control which provides Detection capabilities (and in some instances can provide some Respond capabilities). It is like a fire alarm, but it is not a sprinkler or fire suppression system. Our articles about How to React to a Cyber Incident? and Cyber crisis management in 4 steps provide some inspiration for how to address the Respond and Recover phases.
Businesses must therefore take a holistic approach to cybersecurity and consider what measures need to be introduced alongside a CSOC service.
6. Integrating the CSOC service into existing processes
From the points above it is clear that a CSOC service is not a black box and it does not exist in isolation.
The SIEM ingests log files from sources across the business, but this is a constantly changing landscape and a moving target is harder to hit. Change management procedures should be updated to include steps to update asset inventories when relevant changes (asset addition, decommission or upgrades) take place.
7. Risk management
The followings are real scenarios which popped up during CSOC implementation projects:
- An ancient PC running Windows XP runs a key application that nobody knows how to administer since that old guy left 10 years ago.
- A Data Centre project has been delayed several times, but it is expected to start soon (we hope). The third-party responsible for the DC does not want to invest time in onboarding the servers in the DC until after the move.
- Part of the business has been sold and a 6-month disentanglement project has started to separate servers and other infrastructure which are part of the deal. Care must be taken not to integrate these devices into the CSOC.
- The business has completed a Cloud Migration POC. It is possible that a huge migration to the cloud will be green-lit.
Each of the above present risks that need to be addressed as part of the project.
A risk-based approach must be used when deciding which devices will NOT have their logs integrated into the SIEM. Even delaying integration can expose the business to risk.
Such decisions go above the project manager’s level of responsibility and IT Risk Management needs to be advised of all such potential exceptions so that they can make informed decisions.
8. Start small and scale-up
It helps imagine the high-level goal of a CSOC service as comprising a chain of activities. Timely collection of log sources via a secure channel, which feeds a SIEM, where use cases are triggered, alerts consolidated into security incidents via triage and then forwarded as necessary for remediation.
Establishing this chain can be done with just one log source sending files to the SIEM which has one rule running against the file. It does not make sense to focus efforts on onboarding all the log sources in scope and only then consider use cases.
A POC can work out the kinks with the log integration process and make sure that all participants are comfortable with the workflow (and of course during your POC, you can continue completing your log source inventory, so it is ready for the next phase).
A phased approach is also useful in showing value to stakeholders. Once the first alerts are detected, the project has a tangible result that can be communicated to stakeholders.
Phases can be structured based on asset criticality (starting with all security infrastructure such as firewalls) location or site criticality.
9. “More” is not “Better” when it comes to the number of use cases deployed in a CSOC
Experience has shown that some organizations starting their CSOC journey, can get hung up on the number of use cases that are provided “out-of-the-box” by a potential MSSP. In some cases, this may even be criteria for MSSP selection.
Consider for example an MSSP which has deployed CSOC services for an industrial client, who operates SCADA and PCL devices. Large numbers of Use Cases have been developed specifically for these devices and now reside in their use case library. None of these use cases will be of any use to a non-industrial organization that does not operate these kinds of devices.
So, if an MSSP declares during pre-sales that they have 400 use cases ready to go, it is wise to ask for more information. Focus on the value of each use case that is proposed and understand what scope there is for adding new use cases during the life of the service.
Did you like the article? Let us know!
