Lecture 12 – Incident Response & Digital Forensics

Incident Response
-​ A cyber attack is deliberate exploitation of computer systems and networks typically using malicious
software (malware) to compromise data or disable operations.
-​ Cyber attacks enable cyber-crimes like information theft, fraud and ransomware schemes.
-​ In the fields of computer security and information technology, Computer Security Incident
Management, otherwise known as Incident Response, involves the monitoring and detection of
security events on a computer or computer network, and the execution of proper responses to those
events. Computer Security Incident Management is a specialised form of Incident Management,
the primary purpose of which is the development of a well understood and predictable response to
damaging events and computer intrusions.
-​ Organising an effective Computer Security Incident Response Capability (CSIRC) involves several
major decisions and actions. One of the first considerations should be to create an
organisation-specific definition of the term “incident” so that the scope of the term is clear. The
organisation should decide what services the incident response team should provide, consider which
team structures and models can provide those services, and select and implement one or more
incident response teams.
-​ Incident Response Plan, Policy, and Procedure creation is an important part of establishing a team,
so that incident response is performed effectively, efficiently, and consistently, and so that the team is
empowered to do what needs to be done. The plan, policies, and procedures should reflect the team’s
interactions with other teams within the organisation as well as with outside parties, such as law
enforcement, the media, and other incident response organisations

-​
-​ A Computer Security Incident is a violation or imminent threat of violation of computer security
policies, acceptable use policies, or standard security practices.
-​ Examples of incidents include: • An attacker commands a botnet to send high volumes of
connection requests to a web server, causing it to crash. • Users are tricked into opening a
“quarterly report” sent via email that is malware; running the tool has infected their computers
and established connections with an external host. • An attacker obtains sensitive data and
threatens that the details will be released publicly if the organisation does not pay a
designated sum of money. • A user provides or exposes sensitive information to others through
peer-topeer file sharing services.
-​ First Responder / First Level Review • First person to be on scene or receive notification of an event.
Organisations should provide training to the first responder to recognise and properly react to
emergency circumstances.
-​ Help Desk Ticket (Control) • An electronic document captured in a database and issue
tracking/resolution system
-​ Ticket Owner • Person reporting the event, the principal owner of the assets associated with the
event or the common law or jurisdictional owner
-​ Escalation Report (Control) • First Responder’s documentation for ticket escalation, the Responder
writes this information into the ticket or the log for the event. The ticket references the log for the
event
-​ Second Tier • Senior technical resources assigned to resolve an escalated event
-​ Incident Coordinator • Individual assigned by organisation senior management to assemble the
incident response team, manage and document response to the incident
-​ Investigation Status Report (Control) • Documentation of the current investigation results. The
incident coordinator may document this material in a ticket, log, or an engineer’s journal.
-​ Meeting Minutes (Control) • Documentation of the incident team meeting, the minutes document the
attendees, current nature of the incident and the recommended actions. The incident coordinator may
document this material in the ticket, log or an engineer’s journal
-​ Lock-down Change Control • A process ordered as a resolution to an incident. This process follows
the same authorisation and response requirements as an Emergency Change Control.
-​ Test Report (Control) • This report validates that IT personal have performed all necessary and
available repairs to systems prior to bringing them back online
-​ War Room • A secure environment for review of confidential material and the investigation of a
security incident.
-​ Report to Senior Management (Control) • The incident coordinator is responsible for drafting a
senior management report. The incident coordinator may document this material in the ticket, log or
an engineer’s journal
-​ Sometimes, some organisations will ask the question “Why do I need an Incident Response
Capability?” Attacks frequently compromise personal and business data, and it is critical to respond
quickly and effectively when security breaches occur. The concept of computer security incident
response has become widely accepted and implemented. One of the benefits of having an incident
response capability is that it supports responding to incidents systematically (i.e., following a
consistent incident handling methodology) so that the appropriate actions are taken. Incident
response helps personnel to minimise loss or theft of information and disruption of services caused by
incidents. Another benefit of incident response is the ability to use information gained during incident
handling to better prepare for handling future incidents and to provide stronger protection for
systems and data. An incident response capability also helps with dealing properly with legal issues
that may arise during incidents.
-​ Incident Response Capability, notwithstanding an Incident Response Team, there are at least
three (3) things that are required.
-​ An Incident Response Policy is a policy governing incident response that is highly
individualised to an organisation. Most policies include the same key elements, which are:
-​ Statement of management commitment • Purpose and objectives of the policy • Scope
of the policy (to whom and what it applies and under what circumstances) • Definition of
computer security incidents and related terms • Organisational structure and definition
of roles, responsibilities, and levels of authority ••• This should include the authority of
the incident response team to confiscate or disconnect equipment and to monitor
suspicious activity, the requirements for reporting certain types of incidents, the
requirements and guidelines for external communications and information sharing (e.g.,
what can be shared with whom, when, and over what channels), and the handoff and
escalation points in the Incident Management Process
An Incident Response Policy is a policy governing incident response that is highly
individualised to an organisation. Most policies include the same key elements, which are:
Prioritization or severity ratings of incidents • Performance measures • Reporting and contact
forms
-​ An Incident Response Plan is a formal, focused, and coordinated approach document that
provides the roadmap for implementing an organisations incident response capability.
Each organisation needs a plan that meets its unique requirements, which relates to the
organisation’s mission, size, structure, and functions. The plan should lay out the necessary
resources and management support. The Incident Response Plan should include the
following elements:
-​ • Mission • Strategies and goals • Senior management approval • Organisational
approach to incident response • How the incident response team will communicate with
the rest of the organisation and with other organisations • Metrics for measuring the
incident response capability and its effectiveness • Roadmap for maturing the incident
response capability • How the program fits into the overall organisation.
An organisation’s mission, strategies, and goals for incident response should help in
determining the structure of its incident response capability. The incident response program
structure should also be discussed within the plan. Examples of Incident Response Program
Structures include: • Central Incident Response Team • Distributed Incident Response Teams •
Coordinating Team Once an organisation develops a plan and gains management approval,
the organisation should implement the plan and review it at least annually to ensure the
organisation is following the roadmap for maturing the capability and fulfilling their goals for
incident response.
 -​ Incident Response Procedures should be based on the incident response policy and plan.
