Incident Response: The Computer Security Incident Handling Guide

Organizations have to implement some form of assistance in order to mitigate the risks of computer security incidents. Computer security incidents encompass anything that violates a computer security policy or practice. Some good examples of computer security incidents include malware infection, DDoS attacks against a Web server, or data breaches, all of which necessitate immediate and proper containment, eradication, and recovery.

The NIST SP 800-61 (Revision 2) assists organizations in responding efficiently and effectively to incidents big and small. Every organization is going to experience and incident at one point, so being able to appropriately respond and analyze incident-related data to determine an appropriate response is crucial in a time where Incidence Response (IR) has become an important aspect of Information Technology.

SP 800-61 provides organizations with a way to develop incident handling policies, plans, procedures, teams, and recommendations. It also prepares organizations for the detection and analysis of cyber attacks as well as the containment, eradication, and recovery from cyber incidents. Let’s take a look at the response techniques outlined in this document so we can better understand the proper way to react.

Preparation

Organizations must be prepared to handle a computer security incident before it happens. This entails the creation of an incident response team (IR team) and an identification of the key players (e.g., technical staff, contractors, law enforcement, management, stakeholders, human resources, marketing, and legal counsel). All key players must understand their role and responsibilities in the IR process. For example, the technical staff will provide continuing IT support in the background and report to senior leaders regarding updates, recovery time estimations, or any required assistance and resources. Likewise, the legal counsel will support any legal inquiries and will keep senior leaders stay informed should a computer security incident require some form of intervention, such as an e-discovery process or compliance to disclosure laws.

The IR team will likely have already undergone table-top exercises (TTXs) or live-fire exercises (LFXs) to prepare for real-world incidents and adverse events, seeing as this is critical to the success of any IR plan and business continuity. All incident handlers should have a way to communicate quickly and efficiently. Typically, incident handlers will hold a list of contact information of team members and others outside of their team. It’s also wise to setup a “war room” for central communication and coordination. Incident handlers, especially the technical staff and first responders, should all have the necessary equipment in their jump bags (e.g., IR documents, contact lists, write blockers, cabling, removable media, laptops, digital forensic software, anti-static evidence bags, evidence tags/labels, notepad and pen, and a camera).

Preventing Incidents

A good way to prepare for computer security incidents is to identify and understand weaknesses in the infrastructure. There are several approaches to completing this step. One way to do this is to conduct a Business Impact Analysis (BIA) that aligns with guidelines established in FIPS 199, which identifies and prioritizes an organization’s assets according to their security categorizations. From there, organizations can at least identify, which systems are critical to business continuity. Similarly, a risk assessment would help identify any risks that can be mitigated, transferred, deterred, or avoided. the guidelines in NIST SP-837 can help identify these risks, security categorizations, pinpoint recommended security controls, ascertain their correct implementation, and their acceptable monitoring practices.

Many organizations are implementing a vulnerability management framework whereby they periodically perform vulnerability scans using tools such as Nessus, OpenVAS, and Web application vulnerability scanners like Nikto. Most, however, are using Security
Content Automation Protocol (SCAP) scanners (like Nessus). Once vulnerabilities are identified, such as system misconfigurations, firewall misconfigurations, missing security hardware/software, and so forth, they can be mitigated by implementing the correct security controls, which helps in the prevention of computer security incidents. Additionally, user awareness training plays a big role in reducing the frequency of computer security incidents because users are aware of the organization’s security policies and procedures.

Signs of an Incident

Identifying the signs of a computer security incident can prove difficult, but are worthwhile since earlier detection could help mitigate any adverse events. Therefore, an organization should turn their attention to the abundance of data sources at their disposal, such as firewall logs, IDS/IPS logs and alerts, packet captures, NetFlow data, system logs, SIEMs, anti-malware software alerts, and file integrity checks.

Learn to analyze these sources of data! For example, if you see one of your network device logs showing continuing failed login attempts in a short amount of time, this could be an indication of a brute force attack. Likewise, if your packet captures are showing suspicious malformed packets, the source of this traffic would be something to investigate further.

After that, you might want to use some form of point-in-time analysis or correlation analysis for investigation. If you observe that your initial baseline doesn’t show the suspicious event in question, such as a spike in a host’s activity, you could examine that particular system for a possible malware infection.

Prioritizing Incidents

When incidents do occur, you should prioritize them based on a number of different criteria. Ask the following questions: How will this incident impact the existing functionality of the organization (e.g., low. medium, or high)? What information is impacted as a result of this incident? Obviously, the more sensitive the information (e.g, PHI or proprietary information), the more prioritization the incident deserves. What is the recovery time estimation for this incident? If you find that the recovery time exceeds your recovery objective, you may need to recruit additional resources or help from third parties.

Combining these together identifies the true impact of the incident, any supplementary resources required to contain and eradicate the incident, and an idea of how long the recovery process will take. It also helps you recognize when the organization has a legal requirement or obligation to notify its stakeholders or customers.

