Implementing an Effective Security Operations Centre

Nowadays every organization is in the process of implementing a Security Operations Centre (SOC) in order to streamline their internal information security operations. Unfortunately, most organizations in Pakistan are not yet ready for implementing a SOC that can give them a better ROI due to variety of reasons. Some of those reasons I want to highlight in this blog post so that organizations that are in the process of either launching an RFP for SIEM or are in the process of evaluating vendors can have an idea what pre-requisites are needed.

Security Information and Event Management (SIEM) is a primary component of SOC. Many other functions such as incident handling and response, incident detection and analysis, threat modelling and attack vector analysis revolve around the outputs generated through SIEM. SIEM solutions such as QRadar works with logs and network flows in order to detect any anomaly or security threats operating within the environment. For logs and network traffic to be continuously feeded to the SIEM solution, a change and configuration management process is a must. Based upon my experience with the organizations here, a lot of them don't have any configuration and change management process (even though majority of these organizations claim they are ISO 27001 certified but that is a story for a different blog post). Without an effective change and configuration management process, logs and network flows can get stopped any second from either a deliberate or unintentional mistake from the network and system administrators. Also, non approved changes in production environment on a daily basis result in generation of a lot of false positives and wastage of valuable time. For example, SOC analyst detects a large number of proxy traffic going through a machine and conclude that a pivot point has been established by an attacker which is exfiltering all the data outside. The SOC analyst generates an incident report of the highest degree (due to the nature of the threat) only to find out that the systems team were testing a new proxy server in production and the information was not communicated to the SOC analysts.

The next thing that is required before operating a SIEM solution is to first establish log management. Logs serve as a bread and butter for SIEM and more than half of all the data analysed by SIEM comes through logs from network devices and systems. When an organization do not have a proper log management process in place, it means no logs are stored and analysed by the organization. What this translates to is that when SIEM solution is installed and brought online, the organization don't have any idea what they want to analyse through it. It is true that any professional SIEM solution has lots of built-in rules and detection signatures for common threats such as malware and post scanning, still the most dangerous and hard-to-detect threats are those that are specific to an organization's internal environment. If they don't have any log management process in place, it means they haven't analysed their own threat landscape as yet. Without defining clearly what needs to be monitored, feeding the SIEM with logs and network traffic is only half the story.

Organizations should first establish a proper change and configuration management process. After that, logs should be stored and manually analysed for some time so that they have an idea what sort of threats are commonly encountered in their particular environment. Based upon the threats detected and analysed, they should come up with clear cut use cases to be tested and demonstrated during the PoC. Only then can any organization have an effective SOC providing real security against today's advance threats.