Maximizing Effectiveness with Incident Response Platforms

Written by Alex Vakulov.

Over recent years, there has been an escalating number of cyber incidents, with the complexity of these attacks also on the rise. This growing menace has prompted both governments and businesses to place greater emphasis on bolstering their information security.

In light of this, Security Operation Centers (SOCs) have gained a crucial role. However, there is often a misunderstanding, equating SOCs solely with security event management tools, primarily SIEM systems. Some information security experts tend to focus mainly on the detection phase. Not all of us consider the subsequent steps after a security event is classified as a genuine security incident. Even fewer organizations go a step further to develop and implement actionable response plans - playbooks.

The mere collection of events and logging infosec incidents is not enough if there is no follow-up analysis and response. It simply does not add value. To enhance the fight against cyber intruders and expedite decision-making, there is a need to automate specific tasks and procedures. It is in this context that Incident Response Platforms (IRPs) come into play.

The Broad Spectrum of IRP Abilities

IRPs provide a suite of capabilities to address challenges information security professionals face. Key features of IRPs include:

• Centralizing IT asset information within a single platform and offering differentiated system access to all relevant parties.
• Automating processes to manage the lifecycle of an IT asset.
• Handling cyber incidents through a "single-window" system, a unified environment for task setting, execution, and monitoring.
• Leveraging various integrations with data enrichment sources.
• Automatically enriching information security incident cards\reports and adjusting response routes as necessary.
• Automating event notifications via a range of mechanisms, including in-app alerts, emails, and instant messaging apps.
• Utilizing various dashboards and reports to monitor key metrics.

Amidst the discussion of IRPs and their pivotal roles, one cannot overlook the influence of cloud technology. Integrating IRP with cloud solutions has brought forth several benefits, including scalability, real-time threat intelligence, and reduced on-premises hardware dependencies. As cyber threats grow in complexity, the elasticity and real-time processing offered by the cloud become essential for adaptive and efficient incident responses. Moreover, cloud-based IRPs enable organizations to integrate seamlessly with various third-party security solutions, amplifying their threat detection and response capabilities.

Unraveling the Complexity of IRP Implementation

However, implementing an Incident Response Platform is not as straightforward as it may seem. It is a comprehensive project that involves several key steps:

• Identifying and automating the processes related to responding to information security incidents. These processes could be based on the lifecycle of an asset (from procurement to decommissioning) or related to vulnerabilities (from detection by a security scanner to remediation).
• Developing information security incident response workflows or playbooks. These are detailed plans outlining what actions to take in various scenarios, such as when malware is detected, an account is compromised, or audit logs overflow.
• Creating data models and exploring integration possibilities. This involves setting up connectors for the various IT systems and information security tools in use.

Furthermore, such projects typically involve a multitude of specialists from diverse fields. For example, when developing connectors and commands that need to be executed automatically, all categories of IT assets must be considered. These range from Windows platforms (including servers and workstations) to various Linux platforms (where differing commands might be used depending on the specific OS and its version), virtual infrastructure, as well as a broad array of active network equipment and information security facilities.

Moreover, each IT asset's licensing policies need to be considered. Depending on the type of license purchased, different functions may be invoked and could operate differently.

Project stages

The roll-out of an Incident Response Platform is often a large-scale project comprising multiple steps. When you begin the IRP implementation largely depends on the state of the company's IT infrastructure and processes. For instance, some businesses might still be in the process of inventorying their IT assets, while others might already have an IRP system in place, with designated personnel for handling standard information security incidents, and only need to automate their playbooks.

Therefore, the scale and timeline of IRP implementation projects can greatly vary from one to another, but they will generally follow the same overarching process. To define the scope of any particular project, at the very least, you will need to understand the company's expectations from the IRP implementation, identify the processes to be automated, and assess the current state of the IT infrastructure.

Crafting the Design Framework

Even if the primary objective of implementing an Incident Response Platform is to automate incident response, it is crucial to first develop processes related to IT assets. If the IRP does not house data on IT assets, it becomes impossible to swiftly enrich incidents with information, and consequently, their accurate prioritization and routing cannot be achieved.

