Forensic investigations can be triggered from several types of events generated by a variety of security controls. Whether they originate because of human watchfulness, rule matching in an intrusion prevention system (IPS), or modification of data alerted on file integrity monitoring (FIM), organizations must demonstrate an acceptable level of due diligence by ensuring they review each event as it is generated.
While reviewing events, security analysts need to quickly assess the level of risk to the organization and decide whether a full forensic investigation needs to be initiated. The criteria for deciding when an event becomes an investigation should not be simply left to the judgment of the security analyst; a series of policies and procedures must be established to clearly define when this escalation is performed. At the point an investigation is initiated, the governance documentation should already include detailed information for how to proceed and who should be involved.
A forensic investigation can be initiated from several types of events or incidents. Like how the digital forensic readiness model, as illustrated in Figure 13.1, provides a consistent and repeatable workflow for conducting a forensic investigation, the way in which organizations manage their incidents should also follow a consistent, repeatable, and structured workflow framework.
Incident management consists of several phases through which specific activities are performed to mitigate the impact of the incident by containing it and ultimately recovering from it. Illustrated in Figure 13.2, there are four major phases within the incident management lifecycle, each containing a subset of activities and steps that must be performed. Typically, the phases of an incident management lifecycle are completed in sequence and, like that of the forensic readiness model, may require that preceding phases be revisited as new events or findings are detected, a situation making it very much a lifecycle.
Figure 13.1 High-level digital forensic process model.
Figure 13.2 Incident management lifecycle.
Integrating the Digital Forensic Readiness Model
When an incident has been declared, organizations must consider the ramifications of their actions on potential digital evidence, with respect to its admissibility in a court of law, as they work through the incident management lifecycle. Illustrated in Figure 13.3, the activities and steps performed during incident response have a direct and collateral effect on the organization’s ability to support and conduct a forensic investigation.
Figure 13.3 Incident response—forensic readiness integration.
Those members of the incident response team (IRT) responsible for performing forensic activities need to have knowledge of the principles, methodologies, procedures, tools, and techniques that apply throughout each phase of the incident management lifecycle. Not only does having this knowledge facilitate more efficient and effective response to incidents, it also ensures that the actions taken during incident handling and response will not interfere with the authenticity and integrity of digital evidence.
Included throughout the sections below, the integration points between each incident response phase and digital forensics have been specified.
Incident Handling and Response
There are four major phases included as part of the incident management lifecycle:
• Preparation (initiation)
• Respond (detection & analysis)
• Restore (containment, eradication, & recovery)
• Learn (post-incident)
The activities and steps performed in some of these lifecycle phases are common to all security incidents, such as when a detected incident has been validated and the IRT moves towards containment actions, while in some incidents there are activities and steps that may not be performed, such as when a detected incident has been invalidated and the IRT moves towards recovery actions.
Making effective use of the incident management lifecycle requires that organizations minimize the number of ad hoc decisions and subjective judgments being made during an incident. Not only will this facilitate reducing stress related to potentially making an incorrect decision, but it also provides organizations with a comprehensive methodology that is demonstrably consistent and repeatable when challenged in a court of law.
The incident management lifecycle starts by completing activities that ultimately enable the organization to effectively respond and handle incidents. This is the most critical phase of the entire lifecycle because it establishes a foundation for how the subsequent phases will be executed within the capabilities throughout the organizations.
One of the first actions that should be to taken is to specify as part of a taxonomy, discussed further in Addendum D, “Building a Taxonomy,” what the organization defines as an event and an incident. Doing this as the first step provides a clear scope so that further decisions can be made as to roles and responsibilities, team structures, and escalation workflow criteria.
An event is any observable occurrence. Events can be physical or technical in nature such as a user accessing a restricted area or a firewall blocking a connection attempt. Additionally, an adverse event is a specific type of event that results in a negative consequence such as system failures, malware execution, or data exfiltration.
An incident is any violation or imminent threat of violating the organization’s policies, standards, or guidelines. Examples of incidents are:
• A distributed denial of service (DDoS) attack resulting in system failures
• The release of confidential or sensitive information to unauthorized parties
Policies, Plans, and Procedures
Organizing an effective incident handling and response capabilities requires organizations to establish formal incident management policies, plans, and procedures before an incident occurs.
This series of documentation must emphasize how interactions throughout the organization, as well as with external parties such as law enforcement, will be conducted.
Policies At the highest level, policies are built as formalized blueprints used to describe the organization’s goals specific to incident management. These documents address general terms and are not intended to contain the level of detail found in the plans and procedures that are created afterwards.
While the contents of these documents will be subjective to the organization’s individual incident management needs, the following elements are commonly used across all policy implementations:
• Statement of management commitments to incident management
• Purpose and objective for creating the policy
• Scope of to whom, how, and when the policy applies
• Inclusion of, or reference to, the organization’s taxonomy which is used to define common terms and language
• Prioritization or severity ranking of incidents
• Escalation and contact information
• Organizational structure, including roles and responsibilities, chain of command, and information sharing rules
Plans Building off policies, plans are the documents that formally outline the focused and coordinated approach to incident management. It is important for each organization to have a plan that is implemented to meet their unique requirements and provide the roadmap for how they will implement their incident response capabilities.
In addition to describing the resources and management support required, this document should also include the following components:
• Mission, strategies, and goals for incident management
• Approach and methodology used to support incident management
• Communication and information sharing plan
• Stakeholder (e.g., management) approval of the document
• Service level objectives (SLO) used to measure performance
• Roadmap for maturing incident management capabilities
Procedures Standard operating procedures (SOP) should be created and maintained based on the organization’s implementation of governing policies, plans, and staffing models. Contained within these SOP documents should be comprehensive and detailed technical processes, checklists, and forms that will be used for handling and responding to an incident following digital forensics principles, methodologies, and techniques.
The goal for creating these SOP documents is to provide a consistently repeatable process that are relevant to all incidents and that can be accurately applied to all forensic activities throughout. Suggested components for an SOP document, including the requirements for digital forensics, are presented throughout the incident handling and response phases in the sections to follow.
An IRT should always be readily available for anybody who identifies or suspects that an event within the organization has occurred. Beyond the availability of incident management documentation, the success of the IRT to analyze events and act appropriately depends on the involvement of key individuals through the organization. Generally, the IRT is responsible for:
• Developing appropriate incident management documentation
• Retaining resources necessary to perform incident management activities
• Investigating the root cause of detected incidents
• Managing digital evidence gathered and processed from the incident
• Recommending countermeasures and security controls (administrative, technical, or physical)
The way in which an IRT is deployed depends largely on the organization’s size. In business environments where operations are centralized to a smaller geographical region, it is quite effective to have a centralized IRT. However, as business environments become more dispersed and operations are scattered across multiple geographic locations, there could be a need to deploy regional IRTs. Where there are multiple IRTs distributed across a larger business environment, it is important that all teams be part of a single coordinated unit so that policies, plans, and procedures are consistently used for incident management throughout the organization.
At the end of the day, the decision to use a centralized or distributed IRT comes down to the cost of deploying the model. Through a cost-benefit analysis, as discussed further in Addendum C, “Cost-Benefit Analysis,” organizations can determine which team model works best for them.
Roles and Responsibilities It is important that there is participation of stakeholders throughout the organization to provide their expertise, judgement, and abilities throughout the incident management lifecycle. While the duties performed by each of these stakeholders may not have direct involvement in conducting incident response or handling related activities, their cooperation is essential to ensuring that the policies, plans, and procedures are consistently followed.
Depending on the size of the organization, not all business areas specified in the list might exist. Where this is the case, it is important that the organization identify people who are experienced in these subject matters so that when an incident occurs, there will be no knowledge gap with how to proceed under certain circumstances.
• Management are ultimately accountable for establishing incident management documentation, budgets, and staffing. They are also held responsible for coordinating incident response and handling capabilities amongst stakeholders and dissemination of information.
• Information security resources provide supplementary support during distinct stages of the incident response and handling activities, such as validating security controls (e.g., firewall rules).
• Information technology (IT) support and administration resources have the most intimate knowledge of the technology they manage daily. This expertise is important to have when ensuring that appropriate actions are taken for affected assets; such as the proper sequence for shutting down critical systems.
• Forensic practitioners are knowledgeable in the scientific principles, methodologies, and techniques, and are equipped with tools to ensure that incident response activities preserve the forensic viability and admissibility of digital evidence for use in a court of law.
• Legal experts should review all incident management documentation to ensure the organization is compliant with applicable laws, regulations, guidance, and the right to privacy. Furthermore, their expertise should also be sought when it is believed that an incident will have some form of legal ramifications, such as prosecution of perpetrators or the creation of binding agreements for external information sharing.
• Public and corporate affairs will facilitate, depending on the nature and context of the incident, the communication and sharing of information with external parties (e.g., media) and the public.
• Human resources and employee relations mediate disciplinary proceedings when an employee is suspected of being involved with the incident.
• Business continuity planning ensures that all incident management documentation is aligned and consistent with the organization’s business continuity practices. During an incident, their expertise can be used to help minimize operational disruptions and assist with communication. Additionally, these people should be made aware of the impact resulting from incidents so they can revise documentation accordingly, such as business impact and risk assessments.
When an incident occurs, those individuals throughout the organization who have a vested interest in the process must be kept readily informed of what is happening. This requires that throughout each phase of the incident management lifecycle, the IRT must ensure they provide adequate and timely information about the incident.
Communication plans should account for the dissemination of information to a wide variety of audience, across many different delivery channels (e.g., in person, email, paper), and be formatted based on the intended audience (e.g., other IRTs, management, stakeholders). Not only should information be communicated on a periodic basis (e.g., hourly updates, daily summary), but it should also be made available when requested on a “need to know” basis.
Recording and distributing information about an incident should be limited to specific IRT members, sometimes referred to as scribes, whose responsibility is solely communication and escalations. These individuals work closely with other members of the IRT team(s) to document the activities, steps, and progress through the incident management lifecycle and ensure that accurate and appropriate information is provided to those need it.
External Information Sharing From time to time, organizations may need to share information with a variety of external parties such as law enforcement, media, industry experts, and so on. When required, key stakeholders throughout the organization—such as legal, executive management, and public/corporate affairs—should always be consulted prior to the dissemination of any information to external parties. Without having these teams involved to determine how and to what level of detail information can be shared, there is a risk that sensitive or confidential information could be disclosed to unauthorized individuals.
When required, the IRT may need to escalate specific activities about the incident to highlight issues so that appropriate individuals can respond and provide the required level of resolution. Most commonly, escalations are used during incident response to re-prioritize, reassign, or monitor specific activities or actions so normal business operations, functions, and services can be restored as quickly as possible. Escalations can typically be grouped into one of the following categories:
Hierarchical Escalation Hierarchical escalations are used to ensure that attention is given to the necessary actions for resolving an issue. During a hierarchical escalation, the focus is placed on following the documented chain of command until a resolution is achieved.
In Figure 13.4, an example of this can be seen during security monitoring where the first-level analysts complete the initial event triage and if they are unable to resolve the issue it is escalated to the second-level analysts, and so on until it is resolved.
Figure 13.4 Hierarchical escalation.
Functional Escalation Functional escalations are used to ensure that issue resolution is achieved within a given SLO. During a functional escalation, the focus is placed on the priority for resolving the issue because of the combined importance and urgency.
Illustrated in Figure 13.5, a priority matrix demonstrates how priority can be determined to resolve issues within a given SLO.
Escalations should not be predominantly used as a means of deviating from established incident management processes. This typically happens when an organization incorrectly or vaguely defines when an escalation is to be used during the incident management lifecycle, and the IRT will not know under what circumstance they should initiate an escalation, with whom they should communicate, and how they are to perform the escalation. Examples of when an escalation can be triggered under both categories specified previously include the following:
• Evidence of a reportable crime exists.
• Evidence indicates a fraud, theft, or other loss.
• The estimate of possible damage exceeds a specified threshold.
• Potential for embarrassment or reputational damage exists.
• Immediate impact to customers, partners, or profitability is imminent.
• Recovery plans have been invoked or are necessary.
• The incident is reportable under legal or compliance requirements.
Figure 13.5 Functional escalation.
The use of escalations should be limited to specific circumstances as defined in the incident management documentation. To ensure escalations are only performed when required, the IRT should include a decision maker, such as the incident manager, who will decide whether an escalation is required.
One of the most challenging aspects of the incident management lifecycle is accurately detecting and assessing potential incidents, primarily because incidents can originate from many different attack vectors such as loss/theft of equipment or lack of employee awareness.
While the established SOP supports a consistent and repeatable process for responding to all incidents, the way in which organizations handle each incident varies. Contained with the scope of this phase, activities and steps performed are focused primarily on the detection and analysis of incidents as they are received.
Incidents can be detected through many sources other than the targeted security monitoring capabilities discussed previously in Chapter 12, “Enabling Targeted Monitoring.” Regardless, the indicators of an incident can be grouped into one of the following categories:
• Precursor incidents are those events that imply that an incident may occur in the future.
• Indicator incidents are those events that signify that an incident has or is occurring now.
With both categories of events, organizations need to use supplemental information, as discussed further in Chapter 9, “Determine Collection Requirements,” to prevent an impending incident from escalating and further impacting business operations.
Generally, assessing incidents would be relatively simple if precursor and indicator events were guaranteed to always be accurate. However, even when events are confirmed to be accurate, it does not necessarily signify that an incident will or is about to occur. For this reason, it is important that those individual(s) responsible for completing the initial triage determine if the event(s) is true-positive or false-positive. This validation is a crucial step in determining what activities and steps will be performed next, such as whether to contain the incident or move directly into recovery activities.
Where initial validation corroborates the existence of an incident, the IRT must work quickly to prioritize and understand the context surrounding the incident. The following techniques are examples of recommended techniques that can effectively reduce the complexity of incident analysis:
• Profiling is characterizing activity so that unknown or abnormal activity can be more easily identified. Examples of profiling techniques that can be used during incident analysis include file integrity monitoring, discussed further in Chapter 10, “Establishing Legal Admissibility,” and misuse/anomaly/specification-based detection, discussed further in Chapter 12, “Enabling Targeted Monitoring.”
• Maintaining an information knowledge base, such as centralized incident and case management solutions, is important so that it is readily available for the IRT to reference quickly during an incident. The knowledge base should contain a variety of information that can be used to assess an incident, including the following:
• Observables are the resulting outputs that might be or have been seen across an organization (e.g., service degradation).
• Indicators describe one or more observable patterns that, combined with other relevant and contextual information, represent artifacts and/or behaviors of interest (e.g., file hashes).
• Incidents are distinct instances of indicators that are affecting an organization accompanied by information discovered or decided upon during an investigation.
• Adversary tactics, techniques, and procedures (TTP) are the attack patterns, tools, exploits, infrastructure, victim targeting, and other methods used by the adversary or attacker.
• Exploit targets are vulnerabilities, weaknesses, or configurations that might be exploited.
• Courses of action are specific countermeasures taken as corrective or preventative response actions to address an exploit target or mitigate the potential impact of an incident.
• Campaigns are instances of threat actors that are performing a set of TTPs or incidents potentially seen across an organization.
• Threat actors are malicious adversaries with intent and observed behaviors that represent a threat to an organization.
• Internet search engines can help the IRT find information about similar incidents or perpetrators. When performing Internet research, it is important to use systems that are not directly associated or connected with the organization so that anonymity can be maintained. Additionally, by using throwaway systems, such as a virtual machine, organizations can avoid the potential of their searches being tracked or correlated by always using a system that operates within a pre-established and known condition and/or state.
Following the analysis and assessment of an incident, the most critical decision to be made by the IRT is establishing incident priority. As a rule of thumb, incidents that have been assessed should be handled by priority and not on a first-come-first-served basis, as in how a hospital’s emergency department (ED) might operate. Prioritizing incidents can be achieved by using the following factors:
Functional Impact Incidents targeting an organization’s information technology (IT) assets typically impact the organization. The IRT should consider not only the immediate negative impact to the business, but also the likelihood of future impact if the incident is not contained.
See Table 13.1 for criteria related to prioritizing incidents that have a functional impact.
Informational Impact Incidents can affect the security properties of an organization’s information, including confidentiality, integrity, availability, authentication, authorizations, and nonrepudiation. The IRT must consider the implications of sensitive or confidential information potentially being exfiltrated because of the incident.
See Table 13.2 for criteria related to prioritizing incidents that have an informational impact.
Table 13.1 Functional Impact Prioritization
Category | Criteria |
None | No effect to business operations, functions, or services |
Low | Minimal effect to business operations, functions, or services; no critical services have been impacted |
Medium | Moderate effect to business operations, functions, or services; a subset of critical services have been impacted |
High | Significant effect to business operations, functions, or services; all critical services have been impacted |
Table 13.2 Informational Impact Prioritization
Category | Criteria |
None | No information was exfiltrated, lost, or otherwise compromised. |
Privacy breach | Sensitive information was exfiltrated, lost, or otherwise compromised (e.g., personally identifiable information [PII]). |
Proprietary breach | Internal information was exfiltrated, lost, or otherwise compromised (e.g., architectural diagrams). |
Integrity breach | Sensitive or proprietary information was exfiltrated, lost, or otherwise compromised (e.g., financial records). |
Table 13.3 Recoverability Impact Prioritization
Category | Criteria |
Regular | Restoration time is predictable and can be achieve using existing resources. |
Supplemented | Restoration time is predictable but requires additional resources. |
Extended | Restoration time is unpredictable and requires assistance from existing, additional, and external resources. |
Not recoverable | Restoration time is unpredictable and not realistically possible. |
Recoverability Impact Incidents can result in varying levels of impact to assets and operations. In some instances, it may be possible to quickly recover from an incident; however, in other incidents additional resources might be required to facilitate the restoration of business assets and operations throughout the organization. See Table 13.3 for criteria related to prioritizing incidents that have recoverability impact.
Once the criteria for prioritizing incidents have been established, the IRT needs to ensure that they notify and escalate, if required, to the appropriate stakeholders. Further details about requirements for notification and escalation have been specified in the following sections of this chapter.
Once an incident has been responded to, appropriate actions must be taken to mitigate any further impact on the organization and start working to recover business operations, functions, and services.
While the established SOP documentation supports a consistent and repeatable process for restoring business operations, functions, and services, the ways in which an organization contains and eradicates each incident vary.
Within the scope of this phase, activities and steps performed are focused primarily on the containment and eradication of the incident and subsequent recovery of business operations, functions, and services.
Before an incident can intensify further, organizations need to determine the appropriate strategies for controlling the impact of the incident beyond the assets and resources it has already affected. Every incident varies in context, and because of these variations there is no single containment strategy that can be used across the board. Ultimately, deciding which containment strategy works best for controlling impact beyond the currently affected assets and resources requires organizations to understand the context under which the incident occurred. Examples of criteria that can be used to select an appropriate containment strategy include the following:
• Functional, informational, and recoverability prioritization
• Potential damage to or theft of assets and resources
• Effectiveness of the containment strategy
• Time required to implement the containment strategy
Although the IRT’s primary goal is to select a containment strategy that will assist in eradication of and recovery from the incident, careful consideration must be given to the need for preserving potential digital evidence for legal proceedings. Once the containment strategy has been selected, such as shutting down systems or isolating network segments, the IRT must ensure potential digital evidence is gathered and preserved in the order of the data’s volatility rating.
Generally, the more volatile data within a system is, the more challenging it is to forensically gather it because it is only available for a specific amount of time. The ability to gather potential digital evidence prior to implementing a containment strategy comes with inherent risk because the longer it takes to make a decision, the greater the risk of the incident intensifying and digital evidence being lost.
When deciding to preserve volatile data, it is important to keep in mind that the more volatile the data is, the greater is a need for knowledgeable individuals and specialized tools to ensure the data is gathered and preserved in a forensically sound manner. See Table 13.4 for the order of volatility for digital evidence, ordered from most volatile to least volatile.
After a containment strategy has been implemented, work can begin to remove the elements of the incident from where they exist throughout the organization. Now, it is important that all affected assets and resources have been identified and remediated to ensure that, when containment measures are removed, the incident does not come back or propagate further through the organization.
Recovery efforts that follow eradication involve restoring assets and resources to their normal and fully functional state, such as changing passwords, restoring data from backups, or installing patches. Recovery should be completed following the eradication of an incident’s impact from an asset or resource, not in parallel. By completing these tasks through a phased approach, organizations can prioritize removing the threats from their environment as quickly as possible, then focusing on keeping the organization as secure as possible for the long term.
Table 13.4 Order of Volatility
Lifespan | Storage Type | Data Type |
As short as a single clock cycle | CPU storage | Registers |
Video | RAM | |
Until host is shut down | System storage | RAM |
Kernel tables | Network connections | |
Login sessions | ||
Running processes | ||
Open files | ||
Network configurations | ||
System date/time | ||
Until overwritten or erased | Non-volatile data | Paging/swap files |
Temporary/cache files | ||
Configuration/log files | ||
Hibernation files | ||
Dump files | ||
Registry | ||
Account information | ||
Data files | ||
Slack space | ||
Removable media | Floppy disks | |
Tapes | ||
Optical disc (read/write only) | ||
Until physically destroyed | Optical disc (write only) | |
Outputs | Paper printouts |
Every incident varies in context and most often includes a new threat, attack vector, or threat actor that the IRT has not previously accounted for in their incident management program. However, the most commonly overlooked and disregarded phase of the incident management lifecycle involves learning from the incident.
By holding a “lessons learned” meeting with all stakeholders after an incident, the organization can identify additional controls to improve the organization’s security posture and enhance the IRT’s capabilities for future incidents. This meeting is the organization’s opportunity to close the incident and review specific details, including:
• What happened and at what time(s)?
• How well did stakeholders and the IRT deal with the incident?
• Were incident management processes and procedures followed?
• Did incident management documentation contain adequate information?
• Did any activities, steps, or actions inhibit restoring business operations?
• How could notification, escalation, and information sharing be improved?
Following the completion of activities in this phase, the incident management lifecycle resets to the preparation phase. When this happens, the outputs from the post-incident activities must be carried forward so the incident response process and accompanying documentation can be revised accordingly to reduce the likelihood of new incidents occurring.
The Incident Response Team (IRT)
Within the incident response team (IRT), there will most likely be a combination of technical and business representatives who all have an interest in mitigating the business impact. An IRT should always be readily available to respond and work to mitigate potential business impact from an incident. Generally, the IRT is responsible for:
• Developing appropriate incident management documentation
• Retaining resources necessary to perform incident management activities
• Investigating the root cause of detected incidents
• Managing digital evidence gathered and processed from the incident
• Recommending countermeasures and security controls (administrative, technical, or physical).
The ways in which the IRT is implemented depends largely on the organization’s characteristics, such as geography, size, and business functions. For example, in some enterprises the IRT might be contained to a single and centralized location where all incident response capabilities are managed. Alternatively, some organizations may decide to implement regional IRTs across separate locations to support needs in various areas while maintaining a single coordinated governance structure.
In either case, it is important that the IRT have stakeholders representing different key business environments so that the necessary expertise, skills, and decision-making capabilities can be fully utilized. For example, depending on the organization, the following expertise may be needed in the incident management lifecycle:
• Management personnel are responsible for establishing documentation, providing funding, and allocating resources. Ultimately, they are accountable for coordinating incident response capabilities amongst all stakeholders and for the distribution of information.
• Information security (IS) personnel provide supplementary support throughout the incident response workflow, such as validating security controls (e.g., firewall rules, intrusion prevention signatures).
• Information technology (IT) personnel have the most intimate knowledge of systems and the potential impact to them from incident response activities, such as the sequence for shutting down critical systems.
• Legal personnel should review all documentation to ensure the organization is compliant with applicable laws, regulations, standards, and the right to privacy. Additionally, these individuals must be engaged when there is potential for some type of legal ramifications associated with the incident, such as prosecution of perpetrators.
• Public and corporate affairs personnel facilitate, depending on the incident, communicate and share information with external parties (e.g., the media).
• Human resource and employee relations personnel mediate disciplinary proceedings where violation of corporate governance (e.g., business code of conduct) has occurred and an employee is involved.
• Business continuity planning personnel ensure documentation is aligned and consistent with the organization’s ability to continue its business operations. Their expertise can be used to help minimize operational disruptions and assist with communication.
In addition to having stakeholder representation from key business lines, every successful IRT has clearly defined roles for critical functions during an incident. For example, every IRT should have individuals placed in the following roles:
• The team lead oversees all activities performed during the incident. This role is also responsible for coordinating the review of all actions taken during phase #4, which can lead to changes in documentation and how incidents are handled going forward.
• The incident lead has ownership over the immediate incident and oversees coordinating all incident response activities. All communication about the incident is coordinated through this role to ensure accurate and timely dissemination of information.
• Associate members are those individuals who form the IRT as representatives from different business lines. Their involvement and roles can vary depending on the nature of the incident.
• Scribes are persons who track all activities and document the actions taken throughout the entire incident. Depending on the nature of the incident, multiple scribes might be necessary to capture a complete and comprehensive register of all activities and actions taken.
The Role of Digital Forensics During an Incident
Digital forensics individuals are those with knowledge in the scientific principles, methodologies, and techniques of the discipline. They are equipped with knowledge, experience, and tools necessary to ensure that activities performed during the incident response workflow preserve the forensic viability and legal admissibility of digital evidence.
Generally, the role of digital forensics within the IRT can be two-fold: the first being that of an advisor (or consultant) to ensure the team addresses concerns of preserving digital evidence; and the second being the technical professional who leads the activities to gather and process digital evidence. Whether these roles are held by a single individual or split amongst multiple people is completely dependent on the nature of the incident, size of the organization, and overall maturity of the organization’s incident response capabilities. In circumstances where the incident necessitates having the role of digital forensic resources separated, the following must be considered during the incident response workflow.
People in this role are technically hands-on when it comes to gathering digital evidence during an incident. These individuals must demonstrate the knowledge and skills necessary for applying the fundamental principles, methodologies, and techniques of digital forensics so that gathered evidence is forensically sound and legally admissible.
People in an advisory role are technically hands-off all activities directly involving the gathering of digital evidence. These individuals must demonstrate a thorough understand of the fundamental principles, methodologies, and techniques so that they can correctly instruct and influence key decision making during the incident response workflow.
In circumstances where there is need to have a single digital forensic resource assigned to the incident, this individual will be responsible for switching between practitioner and advisory roles. In this situation, the role demands for these individuals to guide the IRT through decision-making processes as well become hands-on when it comes time to gather digital evidence. At times, playing both roles can be daunting and cumbersome when trying to ensure that the IRT does not make rash and uninformed decisions that could potentially impact digital evidence. To mitigate this risk, it is recommended that the advisor and practitioner roles be performed individually through any combination of internal (i.e., employees) and external (i.e., professional services) resources based on cost, skills, response time, and data sensitivity.
Further discussions about education and training relating to digital forensics can be found in Chapter 14, “Establish Continuing Education.”
The logical flow from the time when the initial event occurs requires organizations to follow a consistent and repeatable incident handling and response process that encompasses several stages of information gathering (e.g., preserving digital evidence, conducting interviewing), communication (e.g., stakeholder reporting, escalations), and documentation (e.g., SOPs, incident or case management knowledge base).
The goal of following a logical investigative process, made up of clear and concise workflows, is to reduce the potential for rushed and uninformed decisions being made during incident handling and response. However, understanding that the context of every incident is different, the investigative workflow should still provide those involved with the ability to make the best and most educated decision for what actions are performed next.
Before an incident is escalated into an investigation, the IRT should have collected sufficient information to assess the impact of this decision on the organization, including the following:
• Can an investigation proceed at a cost that is proportional to the size of the incident?
• How can an investigation reduce the impact to business operations, functions, and services?
Understanding that each organization varies in how they will build their investigative workflow, the diagrams provided in the “Templates” section of this book can be used as a reference for starting to build a logical investigative workflow process.
Types of Security Investigations
Conducting digital forensic investigations in the private sector is not much different from conducting them in the public sector. For example, in both the private and public sectors, digital evidence can be gathered and processed to support some type of criminal allegation; however, in the private sector there can also be a need for digital evidence based on corporate asset abuse or policy violations. Generally, most security events and incidents that require organizations to conduct a forensic investigation involve the misuse or abuse of informational assets or systems where potential sources of evidence can be located across many disparate technologies.
Typically, there are several business scenarios where digital forensics can be leveraged to effectively manage an organization’s business risk; refer to Chapter 5, “Digital Forensics as a Business,” Depending on how an organization implements and integrates their digital forensic capabilities, the following are examples of different security investigations that can be encountered:
• Data breach involves access to and dissemination of informational assets to unauthorized entities.
• Email abuse involves the transmission of content that is outside the scope of acceptable usage as defined by the organization’s enterprise governance framework (i.e., acceptable use policy).
• Inappropriate activity involves access to and rendering of contraband content (e.g., pornography, pirated media).
• Internet abuse involves access to and transmission of content that is outside the scope of acceptable usage as defined by the organization’s enterprise governance framework (i.e., acceptable use policy).
• Intrusion attempts involve efforts to gain unauthorized access to informational assets or systems.
• Malware infections involve the installation and execution of malicious code.
• Unauthorized access involves access to informational assets or systems without approval or delegated privilege.
As the investigation proceeds and evidence is processed, it is important to know how to distinguish between civil and criminal violations. Because any civil investigation can become a criminal investigation, it is critical that all digital evidence be handled following documented, repeatable, and consistent methodologies and techniques; refer to Chapter 3, “Digital Evidence Management,” for further discussion.
Forensic investigations are most commonly triggered because of some type of incident, whether an event was detected through security monitoring, a subpoena was received for legal proceeding, or theft/loss of an asset occurred. Regardless, the logical investigative workflow used to handle and respond to all incidents must be well-defined to reduce incorrect decision making but flexible enough to support a variety of incidents as they occur. In any case, organizations must ensure that their governance framework supports consistent and repeatable actions that can be used throughout their entire incident management capabilities.