Introduction
Understanding an organization’s current incident response (IR) capabilities is vital, as it enables the identification of current strengths and weaknesses. This knowledge is instrumental in formulating future objectives and optimizing allocation of resources.
This analysis will bring forth a model to evaluate the existing IR capabilities by examining the people, processes, and technology dimensions. The result will be organized into a customized matrix, providing an overview of the IR capabilities. Insights derived from this matrix can help in decisions, including technology acquisition, process improvement, training prioritization among other things.
In essence, this document is aimed to highlight the need for a capability review by accomplishing these primary objectives: first, present a structured approach for assessing Incident Response (IR) capabilities; second, and utilize this approach to conduct an evaluation of current IR capabilities as a proof of concept.
Method
This exercise will evaluate current incident response (IR) capability for specific information asset types. IR capability that will be assessed are detection, analysis, containment, and eradication. While asset type that corresponds with these capabilities are identity, endpoint, network, data, apps (along with their respective subtype). Assessment is conducted by evaluating the dimensions of people[1], process, technology (PPT)[2] for each combination of IR capability with specific asset. Afterward a custom matrix, aptly called IR capability matrix was used to map and present the result.
Figure 1 illustrates different levels of measurement for capability, and for this exercise, assessment will be done by looking whether a capability is present. This means either a certain capability exists, or it does not. The quality of the capability, implementation effectiveness and coverage are not considered (but will be highlighted if information is readily available). Future refinements in measurement level can offer a more comprehensive view of our IR capabilities, this will be discussed in key takeaways section.
The assessment of technology dimension involves determining whether currently available solution to the IR team, has a primary function that directly relate with an IR capability. This approach ensures that a capability is not considered available if the IR team cannot access necessary technology or if it is not immediately accessible.
For example, if we were to measure windows defender detection capability on windows endpoint asset, currently this will be marked as exist, because defender for endpoint, whose main function is just that, is readily available for IR team.
In the other hand, if we were to measure containment capability of AWS console, for asset type AWS identity will not be marked as exist. This is because, although it is possible to contain an AWS identity via AWS console, this is not the primary function of the AWS console.
If a primary function of a certain technology is not related to a certain IR capability, but we have developed or acquired add on that made this capability possible, then this will be marked as exist. Using the previous scenario as an example, if a lambda script or an Azure logic apps in sentinel was to exist where the primary function was to perform containment/ eradication of an identity in AWS, this capability then will be marked as exist.
Process dimension is assessed by reviewing currently available processes in company knowledge base. If a process facilitates the execution of a specific Incident Response (IR) capability, then that capability will be classified as present.
The final element of the PPT framework pertains to the people aspect, there are countless way of measuring this aspect can be as complicated as you wanted to be. A suggestion on how to do it, is a one question to IR personnel “how confident are you in doing [IR capability] in [asset type]?”.
Putting all dimensions into a table below and detailing how the evaluation will be conducted.
| IR capability | approach used to evaluate | | |
| Technology | Process | People |
| Detection | A technology solution that capable of automated alerting when a security event related to a specific asset arise is readily available to IR team. | A KB page (guide, playbook, process, standard) exist that relate directly in conducting a certain capability is available to IR team. | one question: how confident are you in doing related capability |
| Analysis | A technology solution that primarily function to provide data in analyzing events from a specific asset surrounding security incident is readily available to IR team. | | |
| Containment & Eradication | A technology solution that primarily function to conduct containment and eradication of a specific asset is readily available to IR team. | |
Table 1 approach used evaluate IR capability
The IR capability matrix was created to map the outcomes of the previous PPT framework assessment. It is modeled after Sounil Yu’s cyber defense matrix. However, while the cyber defense matrix is designed to address the full scope of the NIST Cyber Security Framework (NIST CSF), only certain parts are relevant to incident response capabilities. Therefore, the IR cycle components—detection, analysis, containment, and eradication—will be used as the capability columns in the matrix. The rows will be populated with asset types, which include identity, endpoint, network, data, cloud and applications. The table below will be utilized to map the results of our evaluation.
| Asset | Detection | Analysis | Containment & Eradication |
| Identity | | | |
| Endpoint | | | |
| Network | | | |
| Data | | | |
| Apps | | | |
| Cloud | | |
Table 2 IR capability matrix
Note that the asset column can be as detailed as it needed to be. User can just put cloud, but might also use sub category e.g. IAM, compute, storage, database, management, networking.
Caveats
Detection and analysis in this document are treated as separate entities, unlike in NIST’s computer security incident guide[3] or SANS’s PICERL[4], where they are collectively categorized under one capability. A decision was made to separate detection and analysis into individual column capabilities. This separation acknowledges the heavy reliance of detection on the technology dimension, contrasting with the analysis capability, which depends greatly on the process dimension. The rationale behind this is to ensure a distinct understanding of each capability, as combining them could obscure the true picture of the current capabilities.
[1] There are numerous way to measure this, I aim for the lowest friction.
[2] PPT framework: wayback machine (archive.org).
[3] Computer Security Incident Handling Guide (nist.gov)
[4] 504-incident-response-cycle.pdf (sans.org)