Standard Operating Procedures (SOPs) are a delineation of the specific technical processes,
techniques, checklists, and forms used by the incident response team. SOPs should be
reasonably comprehensive and detailed to ensure that the priorities of the organisation are
reflected in response operations. In addition, following standardised responses should minimise
errors, particularly those that might be caused by stressful incident handling situations. SOPs
should be tested to validate their accuracy and usefulness, then distributed to all team
members. Training should be provided for SOP users with the SOP documents used as an
instructional too
-​ An Incident Response Team is not only those under an organisation’s employment, but rather it
consists of many parties, both internally and externally. Organisations often need to communicate
with outside parties regarding an incident, and they should do so whenever appropriate, such as
contacting law enforcement, fielding media inquiries, and seeking external expertise. Incident
Response Teams should discuss information sharing with the organisation’s public affairs office, legal
department, and management before an incident occurs to establish policies and procedures
regarding information sharing. Otherwise, sensitive information regarding incidents may be provided
to unauthorised parties, potentially leading to additional disruption and financial loss. Incident
Response Teams should also document all contacts and communications with outside parties for
liability and evidentiary purposes.

-​ Besides speaking with the media, organisations need to speak with Law Enforcement and Incident
Reporting Organisations One reason that many security-related incidents do not result in convictions is
that some organisations do not properly contact law enforcement. Several levels of law enforcement are
available to investigate incidents: For example, within the United States, the authority is with federal
investigatory agencies (e.g., the Federal Bureau of Investigation [FBI] and the U.S. Secret Service), district
attorney offices, state law enforcement, and local (e.g., county) law enforcement. In Australia, the
Australian Federal Police and State Police are the agencies responsible. Other parties that organisations
should discuss with may include • Information Sharing and Analysis Centres (ISACs) • Organisation’s
Internet Service Provider (ISP) • Owners of an attacking address (found via WHOIS) • Software Vendors •
Other Incident Response Teams • Affected External Parties
-​ The Incident Response Process has several phases. The initial phase involves establishing and training an
incident response team, and acquiring the necessary tools and resources.
-​ During the Preparation Phase, an organisation attempts to limit the number of incidents that will
occur by selecting and implementing a set of controls based on the results of risk assessments.
However, residual risk will inevitably persist after controls are implemented. Detection of security
breaches is thus necessary to alert the organisation whenever incidents occur. In keeping with the
severity of the incident, the organisation can mitigate the impact of the incident by containing it
and ultimately recovering from it. During this Preparation Phase, activity often cycles back to the
 Detection and Analysis Phase, for example, to see if additional hosts are infected by malware
