New, stealthy threats change best responses to cyberattack

Newly revised guidelines for responding to security incidents have been updated to reflect the emergence of advanced persistent threats in the IT threat landscape.

“Unlike most threats several years ago, which tended to be short-lived and easy to notice, many of today’s threats are more stealthy, specifically designed to quietly, slowly spread to other hosts, gathering information over extended periods of time and eventually leading to exfiltration of sensitive data and other negative impacts,” the National Institute of Standards and Technology says in the publication.

“Identifying these threats in their early stages is key to preventing subsequent compromises, and sharing information among organizations regarding the signs of these threats is an increasingly effective way to identify them,” the guide states.

Related coverage:

How to prevent data breaches – and respond after they occur anyway

A draft of NIST Special Publication 800-61 Rev. 2, "Computer Security Incident Handling Guide," has been released for comment. It has been updated from the previous version released in 2008 and includes guidelines on establishing an effective incident response program, as well as detecting, analyzing, prioritizing and handling incidents.

Comments on the draft should be sent by March 16 to 800-61rev2-comments@nist.gov with "Comments SP 800-61" in the subject line.

Although risk assessments, monitoring and preventive activities can lower the number of security incidents, not all incidents can be prevented, and an incident response capability is necessary. Its goals are rapidly detecting incidents, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring services.

The latest version includes more material on information sharing and changes the focus from identifying the attacker to identifying the attacking host. In initial responses, knowing where an attack is coming from probably should take a back seat to containing the incident, NIST advises. “Identifying an attacking host can be a time-consuming and futile process that can prevent a team from achieving its primary goal — minimizing the business impact.”

The document lays out requirements for establishing an effective incident response program and also outlines the major steps in an incident response if a formal response program is not yet in place:

• Document everything. This includes every action, every piece of evidence, and every conversation with users, system owners and others about the incident.
• Find a co-worker who can provide assistance. Handling the incident will be much easier if two or more people work together. For example, one person can document the actions of the other.
• Analyze the evidence to confirm that an incident has occurred. Perform additional research as necessary (e.g., Internet search engines, software documentation) to better understand the evidence. Reach out to other technical professionals within the organization for help.
• Notify the appropriate people within the organization. This should include the CIO, the head of information security, and the local security manager. Use discretion when discussing details of an incident with others; tell only the people who need to know, and use communication mechanisms that are reasonably secure. If the attacker has compromised e-mail services, do not send e-mails about the incident.
• Notify US-CERT and other external organizations for assistance in dealing with the incident.
• Stop the incident if it is still in progress. The most common way to do this is to disconnect affected systems from the network. In some cases, firewall and router configurations may need to be modified to stop network traffic that is part of an incident, such as a denial-of-service attack.
• Preserve evidence from the incident. Make backups (preferably disk image backups, not file system backups) of affected systems. Make copies of log files that contain evidence related to the incident.
• Wipe out all effects of the incident. This effort includes malware infections, inappropriate materials such as pirated software, Trojan horse files, and any other changes made to systems during the incidents. If a system has been fully compromised, rebuild it from scratch or restore it from a known good backup.
• Identify and mitigate all vulnerabilities that were exploited. The incident may have occurred by taking advantage of vulnerabilities in operating systems or applications. It is critical to identify such vulnerabilities and eliminate or otherwise mitigate them so the incident does not recur.
• Confirm that operations have been restored to normal. Make sure that data, applications and other services affected by the incident have been returned to normal operations.
• Create a final report. This report should detail the incident handling process and include an executive summary of what happened and how a formal incident response capability would have helped to handle the situation, mitigate the risk and limit the damage more quickly.