CISM Incident Tools, Investigation and Containment

This part of CISM domain 4B covers the first half of incident management operations: the tools and techniques that detect and handle incidents, the investigation and evaluation that confirm and scope them, and the methods that contain them. It corresponds to the official outline topics Incident Management Tools and Techniques, Incident Investigation and Evaluation, and Incident Containment Methods, and to the supporting tasks on timely identification of incidents, on investigating and documenting incidents in line with legal and regulatory requirements, and on the incident handling process (SOAR, playbooks, UEBA and containment).

The CISM view is still a manager's view. The information security manager does not tune a correlation rule or image a disk personally; the manager makes sure the organization can see incidents in time, that alerts are validated and investigated consistently, that evidence is handled so it stays usable, that legal requirements shape the investigation, and that containment decisions weigh business impact. Where a choice accepts risk for the business, such as leaving an attacker in place, the manager advises and senior management decides.

Neighbouring material has its own lessons: the incident response plan, classification and testing (4A); the business impact analysis, continuity and disaster recovery (4A); and incident communications, eradication, recovery and post-incident review (the rest of 4B). This lesson stops where containment ends and eradication begins.

A security information and event management (SIEM) system collects events from many sources in one place and applies correlation rules, so an attack whose steps are spread across different systems can be recognised as one incident while there is still time to act. Many attacks look harmless one log at a time: a login from an unusual location, a new local account, a scheduled task, a large file transfer. Seen together, joined by the same user, host or time window, they form a recognisable sequence. Reviewing each system's logs separately, or only periodically, fails twice: it delays detection and never links the pieces.

Each tool sees one layer, and that is why a SIEM sits above them rather than replacing them:

Detection is only as good as its coverage, its timestamps and its tuning. Three conditions decide whether a SIEM or a managed monitoring service actually finds incidents:

• Coverage. A tool cannot alert on events it never receives. If only perimeter devices are monitored, movement between internal servers or misuse of internal accounts is invisible, however sophisticated the analytics. Log sources should be onboarded in order of business criticality, using the asset inventory and classification, rather than whatever is easiest to connect.
• Time synchronization. Investigators rebuild an attacker's path by putting events from different systems in order. If systems keep their own drifting clocks instead of synchronizing to a common time source, events cannot be reliably ordered even when everything was logged.
• Tuning. Generic rules raise alerts on activity that is normal for this organization. When most alerts are false positives, analysts stop reading them and real incidents are lost in the noise (alert fatigue). The fix is to tune rules to the organization's normal activity and known benign patterns, because the cause is rules that do not fit the environment. Remedies that only change how much noise is seen or who handles it leave that cause in place, and filtering by severity alone can hide genuine low-severity signals.

A related trap is closing low-severity alerts one at a time. Several minor alerts about the same account or host in a short period may be a single attack; correlation rules that join related events across sources are what turn them into one meaningful alert.

User and entity behavior analytics (UEBA) learns what is normal for each user, account, host or application and alerts on deviations, which lets it detect insiders and attackers who use valid credentials that signature-based tools and preventive controls accept. A stolen administrator password used during office hours passes authentication, matches no attack signature and may not break any time-of-day rule. What it usually changes is behaviour: systems never accessed before, unusual commands, much larger data volumes, new peer groups.

Preventive controls such as multifactor authentication and role-based access control are not substitutes. A legitimate employee abusing their own access passes both, and so does an attacker who has taken over a session. Behavioural detection is the control that asks whether this authorized activity is normal for this account.

A baseline is only as good as the period it learns from. If UEBA is deployed during abnormal activity, such as a major migration, a year-end close or an incident, the unusual hours and volumes become its idea of normal, and later misuse that looks similar may not be flagged. After such a period the baseline should be reset or relearned. The same applies when roles change substantially. Fixed rules written in advance remain useful, but each catches only the specific pattern it describes, whereas a baseline adapts to each account.

A playbook is a documented, type-specific set of response steps (for phishing, ransomware, a lost device, a compromised account) that turns the incident response plan into consistent, repeatable actions. Without one, two analysts facing the same alert may act in a different order: one contains immediately, another preserves memory and calls the business owner first. A playbook aligns the order and content of actions. It sits beneath the incident response plan and works alongside the classification scheme in 4A rather than standing in for either: the plan sets authority and process, classification sets severity, and the playbook sets the steps for one incident type.

Security orchestration, automation and response (SOAR) platforms run playbook steps automatically across tools, which speeds up response and makes it consistent, but they also repeat any mistake at machine speed. Two management rules follow:

