The Importance of Roles and Responsibilities in Incident Response

by Eric C. Thompson

When developing cybersecurity incident response plans, the roles and responsibilities sections normally focus on a couple items. Outlining all individuals from technical, front-line responders to executives with roles on the team.  The initial response team often include information security and IT infrastructure members because these are the people who understand the day-to-day operation of IT and information security.  If the front-line members of the team walkthrough event scenarios often enough, they learn lessons along the way.  One big lesson consistently learned is to make sure roles and responsibilities are clear. Specifically, when it comes to tools and technology.  Most entities have several tools incident response team members consult during the investigation of an event.  But do each of these capabilities have primary and secondary team member assigned. Heading into an event, knowing who is working where is vital.  Without it time is lost and the team quickly becomes disorganized.  Common technical capabilities utilized during event and incident investigation are included in the list below: 

Endpoint Detection and Response (EDR): This is a big one during incident response.  EDR is essential to understanding what happened to an endpoint during the event(s) under investigation.  The ability to review changes made to any given endpoint leading up to and during an event is key to effective containment.  These changes include files created and deleted and registry changes. These indicators of compromise (IOCs) discovered on one infected endpoint are used to find all other endpoints with the indicators during containment. 

IDS/IPS/Firewall: These logs confirm traffic entering and leaving the network.  Some types capture data about the traffic, for instance Cisco’s FirePower, captures packets related to alerts generated by its ruleset.  Most times, these logs confirm inbound and outbound connections but do not provide visibility when attempted inbound connections are blocked.  Sometimes containing an event or incident requires blocking connections.  Network and security engineers must be available to perform these activities.

SIEM: A security incident and event management solution (SIEM) is a centralized repository for logs collected from the information systems.  Logs generated by firewalls, intrusion detection and/or prevention systems, other network devices, servers, other endpoints and applications are ingested into SIEM solutions.  The SIEM indexes these logs for correlating activities to detect events or are searched when investigating events.  This is an important tool for the IR team.  SIEMs can provide details needed to understand what happened during the event in question.

Email Gateway: The email gateway data captures details of emails delivered to a single individual or groups of individuals during a campaign.  Details captured in these tools detail information about the source of the email.  If the threat actor is not sophisticated, the source of an email can be identified. When malicious emails are identified, the gateway informs the team of how many end users are affected.   

Web Proxy: The web proxy provides clues about activity during an event occurring over the web.  What sites were visited, was anything downloaded, how much traffic was sent over these connections and which direction was this traffic flowing are common questions.  These factors can indicate anomalous activity of interest to the IR team.

Traffic Flows and Packet Capture:  Traffic flows, commonly referred to by the Cisco specific name NetFlow, is valuable.  Some security and forensic analysts contend capturing flow data from enough points to see all traffic in the network is more valuable than have full packets for only a portion of the traffic during key times in the event lifecycle.  Flow data consists of the following information:

• Source IP address and port
• Destination IP address and port
• Number of packets
• Number of bytes exchanged
• Duration

This alone can identify attacks.  If you are ever lucky enough to take SANS Intrusion Detection in Depth course, on day five, students are shown how flow data can detect DNS tunneling.  Flow data several characteristics of DNS Tunneling.  Outbound connections on port 53, used for DNS queries and responses, contain the following pieces of evidence, the duration of the connection and bytes of data transferred.  Anomalous durations jump out when compared to all the other legitimate connections.  Also, byte data show much larger payloads exchanged than other connections over this port. Without looking at any packet data, an analyst either confirm these characteristics are present, or eliminate them from consideration.

Numerous other tools exist and are used during the investigation of events. This is not meant to be comprehensive discussion on incident response tools.  This is a reminder about the sheer number of data points IR teams have available, and the need to make assignments so all aspects are covered.  The Security Incident Response Team (SIRT) consists of technical members with expertise operating network devices and security tools and others still learning. Teams cannot assume the one person familiar with all technology is available when an event occurs. Equally important is not having half the team reviewing the same data.  Through the development of the incident response plan and playbooks, the team identifies the tools likely used when investigating incidents and events.  Assigning primary and secondary members to each, and clear expectations he or she owns that piece of technology during IR investigations eliminates ad hoc behavior and chaos.  The onus is also placed on those assigned to tools he or she is not familiar with to learn how to use the capability during an investigation.  The hope is less noise misdirection when invoking the incident response plan.

About the Author

Eric C. Thompson is an accomplished governance, risk, and compliance professional. In his GRC role as Director of Compliance at Blue Health Intelligence (BHI), Eric leads efforts to increase cyber security maturity in several domains, including governance, policy and controls, risk management, cyber security strategy, and business alignment. He established the risk management function which includes assessment, analysis and treatments of risks, threat and vulnerability management strategy, and due diligence requirements for assessing third-party risk. Eric also assesses cybersecurity technology capabilities and recommends enhancements to current solutions and new implementations that meet risk reduction requirements. Prior to BHI, Eric spent seven years at Ernst & Young in the Advisory practice where he specialized in helping healthcare organizations (providers, payers, and business associates) solve problems related to information security, risk management, and compliance when dealing with electronic medical records. Eric led the HITRUST Common Security Framework (CSF) cybersecurity program management and third-party risk management assessments. Eric is also a proud member of the SANS Mentor team.  

This article was contributed by Eric C. Thompson, author of Cybersecurity Incident Response.