While it is desirable to have well-developed processes related to vulnerabilities, they are not strictly required. This is because these processes can be nearly fully automated using appropriate vulnerability management systems, and the processed data can then be transferred to the IRP system for incident registration or enrichment/enhancement.

The outcome of every stage within the process design phase is comprehensive documentation. This may take the form of flowcharts, tables, and more, outlining independent or interrelated processes. Each process is defined by assigning a responsible person for each step and identifying input and output data, all based on the operating procedures within the organization, procedural notations, and administrative documents. Additionally, this phase also includes the development of metrics and Key Performance Indicators (KPIs).

Technological Conceptualization Stage

As part of the technical design, a data model for the IRP system is developed. This model should identify all the IT systems and information security tools that will interface with the IRP, specifying the categories or types of information they handle (for example, Fully Qualified Domain Name (FQDN), IP addresses, employee email addresses, Common Vulnerability Scoring System (CVSS) ratings, etc.).

Based on this information, a catalog is created containing data to be included in the IT asset profiles (such as details about personnel, hardware, network equipment, information security incidents, etc.) linked to the respective IT systems. This data model plays a critical role in preventing the IRP system from becoming cluttered with unnecessary information.

Once the data model is developed and the scope of integration is understood, several additional steps are undertaken. These include calculating the maximum load on the IRP system, choosing the system vendor, documenting the solution architecture, estimating the necessary resources for implementation, and defining the integration parameters such as protocols, access levels, and the interaction sequence.

The result of the technical design phase is the creation of design documentation. This includes descriptions of the data model, settings needed for IRP system implementation, and potential integration options.

Implementation stage

During the implementation phase, the IRP system is installed, basic settings are configured, and communication is established with external IT systems and information security. In addition, the profiles or "cards" of IT assets, information security incidents, and vulnerabilities (if applicable) are set up.

Leveraging the insights gained from the design phase, workflows are created for the IRP system, taking into account its features, the integrated IT and information security systems, and their specific interaction dynamics.

Based on the expectations from the IRP implementation, the characteristics of the IT infrastructure, and recent incidents identified within the organization, recommendations are made for metrics to be monitored, interactive dashboards, and report templates. Once these elements are agreed upon, the IRP system undergoes testing.

The result of the implementation phase is the successful completion of IRP tests with fully working workflows, integration with data providers and users (external IT and information security systems), as well as the complete set of operational documentation.

Diving into the Learning Phase

Everyone involved in the processes must understand how to use the IRP system, be able to quickly navigate its interface, and comprehend their role within each developed process. This is particularly important for specialists who are part of the incident response team, as the timeliness and effectiveness of their actions play a crucial role. The successful conclusion of this stage is marked by positive employee testing results or successfully executed cyber exercises.

Playbook Automation

Separately, it is worth touching upon playbook automation as it raises many questions when implementing IRP. Essentially, you cannot just take and automate a playbook. The intricacy of implementing an IRP system does not lie so much in deploying a product or creating a flowchart in the interface but rather in developing a comprehensive playbook or, in its absence, thoroughly examining each procedure, testing algorithms, and verifying input and output data.

The first step is to identify the data format that needs to be automated. The playbook can be formalized in a variety of ways: as text, tables, and flowcharts. The manner in which information is provided can vary widely from one organization to another.

Here you can identify the entities that are common across all formats. When detailing playbook parameters, you can generally utilize three types: subject, object, and time attribute. For instance, it is not uncommon to see a procedure that specifies it should be performed "during business hours." But what does this mean specifically for your organization? Is it from 9:00 AM to 6:00 PM, Monday to Friday, or from 8:00 AM to 8:00 PM, seven days a week? It is essential that these entities are uniquely identified and clarified.

Terminology Issues

