The process side of things: Four areas of focus your SIEM/SOC efforts should consider

As we have shown in our previous blog posts, it is essential to align your Security Incident and Event Management (SIEM)/Security Operations Center (SOC) project across three dimensions:

• technical architecture
• use case definition and implementation
• as well as processes and organizational structure.

This article is concerned with the latter.

Often, the matters of processes or organizational structures are overlooked in SIEM/SOC implementations. While the use cases and the technical SIEM architecture make up the logic of every SIEM, it’s the processes that make it run in everyday operations. Processes and organizational structures are tightly linked to the SOC. We identified four areas that you should focus on when designing SOC-related processes:

Incident management

This is arguably the most important set of processes to align between your organization and the SOC. The main purpose of a SIEM/SOC is to detect and react to security incidents that are identified based on log information and the respective use cases. Hence, incident management stands at the core of every SOC.

Identifying incidents is key, but it is just as important to get the incident information to the right people in your organization. One crucial element to consider is how to get the incident information into your standard ticket system. Whether you operate the SIEM system yourself or outsource it to a third party: The incident information must be wrapped into a ticket. This often requires the development of a non-standard interface between the SIEM and your default ticket system. You should not take this challenge lightly, as it can be a full-grown software development project that must be considered in change, release, and test management processes.

Change management

Change management is not only important for day-to-day operations but plays an important role in the project phase already. For the initial setup of the technical infrastructure you will be confronted with many necessary and time-critical changes. Here it is important to follow a standardized approach:

• Definition of changes
• Establishing changes in the non-production environment
• Testing changes
• Establishing changes in the production environment
• Monitoring system parameters to ensure that, for example, system load is within the expected range from the testing stage

For day-to-day operations, it is critical to inform your SOC of upcoming changes. Consider your organization is planning the roll-out of a new software version which requires some of your servers to go down for maintenance. If the SOC was not informed of this change, unnecessary incidents would be created. As a preventive measure, the SOC must thus be informed of all planned infrastructure and application changes as well as any emergency changes.

Asset management

As in change management, asset management processes are relevant in both the project phase and the operations phase. Asset management revolves around the central repository for configuration items, the configuration management database (CMDB).

In the project phase, a complete and accurate CMDB is crucial so that all assets are attached to the SIEM. Your organization must ensure that all relevant information is present – especially IP addresses, host names, device types, etc. This way, all assets can be efficiently onboarded with just a few change requests for the different asset types. If you do not have a full picture of your IT assets, the missing parts must be attached as soon as their absence becomes apparent which leads to:

• Incomplete monitoring until everything is onboarded
• Multiple unnecessary changes
• Possibly higher costs by the SOC and/or your IT service provider
• Increased workload on internal staff

After all IT assets are attached to the SIEM, the CMDB serves as the foundation for the onboarding of new assets but also the removal of decommissioned assets.

As mentioned above, unobserved IT assets pose a significant security risk because they offer attackers an opportunity to “fly under the radar.” If there are business or technical reasons for not onboarding a certain asset, the accountable business and IT owners must be presented with the associated risk and formally accept it. Furthermore, during operations the CMDB is used by the SOC to identify threats and decide if an event is really an incident.

Capacity management

Workloads can change substantially over a short period of time and capacity management aims to assure that all necessary resources are available. This includes but is not limited to human and technical resources such as network bandwidth or SIEM processing capabilities and licensing agreements. You must consider this from the get-go. For instance, the amount of log-file data volume per day has to be estimated during the vendor assessment and contract negotiation phase already.

These are the most important core processes that must be aligned, although the list does not end there: Topics such as incident response during out of office hours or the coordination with the business continuity management and disaster recovery planning teams should be considered as well. If you would like to talk about the challenge of process alignment, feel free to get in touch with us.