Part 1: Without clear focus and responsibilities, your SIEM/SOC project is doomed to fail

Companies are increasingly threatened by cyber attacks from inside and outside. While outside attacks from sophisticated APT (advanced persistent threat) groups are the focus of popular media outlets, the inside attacks often make up the majority of security incidents. We experience this in our work every day. The good news is that every attacker leaves traces of their presence inside an infiltrated network, computer, server, and so on. These traces are stored in log files that are produced by any hard- and software asset inside your company network. A SIEM/SOC can detect such attacks in near real time and prevent them before the intruder (internal or external) inflicts any damage.

To deal with the ever-increasing amount of data, companies must adjust their incident management capabilities. It is simply not possible to analyze log files manually. From our experience, the log files of a single core ERP system can range from anything between a couple of gigabytes to multiple terabytes of data per day. This is where a SIEM can help to analyze these log files and draw relevant inferences from them.

But it is just a piece of hard- and software that is useless without skilled individuals behind the technology who analyze the unfiltered incidents the SIEM produces. This is where the SOC comes into play: The Security Operations Center is the organizational unit behind the SIEM that analyzes the incidents as first-, second-, and/or third-level support, depending on the demands of your company.

In order to successfully introduce a SIEM/SOC to your organization, a well-organized project must be set-up with clear responsibilities and focus areas. No matter whether you have an external SIEM/SOC provider or decide to run it inside your organization, we recommend aligning your efforts across these three topics:

Figure 1: Project Focus Areas

Technical Architecture

This is the foundation for your SIEM/SOC, i.e. the basic hard- and software installation. Without this step, no log files can be analyzed and no inferences can be drawn. Key points to consider are:

• Be sure to align with all relevant stakeholders for the set-up of servers and network hardware, e.g. your IT provider, the SIEM/SOC provider, and internal IT and business units.
• It is cumbersome, but essential when you introduce new hardware to the corporate environment.
• Be ready to challenge the data quality inside your CMDB (configuration management database). Without high quality data on all your assets, the setup of the technical architecture fails from the start.

Use case definition and implementation

When the technical architecture is the foundation, use cases incorporate the logic of your SIEM/SOC. Use cases define when incidents should be created, e.g. if a user tries to login on multiple devices at the same time. Key points to consider are:

• A staged approach helps to prioritize your efforts. Basic technical use cases that monitor hardware and operating systems come first, while more challenging application-focused use cases come second.
• For the first stage, start off with the hardware as a baseline. These are quick wins and you should take them. Having the basic logs of hardware and operating systems analyzed in the SIEM goes a long way towards a fully integrated SIEM/SOC.
• For the second application-focused stage, follow a risk-driven approach. It is better to have a couple of good, effective use cases than many that produce many false positives.

Processes and organizational structure

Processes and organizational structures are critical in successfully transferring your project into efficient operations, even if your SIEM/SOC is delivered internally. Key points to consider are:

• Plan the alignment between the SIEM/SOC processes and established corporate processes early on in the project. A SIEM/SOC drives tremendous change in your IT process landscape, such as incident management, change management, and many more of the core ITIL processes.
• Involve all relevant stakeholders when attempting to redesign processes. It is critical that the process owners see the positive change and that they support your efforts.
• Prepare your internal organization for an increased workload after the project is completed. Running a SIEM/SOC requires substantial resources in your IT, Information Security, and business departments.

Get in contact to talk  about anything related to your SIEM use cases.

Based on our diverse project experiences, Capgemini Invent has developed a tested framework for SIEM/SOC projects that helps our clients make their SIEM/SOC project a success. If you are interested in talking to us on any matter related to your SIEM/SOC project, click here to contact us.