Eliminating "obvious questions" is crucial. Every organization uses its own terminology. Words like "Information Security Solution" can be interpreted differently, standing for "information security tool" in one context (referring to an independent product such as an antivirus) and "information security system" in another (denoting a collection of protective measures within the Zero Trust model. This disparity becomes even more prominent with highly specialized abbreviations. Therefore, it is essential to ensure that all project participants are speaking the same language.

Moreover, both subjects (everyone mentioned in the playbook) and objects (such as protective equipment, documents, etc.) must have unique designations within the process. If the playbook says that an "employee" is being notified, then it should be the "employee" (and not "user" or "operator") that continues to be referenced throughout the playbook. Unfortunately, context does not always clarify the synonymous nature of terms.

Understanding the Structure of a Playbook

After analyzing the procedures, it is possible to identify questions and errors that repeat from playbook to playbook. These can be avoided by first pinpointing the key parameters essential for automation:

• Procedure identifier
• Procedure name (optional, can also serve as an identifier)
• Person responsible for the execution of the procedure (always only one!)
• Participants involved (optional)
• Procedure duration
• Input data
• Output data
• Action algorithm

Striving to achieve a playbook balance

I am not advocating for integration with all systems in the IT infrastructure and pulling all accessible data into the IRP system. Only the information that is required to solve problems should enter the IRP system.

For instance, the "City" and "Province" field values can be extracted from Active Directory, but these are needed in the IRP only if the company has a geographically distributed IT infrastructure, and these values can influence the inventory or response processes. If not, this information would only clutter the IRP system operator's workspace.

At the same time, if, within the process, you need certain information from a specific IT system, this integration is necessary. Thus, when automating playbooks, a balance is required.

Ensuring Precision in IRP System Parameters

The process of developing parameter descriptions, including the list of input and output data, must be carried out with great attention to detail. A response team member might be able to ask who to send a notification to or call a colleague to get the IP address of their workstation if it was not provided in the application. However, the IRP system operates according to a predefined algorithm, and if it is not fine-tuned, then the processes will not be able to complete correctly.

The same issue applies to output data. A phrase like "Event Analysis Report" might be understandable to someone who has seen or created such a report before, but it is not sufficient for an IRP system. A report in the system requires detailed settings, and for this, you need to have a template or know what data in what format should be included in it.

And the same principle applies to the description of action algorithms. For instance, an operator might use several alternative commands to search for a workstation name (moving on to the next step if one does not work). However, in an IRP system, the result of a command must conform to a previously agreed format (such as upper or lower case, with or without a domain name). This is because different results may necessitate different subsequent processing and condition settings.

To run a playbook in an IRP system, each command must be tested. Just imagine what can happen if an IRP system sends a workstation network isolation request with no option to cancel. When setting up the execution of commands, including using external IT systems, it is necessary to analyze further steps in advance. If it is possible to block network access to a workstation remotely, then how can this access be returned later? Will the capabilities of the IRP system allow this? Should you preconfigure exceptions to close ports, or should you pre-set a timeout that is long enough to get the job done? Or maybe use the integration with another information security tool or develop a procedure for obtaining local/physical access to the target workstation? You must think ahead and plan accordingly.

Conclusion

IRP offers a wealth of capabilities. However, fully leveraging these capabilities requires not just the deployment of another out-of-the-box security solution but substantial preparatory work for system implementation and configuration. At its core, the IRP is a tool. Once an information security manager or the head of the SOC understands what they aim to achieve from the project, this tool can help resolve many issues. The project client will not only reap the necessary benefits but also gain a flexible tool that is cost-effective for addressing future information security challenges.

The desired outcomes to be achieved with the help of IRP, the size of the IT infrastructure, the number of information protection tools engaged in incident response, and the processes existing within the organization all contribute to not just the project implementation timeline but also the depth of automation being developed.

IRP implementation projects are intricate and demand consistent effort, not just from technical specialists inventorying IT infrastructure and configuring connectors but also from methodologists designing the necessary processes with their technical execution in mind.

By choosing the right approach and paying careful attention to all the details, the implementation of an IRP will ultimately enhance the quality of work of information security professionals and reduce the volume of tasks that need to be performed manually.

About the Author

Alex Vakulov is a cybersecurity researcher with over 20 years of experience in virus analysis. Alex has strong malware removal skills. He is writing for numerous security-related publications sharing his security experience.