34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Digital Forensics and Incident Response will guide you through the entire spectrum of tasks associated with incident response, starting with preparatory activities associated with creating an incident response plan and creating a digital forensics capability within your own organization. You will then begin a detailed examination of digital forensic techniques including acquiring evidence, examining volatile memory, hard drive assessment, and network-based evidence. You will also explore the role that threat intelligence plays in the incident response process. Finally, a detailed section on preparing reports will help you prepare a written report for use either internally or in a courtroom.
By the end of the book, you will have mastered forensic techniques and incident response and you will have a solid foundation on which to increase your ability to investigate such incidents in your organization.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 332
Veröffentlichungsjahr: 2017
Ähnliche
BIRMINGHAM - MUMBAI
< html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
Digital Forensics and Incident Response
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2017
Production reference: 1210717
ISBN 978-1-78728-868-3
www.packtpub.com
Credits
Author
Gerard Johansen
Copy Editor
Safis Editing
Reviewer
Nicole L. Stoneman
Project Coordinator
Judie Jose
Acquisition Editor
Rahul Nair
Proofreader
Safis Editing
Content Development Editor
Abhishek Jadhav
Indexer
Aishwarya Gangawane
Technical Editor
Manish D Shanbhag
Graphics
Kirk D'Penha
Production Coordinator
Aparna Bhagat
About the Author
Gerard Johansen is an information security professional with over a decade of experience in such areas as penetration testing, vulnerability management, threat assessment modeling, and incident response. Beginning his information security career while acybercrime investigator, Gerard has built on that experience while working as a consultant and security analyst for clients and organizations ranging from healthcare to finance. Gerard is a graduate of Norwich University's Masters of Science in Information Assurance and a Certified Information Systems Security Professional.
Gerard is currently employed as an Enterprise Security Manager with a large retailer with a focus on incident detection, response and threat intelligence integration. He has also contributed to several online publications focused on various aspects of penetration testing.
About the Reviewer
Nicole L. Stoneman is the Director of Digital of Forensics at Vestigant. Ms. Stoneman has been conducting computer forensic exams since 2005 and has been involved in thousands of forensic investigations.Ms. Stoneman is a Certified Computer Examiner (CCE) through The International Society of Forensic Computer Examiners.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.comand as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1787288684/.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the color images of this book
Errata
Piracy
Questions
Incident Response
The incident response process
The role of digital forensics
The incident response framework
The incident response charter
CSIRT
CSIRT core team
Technical support personnel
Organizational support personnel
External resources
The incident response plan
Incident classification
The incident response playbook
Escalation procedures
Maintaining the incident response capability
Summary
Forensic Fundamentals
Legal aspects
Laws and regulations
Rules of evidence
Digital forensic fundamentals
A brief history
The digital forensic process
Identification
Preservation
Collection
Proper evidence handling
Chain of custody
Examination
Analysis
Presentation
Digital forensic lab
Physical security
Tools
Hardware
Software
Jump kit
Summary
Network Evidence Collection
Preparation
Network diagram
Configuration
Logs and log management
Network device evidence
Security information and event management system
Security onion
Packet capture
tcpdump
WinPcap and RawCap
Wireshark
Evidence collection
Summary
Acquiring Host-Based Evidence
Preparation
Evidence volatility
Evidence acquisition
Evidence collection procedures
Memory acquisition
Local acquisition
FTK Imager
Winpmem
Remote acquisition
Winpmem
F-Response
Virtual machines
Non-volatile data
Summary
Understanding Forensic Imaging
Overview of forensic imaging
Preparing a stage drive
Imaging
Dead imaging
Live imaging
Imaging with Linux
Summary
Network Evidence Analysis
Analyzing packet captures
Command-line tools
Wireshark
Xplico and CapAnalysis
Xplico
CapAnalysis
Analyzing network log files
DNS blacklists
SIEM
ELK Stack
Summary
Analyzing System Memory
Memory evidence overview
Memory analysis
Memory analysis methodology
SANS six-part methodology
Network connections methodology
Tools
Redline
Volatility
Installing Volatility
Identifying the image
pslist
psscan
pstree
DLLlist
Handles
svcscan
netscan and sockets
LDR modules
psxview
Dlldump
memdump
procdump
Rekall
imageinfo
pslist
Event logs
Sockets
Malfind
Summary
Analyzing System Storage
Forensic platforms
Autopsy
Installing Autopsy
Opening a case
Navigating Autopsy
Examining a Case
Web Artifacts
Attached Devices
Deleted Files
Keyword Searches
Timeline Analysis
Registry analysis
Summary
Forensic Reporting
Documentation overview
What to document
Types of documentation
Sources
Audience
Incident tracking
Fast incident response
Written reports
Executive summary
Incident report
Forensic report
Summary
Malware Analysis
Malware overview
Malware analysis overview
Static analysis
Dynamic analysis
Analyzing malware
Static analysis
Pestudio
Remnux
Dynamic analysis
Process Explorer
Cuckoo sandbox
Summary
Threat Intelligence
Threat intelligence overview
Threat intelligence types
Threat intelligence methodology
Threat intelligence direction
Cyber kill chain
Diamond model
MITRE ATT&CK
Threat intelligence sources
Internally developed sources
Commercial sourcing
Open source
Threat intelligence platforms
MISP threat sharing
Using threat intelligence
Proactive threat intelligence
Reactive threat intelligence
Autopsy
Redline
Yara and Loki
Summary
Preface
Digital Forensics and Incident Response will guide you through the entire spectrum of tasks associated with incident response, starting with preparatory activities associated with creating an incident response plan and creating a digital forensics capability within your own organization. You will then begin a detailed examination of digital forensic techniques including acquiring evidence, examining volatile memory, hard drive assessment, and network-based evidence. You will also explore the role that threat intelligence plays in the incident response process. Finally, a detailed section on preparing reports will help you prepare a written report for use either internally or in a courtroom.By the end of the book, you will have mastered forensic techniques and incident response and you will have a solid foundation on which to increase your ability to investigate such incidents in your organization.
What this book covers
Chapter 1, Incident Response, addresses the incident response process and how to create an incident response framework for use within an enterprise, which allows for an orderly investigation and remediation of a cyber security incident.
Chapter 2 , Forensics Fundamentals,focuses on the fundamental aspects of digital forensics. This includes a brief history of digital forensics, the basic elements of forensic science, and integrating these techniques into the incident response framework.
Chapter 3 , Network Evidence Collection, focuses on the network-based evidence. This includes logs from network devices such as firewalls, routers, proxy servers, and other layer 2 and 3 devices. The chapter also focuses on acquiring network-based evidence from these sources.
Chapter 4, Host-Based Evidence, compromised hosts contain a good deal of forensically valuable information. In this chapter, the reader guided through the process of using free tools to acquire the running volatile memory, log files, and other evidence on a running system.
Chapter 5, Understanding Forensics Imaging, hard disk drives from compromised systems may contain a great deal of evidence.Furthermore, in cases of fraud or other cybercrimes, most of the evidence that is valuable is obtained from the HDD. As a result, the proper acquisition of this evidence is critical. To do this requires a forensically sound process. This chapter details the steps necessary to properly image a suspect HDD.
Chapter 6, Network Evidence Analysis, using free tools such as tcpdump and Wireshark, the reader is guided through the analysis process to identify evidence such as command and control traffic or data exfiltration. Readers are also be guided through correlating firewall and proxy logs with packet captures.
Chapter 7, Analyzing System Memory,explores the methods for identifying potential malicious code present within the memory of a compromised system. This includes using commonly available tools and methods to identify processes, network connections, and registry key settings associated with potentially malicious software.
Chapter 8, Analyzing System Storage,consists of an overview of several tools and methods available for extracting potential evidence from previously imaged HDDs. An examination of tools and methods is undertaken, but it should be noted that, due to the complexity and depth of digital forensic examination, this will serve only to highlight specific areas.
Chapter 9, Forensic Reporting, reporting the findings from an incident is a critical step that is often overlooked. In this chapter, the reader is guided through preparing a report for use by internal stakeholders and potential external legal entities. The end goal is to have a report prepared that can stand the scrutiny of a court of law.
Chapter 10, Malware Analysis,will provide an overview of the methods that can be deployed for examining malware in a sandbox environment. This provides incident responders with reverse engineering skills an environment to deploy a suspected piece of malware for investigation.
Chapter 11, Threat Intelligence, threat intelligence is a relatively new concept in the information security space, and in particular to the incident response field. In this chapter, the reader will be guided through a review of threat intelligence and how to incorporate that into their incident response framework and processes.
What you need for this book
The following software is required for this book:
EnCase Imager
F-Response
Rekal
Madiant Redline
Autopsy
Wireshark
tcpdump
Volatility
Security Onion
FTK Imager
Winpmem
Eraser
CAINE OS, a Linux distribution for forensics purposes
Xplico and CapAnalysis
ELK stack
Fast Incident Response
(
FIR
) platform
Pestudio
Remnux
Cuckoo Sandbox
Yara and Loki
The hardware and system requirements for these can be found at there respective websites. Most of this softwares are free, but F-Response is paid.
Who this book is for
This book is targeted at information security professionals, forensics practitioners, and students with knowledge of and experience in the use of software applications and basic command-line experience. It will also help professionals who are new to the incident response/digital forensics role within their organization.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide atwww.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/DigitalForensicsandIncidentResponse_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title. To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] a link to the suspected pirated material. We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Incident Response
There are a number of threats to today's complex information systems. An internal employee can download a single instance of ransomware and can have a significant impact on an organization. More complex attacks such as a network exploitation attempt or targeted data breach increases the chaos that a security incident causes. Technical personnel will have their hands full, attempting to determine what systems have been impacted and how they are being manipulated. They will also have to possibly contend with addressing the possible loss of data through compromised systems. Adding to this chaotic situation is senior managers haranguing them for updates and an answer to the central questions of how did this happen? and how bad is it?
Having the ability to properly respond to security incidents in an orderly and efficient manner allows organizations to both limit the damage of a potential cyber attack, but also recover from the associated damage that is caused. To facilitate this orderly response, organizations of all sizes have looked at adding an incident response capability to their existing policies and procedures.
In order to build this capability within the organization, several key components must be addressed. First, organizations need to have a working knowledge of the incident response process. This process outlines the general flow of an incident and the general actions that are taken at each stage. Second, organizations need to have access to personnel who form the nucleus of any incident response capability. Once a team is organized, a formalized plan and associated processes need to be created. This written plan and processes form the orderly structure that an organization can follow during an incident. Finally, with this framework in place, the plan has to be continually evaluated, tested, and improved as new threats immerge. Utilizing this framework will position organizations to be prepared for the unfortunate reality that many organizations have already faced, an incident that compromises their security.
The incident response process
There is a general path that cyber security incidents follow during their lifetime. If the organization has a mature incident response capability, they will have taken measures to ensure they are prepared to address an incident at each stage of the process. Each incident starts with the first time the organization becomes aware of an event or series of events indicative of malicious activity. This detection can come in the form of a security control alert or external party informing the organization of a potential security issue. Once alerted, the organization moves through analyzing the incident through containment measures to bring the information system back to normal operations. The following figure shows how these flow in a cycle with Preparation as the starting point. Closer examination reveals that every incident is used to better prepare the organization for future incidents as the Post Incident Activityand is utilized in the preparation for the next incident:
The incident response process can be broken down into six distinct phases, each with a set of actions the organization can take to address the incident:
Preparation:
Without good preparation, any subsequent incident response is going to be disorganized and has the potential to make the incident worse. Some of the critical components of preparation are the creation of an incident response plan. Once a plan is in place with the necessary staffing, ensure that personnel detailed with incident response duties are properly trained. This includes both processes, procedures, and any additional tools necessary for the investigation of an incident. In addition to the plan, tools such as forensics hardware and software should be acquired and incorporated into the overall process. Finally, regular exercises should be conducted to ensure that the organization is trained and familiar with the process.
Detection:
The detection of potential incidents is a complex endeavor. Depending on the size of the organization, they may have over 100 million separate events per day. Couple this mountain of events with other security controls constantly alerting to activity and you have a situation where analysts are inundated with data and have to subsequently sift out the valuable pieces of signal from the vastness of network noise. Even today's cutting edge
Security Incident and Event Management (SIEM)
tools lose their effectiveness if they are not properly maintained with regular updates of rule sets that identify what events classify as a potential incident. The detection phase is that part of the incident response process where the organization first becomes aware of a set of events that possibly indicates malicious activity. This can be from the SIEM technology or other security controls. For example, a security analyst may receive an alert that a particular administrator account was in use during a period of time where the user was on vacation. Detection may also come from external sources. An ISP or law enforcement agency may detect malicious activity originating in an organization's network and contact them and advise them of the situation. In other instances, users may be the first to indicate a potential security incident. This may be as simple as an employee contacting the help desk and informing a help desk technician that they received an Excel spreadsheet from an unknown source and opened it. They are now complaining that their files on the local system are being encrypted. In each case, an organization would have to escalate each of these events to the level of an incident (which we will cover a little later in this chapter) and begin the reactive process to investigate and remediate.
Analysis:
Once an incident has been detected, personnel from the organization or a trusted third party will begin the analysis phase. In this phase, personnel begin the task of collecting evidence from systems such as running memory, log files, network connections, and running software processes. Depending on the type of incident, this collection can take as little as a few hours to several days. Once the evidence is collected, it then has to be examined. There are a variety of tools to conduct this analysis, many of which are explored in this book. With these tools, analysts are attempting to ascertain what happened, what it affected, whether any other systems were involved, and whether any confidential data was removed. The ultimate goal of the analysis is to determine the root cause of the incident and reconstruct the actions of the threat actor from initial compromise to detection.
Containment:
Once there is a solid understanding of what the incident is and what systems are involved, organizations can then move into the containment phase. In this phase, organizations take measures to limit the ability for threat actors to continue compromising other network resources, communicating with command and control infrastructures, or exfiltrating confidential data. Containment strategies can range from locking down ports and IP address on a firewall to simply removing the network cable from the back of an infected machine. Each type of incident involves its own containment strategy, but having several options allows personnel to stop the bleeding at the source if they are able to detect a security incident before or during the time when threat actors are pilfering data.
Eradication and recovery:
During the eradication phase, the organization removes the threat actor from the impacted network. In the case of a malware infection, the organization may run an enhanced anti-malware solution. Other times, infected machines have to be wiped and reimaged. Other activities include removing or changing compromised user accounts. If an organization has identified a vulnerability that was exploited, vendor patches are applied or software updates are made. Recovery activities are very closely aligned with those that may be found in an organization's
business continuity or disaster recovery
plans. In this phase of the process, organizations reinstall fresh operating systems or applications. They will also restore data on local systems from backups. As a due diligence step, organizations will also audit their existing user and administrator accounts to ensure that there are no accounts that have been enabled by threat actors. Finally, a comprehensive vulnerability scan is conducted so that the organization is confident that any exploitable vulnerabilities have been removed.
Post-incident activity:
At the conclusion of the incident process is a complete review of the incident with all the principle stakeholders. Post-incident activity includes a complete review of all the actions taken during the incident. What worked and more importantly, what did not work are important topics for discussion. These reviews are important because they may highlight specific tasks and actions that had either a positive or negative impact on the outcome of the incident response. It is during this phase of the process that a written report is completed. Documenting the actions taken during the incident is critical to capture both what occurred and also whether the incident will ever see the inside of a courtroom. For documentation to be effective, it should be detailed and show a clear chain of events with a focus on the root cause if it was determined. Personnel involved in the preparation of this report should realize that stakeholders outside of information technology might read this report. As a result, technical jargon or concepts should be explained. Finally, the organizational personnel should update their own incident response processes with any new information developed during the post-incident debrief and reporting. This incorporation of
lessons learned
is important as it makes future responses to incidents more effective.
The role of digital forensics
There is a misconception that is often held by people unfamiliar with the realm of incident response. This misconception is that incident response is merely a digital forensics issue. As a result, they will often conflate the two terms. While digital forensics is a critical component to incident response (and this is why we have included a number of chapters in this book to address digital forensics), there is more to addressing an incident than examining hard drives. It is best to think of forensics as a supporting function of the overall incident response process. For example, some incidents such as Denial of Service attacks will require little to no forensic work. On the other hand, a network intrusion involving the compromise of an internal server and Command and Control (C2) traffic leaving the network will require extensive examination of logs, traffic analysis, and examination of memory. From this analysis may be derived the root cause. In both cases, the impacted organization would be able to connect with the incident, but forensics played a much more important role in the latter case.
The incident response framework
When examining the incident response process, it is not ad hoc. Undefined processes or procedures will leave an organization unable to both identify the extent of the incident and be able to stop the bleeding in sufficient time to limit damage. Having an understanding of the incident response process is just the first step to building this capability within an organization. What is needed is a framework that puts that process to work utilizing the organization's available resources. The incident response framework describes the components of a functional incident response capability within an organization. This framework is made up of elements such as personnel, policies, and procedures. It is through these elements that an organization builds its capability to respond to incidents.
The incident response charter
The first step to building this capability is the decision by senior leadership that the risk to the organization is too significant not to address the possibility of a potential security incident. Once that point is reached, a senior member of the organization will serve as a project sponsor and craft the incident response charter. This charter outlines key elements that will drive the creation of a Computer Security Incident Response Team (CSIRT).
The incident response charter should be a written document that addresses the following:
Obtain senior leadership support
: In order to be a viable part of the organization, the CSIRT requires the support of the senior leadership within the organization. In a private sector institution, it may be difficult to obtain the necessary support and funding, as the CSIRT itself does not provide value in the same way marketing or sales does. What should be understood is that the CSIRT acts as an insurance policy in the event the worse happens. In this manner, a CSRIT can justify its existence by reducing the impact of incidents and thereby reducing the costs associated with a security breach or other malicious activity.
Define the constituency
: The constituency clearly defines which organizational elements and domains the CSIRT has responsibility for. Some organizations have several divisions or subsidiaries that for whatever reason may not be part of the CSIRT's responsibility. The constituency can be defined either as a domain such as
local.example.com
or an organization name such as Acme Inc. and associated subsidiary organizations.
Create a mission statement
: Mission creep or the gradual expansion of the CSIRT's responsibilities can occur without clear definition of what the defined purpose of the CSIRT is. In order to counter this, a clearly defined mission statement should be included with the written information security plan. For example,
The mission of the Acme Inc. CSIRT is to provide timely analysis and actions to security incidents that impact the Confidentiality, Integrity, and Availability of ACME Inc. information systems and personnel.
Determine service delivery
: Along with a mission statement, a clearly defined list of services can also counter the risk of mission creep of the CSIRT. Services are usually divided into two separate categories, proactive and reactive services:
Proactive services:
These includes providing training for non-CSIRT staff, providing summaries on emerging security threats, testing and deployment of security tools, and assisting security operations with crafting IDS/IPS alerting rules.
Reactive services:
These primarily revolve around responding to incidents as they occur. For the most part, reactive services address the entire incident response process. This includes the acquisition and examination of evidence, assisting in containment, eradication, and recovery efforts, and finally documenting the incident.
CSIRT
Once the incident response charter is completed, the next stage is to start staffing the CSIRT. Larger organizations with sufficient resources may be able to task personnel with incident response duties full-time. More often than not though, organizations will have to utilize personnel who have other duties outside incident response. Personnel who comprise the internal CSIRT can be divided into three categories: core team, technical support, and organizational support. Each individual within the CSIRT fulfills a specific task. Building this capability into an organization takes more than just assigning personnel and creating a policy and procedure document. Like any major project initiative, there is a good deal of effort required in order to create a functional CSIRT.
For each of the CSIRT categories, there are specific roles and responsibilities. This wide range of personnel is designed to provide guidance and support through a wide range of incidents ranging from the minor to the catastrophic.
CSIRT core team
The CSIRT core team consists of personnel who have incident response duties as their full-time job or assume incident response activities when needed. In many instances, the core team is often made up of personnel assigned to the information security team. Other organizations can leverage personnel with expertise in incident response activities. The following are some of the roles that can be incorporated into the core team:
Incident response coordinator
: This is a critical component of any CSIRT. Without clear leadership, the response to a potential incident may be disorganized or with multiple individuals via for control during an incident, a chaotic situation that can make the incident worse. In many instances, the incident response coordinator is often the c
hief security officer (CSO
), c
hief information security officer
(
CISO
), or the i
nformation security officer
(
ISO
) as that individual often has overall responsibility for the security of the organization's information. Other organizations may name a single individual who serves as the incident response coordinator. The incident response coordinator is responsible for management of the CSIRT prior to, during, and after an incident. In terms of preparation, the incident response coordinator will ensure that any plans or policies concerning the CSIRT are reviewed periodically and updated as needed. In addition, the incident response coordinator is responsible for ensuring that the CSIRT team is appropriately trained and oversees testing and training for CSIRT personnel. During an incident, the incident response coordinator is responsible for ensuring the proper response and remediation of an incident and guides the team through the entire incident response process. One of the most important of these tasks during an incident is coordination of the CSIRT with senior leadership. With the stakes of a data breach high, senior leadership such as the Chief Executive Officer will want to be informed of the critical information concerning an incident. It is the responsibility of the incident response coordinator to ensure that the senior leadership is fully informed of the activities associated with an incident. Finally, at the conclusion of an incident, the incident response coordinator is responsible for ensuring that the incident is properly documented and that reports of the CSIRT activity are delivered to the appropriate internal and external stakeholders. In addition, a full debrief of all CSIRT activities is conducted and lessons learned are incorporated into the CSIRT Plan.
CSIRT Senior Analyst(s)
: CSIRT Senior Analysts are personnel with extensive training and experience in incident response and associated skills such as digital forensics or network data examination. They often have several years of experience conducting incident response activities as either a consultant or as part of an enterprise CSIRT. During the preparation phase of the incident response process, they are involved in ensuring that they have the necessary skills and training to address their specific role in the CSIRT. They are also often directed to assist in the incident response plan review and modification. Finally, senior analysts will often take part in training junior members of the team. Once an incident has been identified, the senior analysts will engage with other CSIRT members to acquire and analyze evidence, direct containment activities, and assist other personnel with remediation. At the conclusion of an incident, the senior analysts will ensure that both they and other personnel appropriately document the incident. This will include the preparation of reports to internal and external stakeholders. They will also ensure that any evidence is appropriately archived or destroyed depending on the incident response plan.
CSIRT Analyst(s)
: The CSIRT Analysts are personnel with CSIRT responsibilities that have less exposure or experience in incident response activities. Oftentimes, they have only one or two years of responding to incidents. As a result, they can perform a variety of activities with some of those under the direction of senior analysts. In terms of preparation phase activities, analysts will develop their skills via training and exercises. They may also take part in reviews and updates to the incident response plan. During an incident, they will be tasked with gathering evidence from potentially compromised hosts, from network devices, or from various log sources. Analysts will also take part in the analysis of evidence and assist other team members in remediation activities.
Security operations center analyst
: Larger enterprises may have an in-house or contracted 24/7 S
ecurity Operations Center (SOC)
monitoring capability. Analysts assigned to the SOC will often serve as the point person when it comes to incident detection and alerting. As a result, having an SOC analyst as part of the team allows them to be trained on techniques and serve as an almost immediate response to a potential security incident.
IT Security Engineer / Analyst(s)
: Depending on the size of the organization, there may be personnel specifically tasked with the deployment, maintenance, and monitoring of security-related software such as anti-virus or hardware such as firewalls or SIEM systems. Having direct access to these devices is critical when an incident has been identified. The personnel assigned these duties will often have a direct role in the entire incident response process. The IT Security Engineer or Analyst will often have a large piece of the preparation component of the incident response process. They will be the primary resource to ensure that security applications and devices are properly configured to alert to possible incidents and to ensure that the devices properly log events so that a reconstruction of events can take place. During an incident, they will be tasked with monitoring security systems for other indicators of malicious behavior. They will also assist the other CSIRT personnel with obtaining evidence from the security devices. Finally, after an incident, these personnel will be tasked with configuring security devices to monitor for suspected behavior to ensure that remediation activities have eradicated the malicious activity on impacted systems.
Technical support personnel
Technical support personnel are those individuals within the organization who do not have CSIRT activities as part of their day-to-day operations, but rather have expertise or access to systems and processes that may be affected by an incident. For example, the CSIRT may need to engage a server administrator to assist the core team with acquiring evidence from servers such as memory captures or logs. Once completed, the server administrator's role is finished and they may have no further involvement in the incident. The following are some of the personnel that can be of assistance to the CSIRT during an incident:
Network Architect/Administrator
: Often, incidents involve the network infrastructure. This includes attacks on routers, switches, and other network hardware and software. The Network Architect or Administrator is vital for insight into what is normal and abnormal behavior of these devices as well as identifying anomalous network traffic. In incidents where the network infrastructure is involved, these support personnel can assist with obtaining network evidence such as access logs or packet captures.
Server Administrator
: Threat actors often target systems within the network where critical or sensitive data is stored. These high-value targets often include domain controllers, file servers, or database servers. Server Administrators can aid in acquiring log files from these systems. If the server administrator(s) are also responsible for the maintenance of the active directory structure, they may be able to assist with identifying new user accounts or changes to existing user or administrator accounts.
Application support
: Web applications are a prime target for threat actors. Flaws in coding that allow for attacks such as SQL injection or security misconfigurations are responsible for some security breaches. As a result, having application support personnel as part of the CSIRT allows for direct information related to application attacks. These individuals will often be able to identify code changes or to confirm vulnerabilities discovered during an investigation into a potential attack against an application.
Desktop support