• Automate a proven process. Before a playbook is automated it should be documented, tested and approved as a manual process, so the automation reflects agreed decisions about what happens and who decides. Technical readiness to build the automation is a separate question from whether the process itself is sound enough to automate; automating an unproven process only makes its flaws faster.
• Keep a human decision where errors are costly. Low-risk, predictable work suits full automation. Steps that disrupt critical services, remove data across the organization or carry legal consequences should have an approval step or stay manual.

When automation harms a critical system, the better response usually targets the impact rather than the automation as a whole: add an approval gate for systems designated critical while keeping automation for routine ones. That keeps the speed where errors are cheap and puts judgement where they are expensive, even when the alert on the critical system is genuine.

The first step when an alert or report arrives is to validate it: confirm whether a security incident actually exists and form an initial view of its scope and severity, before containing, escalating or recovering. Most events are not incidents. Acting on an unconfirmed report, whether by containing, escalating or recovering, can cause disruption, lose evidence or create false alarms that erode trust in the process.

Validation is not the same as finding a plausible excuse. If an alert coincides with an approved change, the analyst still checks that the observed activity matches what the change allows in every respect the change defines. A change ticket explains an alert only when the facts line up with it; an attacker can hide behind authorized activity, and a misconfigured legitimate job can also be a security incident. Once the alert is confirmed as an incident, it is classified and handled under the plan and the matching playbook.

Investigation establishes the full scope of an incident (every affected system, account, data set and attacker foothold) so that containment and eradication are complete rather than partial. Finding malware or misuse in one place does not mean it is the only place. Indicators of compromise (IoCs) from the first host, such as file hashes, domains, IP addresses, account names and persistence mechanisms, are used to sweep the rest of the environment. Skipping that sweep is the classic reason an incident "returns" weeks later: the original cleanup was correct for one host and blind to the others.

Scoping matters most where the attacker had broad reach. A compromised privileged account, especially one held for a long time, may have been used on many systems and to create persistence: new accounts, scheduled tasks, services, keys or tokens. Remediating the first account or system found is reasonable in itself, but done before scoping it leaves other footholds in place and can warn the attacker to change tactics.

Scope comes before eradication because eradication that misses part of the compromise leaves the attacker a way back. Investigation also produces what later decisions need: the timeline, the likely entry point, which backups predate the compromise and whether notification thresholds are met. Those are handed to the communications, eradication and recovery activities covered in the next lesson.

Digital evidence is collected in order of volatility, most short-lived first: memory and live system state, then disk, then logs held elsewhere, archives and backups. RFC 3227 is the classic statement of this order. Memory holds running processes, network connections, logged-in sessions and sometimes encryption keys, and all of it is lost at shutdown. Disks, central logs and backups persist and can be collected afterwards.

This shapes containment of a running system that may become evidence. Powering it off stops the attacker but destroys volatile evidence; leaving it connected preserves evidence but allows further harm. Isolating it from the network contains the attacker without changing its running state, so memory can be captured before an orderly shutdown and disk imaging. Running cleanup tools before collection also changes the system and should wait.