while eradicating a malware incident. After the incident is adequately handled, the organisation
issues a report that details the cause and cost of the incident and the steps the organisation should
take to prevent future incidents
-​ Incident Response Methodologies typically emphasise preparation; not only by establishing an
Incident Response Capability so that the organisation is ready to respond to incidents, but also by
preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.
Although the Incident Response Team is not typically responsible for incident prevention, it is
fundamental to the success of Incident Response Programs.
-​ To prepare to handle incidents, tools and resources need to be available that may be of value
during incident handling. The following are tools and resources that would typically be available in
organisations with an Incident Response Capability.
-​ • Incident Handler Communications and Facilities • Contact information for team
members and others within and outside the organisation • On-call information for other
teams within the organisation, including escalation information • Incident reporting
mechanisms • Issue tracking system • Smartphones • Encryption software to be used for
communications among team members • War room for central communication and
coordination • Secure storage facility for securing evidence and other sensitive mate
-​ • Incident Analysis Hardware and Software • Digital forensic workstations and/or backup
devices to create disk images, preserve log files, and save other relevant incident data •
Laptops for activities such as analysing data, sniffing packets, and writing reports • Spare
workstations, servers, and networking equipment, or the virtualised equivalents • Blank
removable media and removable media with trusted versions of programs to be used to
gather evidence from systems • Portable printer to print copies of log files and other
evidence from non-networked systems • Packet sniffers and protocol analysers to capture
and analyse network traffic • Digital forensic software to analyse disk images • Secure
storage facility for securing evidence and other sensitive materials • Evidence gathering
accessories
-​ Incident Analysis Resources & Mitigation Software • Port lists, including commonly used
ports and Trojan horse ports • Documentation for OSs, applications, protocols, and intrusion
detection and antivirus products • Network diagrams and lists of critical assets, such as
database servers • Current baselines of expected network, system, and application activity •
Cryptographic hashes of critical files to speed up incident analysis, verification, and
eradication • Access to images of clean OS and application installations for restoration and
recovery purposes
-​ Many Incident Response Teams create a jump kit, which is a portable case that contains materials that
may be needed during an investigation. The jump kit should be ready to go at all times. Jump kits
contain many of the same items listed in the bulleted lists on the previous slides. For example, each jump
kit typically includes a laptop, loaded with appropriate software (e.g., packet sniffers, digital forensics).
Other important materials include backup devices, blank media, and basic networking equipment and
cables. The purpose of having a jump kit is to facilitate faster responses. Teams should avoid borrowing
items from the jump kit.
-​ Keeping the number of incidents reasonably low is very important to protect the business processes of an
organisation. If security controls are insufficient, higher volumes of incidents may occur, overwhelming
the Incident Response Team. This can lead to slow and incomplete responses, which translate to a larger
negative business impact (e.g., more extensive damage, longer periods of service and data unavailability).
Although, as stated earlier, Incident Response Teams are generally not responsible for securing resources,
they can be advocates of sound security practices. An Incident Response Team may be able to identify
problems that the organisation is otherwise not aware of; the team can play a key role in risk assessment
and training by identifying gaps.
-​ Although other documents already provide advice on general security concepts and operating system and
application-specific guidelines, the following documents, provide a brief overview of some of the main
recommended practices for securing networks, systems, and applications
-​ • Risk Assessments • Host Security Information • Network Security Information • Malware
Prevention Information • User Awareness and Training Information
-​ Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handling
every incident. Organisations should be generally prepared to handle any incident but should focus on
being prepared to handle incidents that use common attack vectors. Different types of incidents merit
different response strategies.
-​ The following attack vectors are not intended to provide definitive classification for incidents; rather, they
simply list common methods of attack, which can be used as a basis for defining more specific handling
 procedures. • External/Removable Media • Attrition • Web • Email • Impersonation • Improper Usage • Loss