Containment

When the incident is identified and prioritized, it’s time to contain the incident in order to mitigate its effects. There are many ways we can contain an incident and deny it any further damage. Most importantly, however, you should consider the following before containment:

• What damage has already been done?
• Will you need to preserve any evidence?
• How will this affect the availability of the affected service?
• What is the duration of this solution?

One of the trickier things is evidence handling. Should your organization wish to proceed with litigation, evidence will need to be collected in a way that it meets all applicable laws and regulations. Immediately turning off or unplugging an affected system might wipe valuable evidence from volatile memory, cause an unintentional DoS, or limit functionality of critical systems; therefore, it’s important that evidence collection and containment be performed correctly.

One of the ways to contain an incident is through network segmentation. This can be accomplished by physically re-wiring affected systems onto separate networks or logically connecting the systems to an isolated VLAN. This would prevent any lateral movement or communication to a C2 node.

You could also physically remove the affected system off of the network; however, there should be a careful consideration regarding whether or not the system should be powered off considering that the system could contain evidence and valuable intelligence about the adversary.

Reverse engineering could also assist in containment. By statically or dynamically analyzing malware, we can identify how it works, what it does, and identify what other systems are infected.

Eradication and Recovery

After the computer security incident is contained, the IR team can eradicate the infection, breached accounts, or whatever it might be, by identifying and mitigating the vulnerabilities that were exploited. Since we are returning our systems to a known-good state, eradication is sometimes paired with recovery.

If the sanitization of media is required, organizations may follow the guidelines established in NIST SP 800-88 (revision 1). Some adversaries, especially state-sponsored APTs, will pervasively try to remain in an organizations systems. Some recommended ways to conduct proper sanitization are by overwriting the medium with 1s and 0s in multiple rounds. Another option would be to delete an encryption key. On devices that store encrypted information, it’s easier to throw away the key. Two very effective sanitization methods are degassing and physical destruction. The degassing process applies a strong magnetic force against the storage medium. For example, applying a strong magnet to a hard disk drive would not only wipe the data, but probably render it unusable too. On the other hand, physically destroying the device means we either shred it, incinerate it, or expose it to corrosive chemicals.

To re-build the affected systems to a known-good state, we can reconstruct them by applying backups of our system configurations and data. Otherwise, an organization would have to manually re-build the system from scratch, which means the operating system would need to be configured, hardened, any applications that need to be installed thereafter.

The Validation Process

During the validation process, the organization verifies the countermeasures and security controls are working as intended. At this point, the organization has already analyzed the incident data and identified the attack vector. Some of the ways we can validate are:

• Patching: Many computer security incidents result from unpatched systems. By confirming a patch is in place, the organization is taking a proactive step in preventing identical incidents in the future.
• User account and permission reviews: Cyberattacks can be exasperated if user accounts have unnecessary high-level privileges because it puts the organization at risk of vertical privilege escalation attacks. During the incident, the adversaries could have gained a leverage for lateral movement, which of course will only be identified through a thorough user account and permissions review.
• Vulnerability scanning: A vulnerability scan can verify if the vulnerability is still in place or if another related vulnerability exists.
• Continual Monitoring: By continually monitoring the network and the implemented security controls, an organization is reducing risk.

Corrective Actions

The lessons-learned is the most important part of the IR because it helps the organization learn and improve for the next computer security incident. After a considerably thorough reflection, each team should review what exactly happened, how well they performed, what they could improve on, what information they needed sooner, how information sharing could be improved, what they would do differently, and what additional tools or resources are needed for the next computer security incident. This can be accomplished if every team member records their thoughts onto a document that can be submitted to the senior leaders. From there, the senior leaders can pick which lessons-learned reports are the most valuable to share in the After Action Review (ARR).

Some recommendations will also reach the Change Control Board, where any suggested or requested changes to the organization’s infrastructure will be reviewed by the Change Control Committee. After the ARR, the IR plan should be updated to reflect any of the recommendations or suggestions identified during the lessons-learned. An After Action report should summarize all the key points of the incident.

 

References

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer Security Incident Handling Guide (NIST Special Publication 800-61 Rev. 2).  Retrieved from the National Institute of Standards and Technology Web site:https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf

Maymi, F. J., Chapman, B. (2018). All-in-One CompTIA CSyA+ Cybersecurity Analyst Certification Exam Guide CS0-001. McGraw-Hill Education: New York, NY.

National Institute of Standards and Technology. (2004). Federal Information Processing Standards Publication (FIPS PUB 199). Retrieved from the National Institute of Standards and Technology Web site: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf

Ross, R., Swanson, M., Stoneburner, G., Katzke, S., & Johnson, L. (2010). Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach(NIST Special Publication 800-137 Rev. 1). Retrieved from the National Institute of Standards and Technology Web site: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-37r1.pdf