Cloud and other short-lived infrastructure add a timing risk: an orchestration or autoscaling service may replace an instance it sees as unhealthy, deleting its memory and attached storage. The first step is to stop that automatic replacement (for example, by detaching the instance from its group or suspending the group's automatic replacement of unhealthy instances), then collect memory and a storage snapshot. Ordinary deletion safeguards are not enough: on some platforms, protection against manual termination does not stop the scaling service from replacing an instance. Order matters for the same reason: a containment step taken before replacement is stopped may make the instance fail its health checks and be replaced along with its evidence.

Integrity and admissibility rest on three practices:

• Chain of custody: a record of who collected each item, when, how, and every transfer and access afterwards. It is what shows a court or tribunal that the evidence presented is the evidence collected. Protecting evidence well is good practice, but only a documented record of every hand-off proves continuous, controlled handling.
• Hashing at collection: a cryptographic hash of each image or file, recorded when it is taken, lets anyone later verify that the copy is unchanged.
• Analysis on verified copies: examiners work on a hashed copy and keep the original in its seized state. Working on the original risks altering it, and the opposing party can use that to challenge the evidence, even though the hashed image itself is still intact.

Hashing protects evidence only from the moment of collection. It cannot show that data was unaltered before then. If an attacker held administrator rights on a system, its local logs and anything else stored on it may have been edited or deleted. Logs forwarded in real time to a separately administered central platform the attacker could not reach are a more reliable record, which is one reason central, protected log collection is part of incident readiness.

Investigations must follow legal and regulatory requirements, so legal counsel (and human resources when an employee is involved) are consulted before investigators examine an individual's communications, devices or records. Monitoring and searching employees is governed by privacy, employment and telecommunications law and by internal policy. Done wrongly, it can expose the organization to liability and make the evidence unusable in dismissal, civil or criminal proceedings. Disciplinary or external steps follow that advice; taking them first can prejudice the case and alert the person.

Across borders, the law of the jurisdiction where the data and devices are held primarily governs collection and transfer. Other laws can also reach the data (some privacy regimes, such as the GDPR, apply to personal data wherever it is processed), but internal documents and another country's procedures cannot authorize what local privacy, data transfer or evidence law forbids. Investigators plan collection with local counsel and, where needed, collect and review in the country before anything is transferred.

Whether and when to involve law enforcement is a business decision for senior management, made with legal advice. Reporting can bring investigative powers and expertise and may be mandatory for some incidents. It can also make the incident public, add requirements on evidence handling and reduce the organization's control over the investigation's timing. The information security manager contributes the facts and the security implications; legal counsel advises on obligations and consequences; senior management decides. Mandatory regulatory and breach notification itself is covered in the communications lesson.

Containment limits the damage an incident can still do and stops it spreading, and the strategy is chosen primarily by the potential damage and the impact each option would have on critical services. Widely used incident handling guidance lists the criteria to weigh: potential damage to and theft of resources, the need to preserve evidence, service availability, the time and resources the strategy needs, its effectiveness (partial or full containment) and its duration (temporary workaround or lasting solution). Damage and business impact lead because containment exists to limit harm: a strategy that is quick, cheap or evidence-friendly but leaves serious damage possible, or causes more disruption than the incident itself, has failed at its purpose. The other criteria shape how the chosen strategy is carried out.

Containment strategies are agreed in advance where possible, in the plan and playbooks, together with who may authorize disruptive actions. That prevents improvised decisions under pressure, which tend to be either broader and more disruptive than the incident needs or too narrow and slow to keep pace with it.

Good containment draws the boundary at the right place. Segmentation makes this possible: if infected office systems are on a separate segment from operational or production systems, the infected segment can be cut off from everything else, so spread stops quickly while the business keeps running. Where segmentation is weak, the only boundaries left are often too wide or too fine, which is why network design is a readiness issue as much as an architecture one.

Short-term containment is the immediate action that stops harm now; long-term containment puts temporary controls in place so the business can keep operating safely while the clean fix is prepared. Both come before eradication (removing malware, attacker accounts and persistence) and recovery (restoring clean systems to service), which belong to the next lesson.

Contain the attacker's actual foothold. Common methods and their limits:

• Compromised accounts. Disabling the account and revoking its active sessions and tokens cuts access from anywhere at once. Changing the credential without revoking what it already issued may leave existing sessions and tokens working. Disabling a service account can break the applications that depend on it, so the response team arranges a replacement credential with the owner; that cost is usually smaller than leaving the attacker access.
• Network blocks. Blocking known attacker infrastructure is quick but easily bypassed by an attacker who changes it; it supports, but rarely replaces, removing the foothold.
• Isolation and segmentation. Isolating hosts or segments stops spread; for systems that may be evidence, isolation preserves running state better than shutdown.
• Compensating controls. When a vulnerability cannot be patched in time, a temporary control, such as a web application firewall rule or filtering that blocks the specific exploit (often called virtual patching), can let a service resume. Where a system was actually compromised, trust is restored by rebuilding it clean, putting it behind the compensating control and applying the tested patch later; that meets both the security and the business requirement.

Broad shutdowns are the most complete containment but often overshoot; it is justified when the potential damage outweighs the outage, which is again a business impact judgement.

Delaying containment to observe an attacker, whether to learn their methods and scope or because law enforcement asks, accepts continued risk to the business, so it is a decision for senior management, advised by the information security manager and legal counsel. Containing at once may end the chance to identify the attacker or support a criminal case; waiting may expose sensitive data, customers and the organization's legal position. Neither the security team nor an outside agency can accept that exposure on the business's behalf. The manager's job is to present both sets of risks clearly so that the accountable executives decide.

If monitoring is approved, the accepted risk must be bounded in advance. The most important condition is a set of agreed trigger points, such as access to defined sensitive data, signs of exfiltration, privilege escalation or impact on critical services, at which containment starts immediately without a further meeting. Supporting arrangements that improve visibility or document the request are useful, but only predefined triggers limit the risk the business has accepted. The decision, its conditions and its approvers are documented as part of the incident record.