or Theft of Equipment • Other.
-​ Containment is important before an incident overwhelms resources or increases damage. Most incidents
require containment, so it is an important consideration early in the course of handling each incident.
Containment provides time for developing a tailored remediation strategy. An essential part of
containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain
functions). Such decisions are much easier to make if there are predetermined strategies and procedures
for containing the incident. Organisations should define acceptable risks in dealing with incidents and
develop strategies accordingly
-​ Containment Strategies vary based on the type of incident. For example, the strategy for containing an
email-borne malware infection is quite different from that of a network-based DDoS attack. Organisations
should create separate containment strategies for each major incident type, with criteria documented
clearly to facilitate decision-making. Typical criteria for determining the appropriate strategy include •
Potential damage to and theft of resources
-​ • Need for evidence preservation • Service availability (e.g., network connectivity, services provided
to external parties) • Time and resources needed to implement the strategy • Effectiveness of the
strategy (e.g., partial containment, full containment) • Duration of the solution (e.g., emergency
workaround to be removed in four hours, temporary workaround to be removed in two weeks,
permanent solution
-​ In certain cases, some organisations redirect the attacker to a sandbox (a form of containment) so that
they can monitor the attacker’s activity, usually to gather additional evidence. The incident response team
should discuss this strategy with its legal department to determine if it is feasible. Ways of monitoring an
attacker’s activity other than sandboxing should not be used • if an organization knows that a system has
been compromised and allows the compromise to continue, • where it may be liable if the attacker uses the
compromised system to attack other systems. The delayed containment strategy is dangerous because an
attacker could escalate unauthorised access or compromise other systems.
-​ Collecting evidence from computing resources presents some challenges. Although the primary reason for
gathering evidence during an incident is to resolve the incident, it may also be needed for legal
proceedings. In such cases, it is important to clearly document how all evidence, including compromised
systems, has been preserved. Evidence should be collected according to procedures that meet all
applicable laws and regulations that have been developed from previous discussions with legal staff and
appropriate law enforcement agencies so that any evidence can be admissible in court.
-​ In addition, evidence should be accounted for at all times; whenever evidence is transferred from
person to person, chain of custody forms should detail the transfer and include each party’s signature. A
detailed log should be kept for all evidence, including the following:
-​ Identifying information (e.g., the location, serial number, model number, hostname, media access
control (MAC) addresses, and IP addresses of a computer) • Name, title, and phone number of each
individual who collected or handled the evidence during the investigation • Time and date
(including time zone) of each occurrence of evidence handling • Locations where the evidence was
stored.
-​ After an incident has been contained, eradication may be necessary to eliminate components of the
incident, such as deleting malware and disabling breached user accounts, as well as identifying and
mitigating all vulnerabilities that were exploited. During eradication, it is important to identify all affected
hosts within the organisation so that they can be remediated. For some incidents, eradication is either not
necessary or is performed during recovery.
-​ In recovery, administrators restore systems to normal operation, confirm that the systems are functioning
normally, and (if applicable) remediate vulnerabilities to prevent similar incidents. Recovery may involve
such actions as restoring systems from clean backups, rebuilding systems from scratch, replacing
compromised files with clean versions, installing patches, changing passwords, and tightening network
perimeter security (e.g., firewall rulesets, boundary router access control lists). Higher levels of system
logging or network monitoring are often part of the recovery process. Once a resource is successfully
attacked, it is often attacked again, or other resources within the organisation are attacked in a similar
manner
-​ One of the most important parts of incident response is also the most often omitted: learning and
improving. Each incident response team should evolve to reflect new threats, improved technology, and
lessons learned. Holding a “lessons learned” meeting with all involved parties after a major incident, and
optionally periodically after lesser incidents as resources permit, can be extremely helpful in improving
security measures and the incident handling process itself. Multiple incidents can be covered in a single
lesson learned meeting.
 -​

Digital Forensics
-​ Digital Forensics (sometimes known as Digital Forensic Science) is a branch of forensic science
encompassing the recovery and investigation of material found in digital devices, often in relation to
computer crime. The term digital forensics was originally used as a synonym for computer forensics
but has expanded to cover investigation of all devices capable of storing digital data. With roots in
the personal computing revolution of the late 1970s and early 1980s, the discipline evolved in a
haphazard manner during the 1990s, and it was not until the early 21st century that national policies
emerged. Digital Forensics is commonly used in both criminal law and private investigation.
Traditionally it has been associated with criminal law, where evidence is collected to support or
oppose a hypothesis before the courts. As with other areas of forensics this is often a part of a wider
investigation spanning a number of disciplines. In some cases, the collected evidence is used as a
form of intelligence gathering, used for other purposes than court proceedings (for example to locate,
identify or halt other crimes). Digital Forensics is a constantly evolving scientific field with many
subdisciplines. Some of these sub-disciplines are:
-​ Computer Forensics • the identification, preservation, collection, analysis and reporting on
evidence found on computers, laptops and storage media in support of investigations and
legal proceedings
-​ Network Forensics • the monitoring, capture, storing and analysis of network activities or
events in order to discover the source of security attacks, intrusions or other problem incidents,
i.e. worms, virus or malware attacks, abnormal network traffic and security breaches.
-​ Mobile Devices Forensics • the recovery of electronic evidence from mobile phones,
smartphones, SIM cards, PDAs, GPS devices, tablets and game consoles.
-​ Digital Image Forensics • the extraction and analysis of digitally acquired photographic
images to validate their authenticity by recovering the metadata of the image file to ascertain
its history
-​ Digital Audio/Video Forensics • the collection, analysis and evaluation of sound and video
recordings. The science is the establishment of authenticity as to whether a recording is
original and whether it has been tampered with, either maliciously or accidentally
-​ Memory Forensics • the recovery of evidence from the RAM of a running computer, also called
live acquisition
-​ Network Forensics is a critical component for most modern digital forensic, incident response,
and threat hunting work. Whether pursued alone or as a supplement or driver to traditional endpoint
investigations, network data can provide decisive insight into the human or automated
communications within a compromised environment. Network Forensic Analysis techniques can be
used in a traditional forensic capacity as well as for continuous incident response/threat hunting
operations.
-​ Nearly every phase of an attack can include network activity. Understanding an attacker’s actions
during Reconnaissance, Delivery, Exploitation, Installation, Command and Control, and
Post-Exploitation phases can provide deep and valuable insight into their actions, intent, and
capability.
-​ Threat Intelligence often contains network-based indicators such as IP addresses, domain names,
signatures, URLs, and more. When these are known, existing data stores can be reviewed to
determine if there were indications of the intel-informed activity that warrant further investigation.
-​ Network Source Data Types in Digital Forensics include, but are not limited to,
-​ Full-Packet Capture (pcap) • pcap files contain original packet data as seen at the collection
point. They can contain partial or complete packet data.
-​ NetFlow and Related Flow-Based Collections • Flow records contain a summarisation of
network communications seen at the collection point. NetFlow contains no content – just a
summary record including metadata about each network connection. Whether used alone to
determine if communications occurred or in conjunction with other data sources, NetFlow can
be extremely helpful for timely analysis.
-​ Log Files • Log files are perhaps the most widely-used source data for network and endpoint
investigations. They contain application or platform-centric items of use to characterise
activities handled or observed by the log creator
-​ Although there is no single workflow to exhaustively perform network forensic analysis, the most
common and beneficial tasks can generally be placed into the categories below. Note that these
categories are not generally iterative. They are components of a dynamic process that can adapt to
adversaries’ actions
-​ Ingest and Distil • Prepare for analysis and derive data that will more easily facilitate the rest
of the analytic workflow
-​ Reduce and Filter • Reduce large input data volume to a smaller volume, allowing analysis
with a wider range of tools
-​ Analyse and Explore • Identify traffic and artefacts that support investigative goals and
hypotheses
-​ Extract Indicators and Objects • Find artefacts that help identify malicious activity, including
field values, byte sequences, files, or other objects
-​ Scope and Scale • Search more broadly within source data for behaviour that matches known
indicators
-​ Establish Baselines • Identify parameters for “normal” patterns of behaviour to help find
anomalies that need to be investigated
-​ Digital Evidence or Electronic Evidence is any probative information stored or transmitted in
digital form that a party to a court case may use at trial. Before accepting digital evidence, a
court will determine • if the evidence is relevant, • whether it is authentic, • if it is hearsay, and •
whether a copy is acceptable or the original is required
-​ For evidence to be admissible, investigators must follow guidelines carefully. No actions performed
by investigators can change the data in any way. The investigator extracting data must have training
to ensure competence. This professional must also be able to explain the process and the reasons for
it in court, if applicable. Investigators must be able to document the processes performed. A third
party must be able to examine this documentation and follow along to arrive at the same end
result. This is known as repeatable findings. One person on the forensics team must have the
ultimate responsibility for the process, ensuring that the actions of all team members were in
compliance with the law.
-​ According to the National Institute of Standards and Technology (NIST), test results must be
repeatable and reproducible to be considered admissible as electronic evidence.
NIST specifically defines these terms as follows:
-​ Repeatability • refers to obtaining the same results when using the same method on identical
test items in the same laboratory by the same operator using the same equipment within short
intervals of time.
-​ Reproducibility • refers to obtaining the same results being obtained when using the same
 method on identical test items in different laboratories with different operators utilising
different equipment, i.e. different mobile phone, hard drive, and so on
-​ The Federal Rules of Evidence are a set of rules that governs the introduction of evidence at civil
and criminal trials in United States federal trial courts. The current rules were initially passed by
Congress in 1975, after several years of drafting by the Supreme Court. The rules are straightforward
and relatively short, compared to other sets of court rules, such as the Federal Rules of Civil
Procedure. In Australia, the Federal Rules of Evidence equivalent is the Evidence Act of 1995
-​ The Federal Rules of Evidence are broken down into 11 articles: 1. General Provisions 2. Judicial
Notice 3. Presumptions in Civil Actions and Proceedings 4. Relevancy and Its Limits 5. Privileges 6.
Witnesses 7. Opinions and Expert Testimony 8. Hearsay 9. Authentication and Identification 10.
Contents of Writings, Recordings, and Photographs 11. Miscellaneous Rules
-​ During a computer forensics examination there are six (6) separate stages
-​ The Readiness Stage involves training, testing, and verification of any applicable computer
software or equipment. Review of laws and potential issues as well as communication with
clients and preparing a computer system for examination are also included in the Readiness
Stage.
-​ The Evaluation Stage involves receiving and clarifying instructions to ensure understanding.
Evaluation also involves assessing potential risks involved with the examination.
-​ During the Collection Stage, experts extract and examine information from computers. This
process might occur on site or in a forensic laboratory. Members of a team may also collect
physical evidence if any is found, placing items into labelled plastic bags. This process is
colloquially known as Bagging and Tagging
-​ The next stage involves Analysis of the evidence. Team members must analyse, record, and
repeat their analysis to ensure accuracy.
-​ During the Presentation Stage, team members share their findings and address specifics
connected to the purpose of the examination. The report created must be prepared in a way
that the people reading it will understand the information. Often, these people will have limited
technical knowledge. Elaboration and explanation by team members may be necessary to help
people understand the findings.
-​ The final Review Stage involves applying the information gathered. For example, a company
engaging in computer forensics might use the information collected to make policy changes or
to institute stronger network security.
-​ “Bagging and Tagging” is the process of seizing evidence that will be brought off-site for analysis in
a lab environment. This is the point where Chain of Custody documentation begins.
-​ Chain of Custody is a legal term that relates to the process of documenting exactly who was in
custody of evidence, when that change in custody took place, and all attendant circumstances.
Maintaining a well-documented chain of custody is critical to later authenticating the evidence in
court.
-​ A Computer Forensic Investigation begins at the time the first notification comes to the forensic
examiners’ attention. From the outset, information sharing, advice, and incident response must be
efficient and properly handled or evidence can be tainted before the actual examination commences.
If mishandled, the forensic examiner could be subject to a vicious attack on the witness stand, or
even worse, the evidence collected may be rendered inadmissible. Investigators rarely know how a
person under investigation will react when they find out they find out investigators are on their way to
seize their compute
-​ The safety and security of investigators, and the evidence, are the paramount concern from the
beginning. The incident response process can be quite strenuous at times, but attempting to cut
corners and rush through the steps can ultimately lead to unprofessional work and major mistakes.
Painstaking attention to detail, proper evidence handling, and observance of legal restrictions, are a
recipe for professional incident response, a good followup examination, and a strong case in court.
-​ Before entry to a crime scene, the forensic examiner and investigators must gather as much
information as possible about the search scene to reduce the risk of injury to the entry team and to
know as much as possible about the evidence and people inside. Similar to the fundamentals a good
journalist follows, it is essential to first consider the who, what, where, when, why, and how of the
particular situation. Once the team gathers as much intelligence as possible to fully understand the
situation at hand, the forensic team is able to enter the building
-​ Upon entry to the scene, the forensic team must first determine the location of all potential
digital crime scenes. At this point, they touch nothing, being careful to not disturb the evidence in its
state and only assessing the evidence and what immediate preservation procedures must be
 performed. After preserving the evidence, the forensic examiner begins the collection process by
documenting the scene using notes, sketches, videos, or pictures, depending on which medium is
most appropriate and available. The documentation process should be applied to all potential
digital crime scenes. This process might include photographing the screens of running systems and
devices. Most forensic examiners will not only photograph the screen, they will photograph particular
files and applications, along with the back of the computers at various angles to capture exactly how
the cables were plugged into the machine
-​ Many examiners these days will do more, collecting evidence from running systems by saving it over a
network connection or to an attached device. This process requires a higher level of expertise as it may
result in significant changes of the evidence. At this point, by viewing the computer monitor, the forensic
examiner will document the operating system being used, any currently running software, programs, or
open files, and see if there was an encryption program running. Next, after all pertinent information has
been photographed and other relevant information about the computers system state has been
documented, the network connection should be disconnected. This prevents any data from being
destroyed or edited remotely. If the computer is off, the same process of documenting the system state
and connections is performed, and the computer is then prepared for disassembly and transport.
-​ Before getting to the bagging and tagging process however, there are a few other steps that need to be
taken. This include, but are not limited to, • Unix and Linux Shutdown, Power down Procedures • Laptop
and Other Computer Shutdown, Power down Procedures • Examining Hard Drive for Forensic Evidence and
Removing the Hard Drive • Documenting the Hard Drive • Using Write Blockers and Previewing Hard Drive
• Documenting BIOS Time and Date Settings
-​ The first step in seizing evidence during the bag-and-tag process is to plug the network cable back
into the computer. Next, all cables near their terminal end should be labelled and an identical label should
be placed next to its corresponding port. Once all the cables and ports have been properly labelled, the
forensic examiner should again photograph the back of the computer at several different angels. Taking
these photographs will serve as proof for how the computer was configured at the scene. This
documentation will be useful if the forensic examiner must later reconstruct the system
-​ Once documented, all the cables connected to the computer should be removed. Next, the computer
can be placed in a large antistatic bag or a cardboard box, and the hard drive should be placed in a
separate, smaller antistatic bag. Once the computer and hard drive are properly secured, they should each
be appropriately labelled. The label should detail the contents of the bag, time and date, the person seizing
the items in the bag, where the items was located at the search scene, and where the item is going, in
addition to any other necessary information.
-​ Following the bagging and tagging process, it is now time to gather all of the evidence and transport
it back to the forensic lab for further examination. The evidence should be packed carefully so that any
bumps or sudden stops during transportation wouldn’t cause it to shift or be damaged in any way.
-​ Environmental conditions should be always be of concern to the person transporting the evidence.
Once everything has been packed securely and is ready to be transferred, it is always a good practice for
the forensic examiner to double check that they have collected all of the evidence, and just as important,
all of the examiner’s equipment, including the tools that are used during the seizure.
-​ A copy of the search warrant should be left for the person in charge of the building or household
where the seizure took place, as well as a detailed list of the items that were seized.
-​ Once back at the lab, the Chain of Custody report must be continued, detailing that the evidence has
left its original location and is now at the forensic lab. The date and time the evidence arrived at the
lab should be documented, along with any other information necessary for the chain of custody report. The
chain of custody form should also detail where the item is stored at all times it is in the lab, whether it be in
a secure safe or removed for analysis.
-​ After the examiner has successfully secured the evidence in the laboratory environment, the next step is to
image any media that will be subject to analysis. As stated earlier, the examiner must use every
precaution while imaging the media to not alter the original evidence. Using write blockers during the
imaging process is always helpful in achieving this goal. When copying the media, the examiner must also
prevent the cross contamination of evidence. Cross-contamination occurs when evidence from two
separate cases is somehow inter-mixed. One method of preventing cross contamination is to conduct
each examination on its own freshly wiped hard drive. The hard drive can be formatted so it is clearly
labelled as the destination for all of the evidence. All image files, case files, the exported evidence, and
final report can all be saved to this hard drive. If this process is followed, the possibility of cross
contamination is minimised or eliminated.
-​ Tutorial 11
-​