How to respond to a security incident by Yuri Livshitz
Fair use disclaimer: I do not own this content. This post contains excerpts (“highlights”) from a longer article used here solely for educational purposes. All credits go to its rightful owner. Please see Citation information.
<Security incidents happen suddenly, and an organization’s key functions can be significantly damaged. Incidents create a high level of tension—which might escalate to panic. In order to avoid both the damage and the panic, an organization should be well prepared for security incidents.>
You may also be interested in How to break into information security.
Preparation
<A key factor in a solid incident response plan is establishing a process to make incident response a structured, documented, and accountable activity. An organization should have a security incident response team (SIRT), which will investigate and document incidents. In large organizations, SIRT personnel will be based on InfoSec and security operations and control (SOC) groups; in smaller companies, the members of the SIRT team will come from InfoSec, IT, and even development teams. Senior management should set a framework for SIRT operation, and give the SIRT sufficient support to make investigation and response actionable.>
<The SIRT is responsible for playbook creation, based on the organization’s risk assessment of possible security incidents, and come up with plans for a structured way to react to them. For instance, it is important to rank incidents by severity level. It is critical to differentiate between security events (less serious) and security incidents (serious and requiring immediate action). A security event, like a virus on endpoint, might escalate to incident level, but typically it can be addressed via standard procedures or even automation … The SIRT should create a list with everyone’s contact details and a summary of each team member’s responsibility. Those contacts should be aware that in the case of an incident, they might be contacted. Perhaps the best way to do that is via an SMS alerting system with an escalation policy (PagerDuty is a good example of such a service).>
<Every step you make in reducing your organization’s threat surface by blocking ports or reducing access rights will save you an immense amount of work later on. It is highly advisable to do regular incident drills in order to verify that you have a proper incident response process in your organization.>
Identification of security incidents
<It is critical to identify incidents as early as possible to significantly reduce any damage that might be done by bad actors. For swift identification, security information and event management (SIEM) technology should be used. SIEM can integrate and correlate distributed events and alert on hostile or abnormal behavior. A best practice for incident investigation is to enrich your SIEM solution with external threat data. That external threat data can highlight known threat activity in your organization.
<Another key factor in incident identification is a good data-analysis capability. It is vital that an organization’s SIRT measures baselines, and investigates deviation from those baselines. When doing so, it is critical to include logs from all the important systems in the organization. It is important to remember that any security incident might just be just a deception designed to distract from another, more sophisticated, breach attempt.>
<If your analysis leads you to believe that vital company assets—or even people’s lives—might be at risk, immediately notify management and if warranted, law enforcement. You should act responsibly, putting people’s safety and security first.>
Containment
<IT and security should take swift action in order to limit an incident’s impact. When an incident is identified and verified, indicators of compromise should be documented and a high-priority ticket opened. Information should be gathered to determine all the servers, endpoints, and users involved. IT should limit involved users’ permissions, or even disable the users. IT should also limit affected systems’ network connectivity to prevent any communication between infected machines and healthy ones in the corporate LAN. The top goal of the SIRT during the containment phase is to protect critical systems and limit bad actors’ ability to move inside the network. Each step should be properly documented with sufficient details regarding why, how, by whom, and where containment actions were performed.>
Eradication
<After compromised systems are contained, SIRT should return breached systems to working order. This would be done using restore from backup, maintaining original storage as evidence. Disks of the breached sever can be later used for forensic investigation.
<During the incident-eradication stage, it’s important to avoid any software reinstall on breached servers. Only healthy and verified backups should be used. If backup of the infected servers is vulnerable to a known exploit, it has to be patched before you connect it to the corporate network, to reduce the risk of additional breach.>
<The topic of forensics is beyond the scope of this chapter, but I’ll say this: If your organization requires court-admissible evidence following an incident, it’s advisable to consult with professional forensic experts, as only properly collected computer evidence is admissible in court.>
Recovery
<Recovery is about restoring the service that got breached. During this stage, it is important to verify that service is fully available again, including data and previous customizations. Infected systems’ owners should verify that restored systems function properly. Monitoring and verification of restored systems is of extreme importance to prevent any additional breach attempts. Attackers might use new tactics against previously breached systems; therefore comprehensive monitoring techniques should be used.>
Lessons learned
<After a company has recovered from an incident and infected systems are patched or replaced, the “lessons learned” phase should begin. Security staff should complete all documentation that wasn’t done during the previous incident response steps. Documentation should be detailed and structured to answer specific questions regarding why, where, and how the incident occurred. The final chapter of the incident report should include practical steps to take in order to avoid similar incidents. From this document, SIRT can create a new playbook to streamline the incident-response process.>
Further reading
<The Incident Response Handler’s Handbook is must-read material, as it lays out the methodology of the incident response process.>
Citation information
Yuri Livshitz. (2016). How to respond to a security incident (Ch. 9). In Beginner’s Guide To Information Security (pp. 42-45). Peerlyst. Retrieved from https://www.peerlyst.com/posts/peerlyst-announcing-its-first-community-ebook-the-beginner-s-guide-to-information-security-limor-elbaz
