Page295

Mitigation

The mitigation phase (aka eradication) involves the process of understanding the cause of the incident so that the system can be reliably cleaned and ultimately restored to operational status later in the recovery phase. In order for an organization to be able to reliably recover from an incident, the cause of the incident must be determined. The cause must be known so that the systems in question can be returned to a known good state without significant risk of compromise persisting or reoccurring. A common occurrence is for organizations to remove the most obvious piece of malware affecting a system and think that is sufficient. In reality, the obvious malware may only be a symptom, with the cause still undiscovered.

Once the cause and symptoms are determined, then the system is restored to a good state and should not be vulnerable to further impact. This will typically involve either rebuilding the system from scratch or restoring from a known good backup. A key question is whether the known good backup can really be trusted. Root-cause analysis is key here: it can help develop a timeline of events that lends credence to the suggestion of a backup or image known to be good. Another aspect of eradication that helps with the prevention of future impact is bolstering defenses of the system. If the incident was caused by exploitation of a known vulnerability, then a patch would be prudent. However, improving the system’s firewall configuration might also be a means to help defend against the same or similar attacks. Once eradication has been completed, then the recovery phase begins.

Reporting

The reporting phase of incident handling occurs throughout the process, beginning with detection. Reporting must begin immediately upon detection of malicious activity. Reporting contains two primary areas of focus: technical and non-technical reporting. The incident handling teams must report the technical details of the incident as they begin the incident handling process, while maintaining sufficient bandwidth to also notify management of serious incidents. A common mistake is forgoing the latter while focusing on the technical details of the incident itself: this is a mistake. Non-technical stakeholders including business and mission owners must be notified immediately of any serious incident, and kept up to date as the incident handling process progresses.

More formal reporting begins just before the recovery phase, where technical and non-technical stakeholders will begin to receive formal reports of the incident as it winds down, and staff prepares to recover affected systems and place them back into production.

Recovery

The recovery phase involves cautiously restoring the system or systems to operational status. Typically, the business unit responsible for the system will dictate when the system will go back online. Remember to be cognizant of the possibility that the infection, attacker, or another threat agent might have persisted through the eradication phase. For this reason, close monitoring of the system after it is returned to production is necessary. Further, to make the security monitoring of this system easier, strong preference is given to the restoration of operations occurring during off or non-peak production hours.

Remediation

Remediation steps occur during the mitigation phase, where vulnerabilities within the impacted system or systems are mitigated. Remediation continues after that phase, and becomes broader. For example: if the root-cause analysis determines that a password was stolen and reused, local mitigation steps could include changing the compromised password and placing the system back online. Broader remediation steps could include requiring dual-factor authentication for all systems accessing sensitive data. We will discuss root-cause analysis shortly.