Digital Forensics and Incident Response Standard Operating Procedure (SOP)

Introduction

The purpose of this procedure is to establish, define and execute a standard method on the process of initiating digital forensic investigation and incident response. The process defines the rules which are to be adhered to with respect to the identification, acquisition, imaging, collection, analysis and preservation of digital evidence for forensic purposes and the process for acting in response to incidents which require digital forensic preservation. Establishing such rules for conducting digital forensic investigations and incident response, ensures the integrity of data captured for the purposes of a civil or criminal investigation and the preservation of the chain of evidence (admissible in judicial process).

The purpose of a digital forensic investigation or investigation is to secure possible digital evidence by creating a forensic image (or images) of media which is relevant for an investigation. Digital investigations often involve the collection of considerable amounts of data (including Personally Identifiable Information (PII)), they can be invasive in nature. As such these procedures are also aimed to help ensure conformity with data protection and/or privacy considerations in the context of digital forensic investigations.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

Overview

Whether related to malicious cyber activity, criminal activity or the intent to commit a crime, digital evidence can be highly sensitive. Cybersecurity/Forensic professionals understand the nature and sensitivity of this information and respect that it can be easily compromised if not properly handled and protected. For this reason, it is critical to establish and follow strict procedures for activities related to the collection and processing of data when conducting a (digital) forensic investigation. Such procedures include detailed instructions about how and when computer forensics investigators are authorized to recover potential digital evidence. How to properly prepare systems for the retrieval of said evidence; where to store any retrieved evidence, and importantly how to document these activities to help ensure the authenticity of the data(which may be scrutinized in a court of law).

Digital forensic incident response, on the other hand, refers to the processes that are taken into consideration as an approach towards addressing and managing the aftermath of computer crime or cyber-attack. The digital forensic incident response involves all the steps that are taken to reduce the extent of the cyber-attack. The main aim of digital forensic incident response is to reduce the damage limits and reduce the cost of recovering and time taken to recover from an attack

Incident Response

The objectives of an Incident Response in the context of a computer system or systems is to:

• set out the guiding principles for establishing strategies that enable the appropriate levels of system and information confidentiality, integrity and availability to be maintained;
• minimize opportunities for, and maximize the ability to detect, protect and respond to threats against, information system resources;

Security threats can come in many forms including (but not limited to):

• Worms, viruses and Trojan-horse programs
• Malicious content from hostile or compromised web-sites
• Internet-based attacks from hackers/crackers
• Unauthorised modification of data
• Unauthorised access to privileged information
• Misuse of corporate infrastructure to break the law or perform malicious activities
• Loss or theft of company infrastructure, sensitive data or intellectual property; and/or
• Attempted and/or successful physical access to information, equipment or facilities.

Each of these threats may be addressed by a different response and the procedures outlined in this document ensure that a suitable methodical and thorough response process is followed

Mitigation Objectives

The measures outlined below are designed to reduce the following risks to a system:

• Risk of extensive damage to files, data, systems, storage and networks due to not taking timely action in containing an incident;
• Risk of the possibility of an incident affecting multiple or distributed systems;
• Risk of negative exposure that can damage stature and reputation or an organization; and
• Risk of possible legal liability and/or prosecution for failure to exercise adequate due diligence or execution of standards of care when systems are inadvertently or intentionally used to attack others (local or distributed).

Establishing A Security Incident

Part of the Incident Response is to establish the definition for an information security incident.

An Information Security Incident is defined as an attempt, either failed or successful, of unauthorised access, use, disclosure, modification or destruction of information; denial of information or service; or violation of explicit or implied security policy, standard or procedure.

Examples of security incidents include but are not limited to:

•      Violation of an explicit or implied security policy, standard or procedure.
•      An attempt to gain unauthorized access.
•      Unwanted/unintended/malicious denial of resources.
•      Unauthorized use of electronic resources (files, data, systems, storage and networks).
• Any other reasonable event, situation or system status change, that resulted in an unacceptable loss, corruption or exposure of information.
•      Computer and/or network security intrusion
•      Unauthorised use of systems, network or data
•      Unauthorised change to hardware or software configurations
•      Loss or theft of equipment used to store classified or potentially sensitive information
•      Denial of service attack
•      Computer virus/worm/spam outbreak
• Malicious software installations on computer or network device, e.g. spyware, Trojan horse, backdoor, logic bomb and root kit.
•      Compromised user account resulting in horizontal or vertical elevation of privileges.
•      Incorrect or inappropriate privilege/permission configuration
• Contact from law enforcement organisations regarding a computer and/or network device that may have been used to commit a computer crime
•      Use of software in violation of the software agreement

Incident Response Phases

The Incident Handling plan comprises six phases that ensure a consistent and systematic approach in handling Cyber Security Incidents (and apply to Cyber Security Incidents as well as normal incidents), i.e.:

• Preparation
• Identification
• Containment
• Eradication
• Recovery
• Follow-up

The details for each of the six phases is summarised below:

Preparation

In any Incident response, it is essential to form an escalation group prior to other tasks.

The role of this team is to promptly handle and respond to an incident so that it will have minimal impact on business operation. The team is formed by a member(s) from various functional roles within an organisation and may be a single member of the operations team or comprise of multiple members spanning the operations team through to management (commonly referred to as war-room members)

Identification

The occurrence of an Incident is unpredictable and uncertain. An anomaly in the system behavior may or may not indicate a cyber security incident. Hence, identifying an incident among routine daily operations is not an easy task (even for seasoned cyber security professionals).  In order to be effective, identification is a task for all users, not just operations staff. Following initial identification, a more thorough investigation is performed by the operations/investigative team.

Containment & Contingency

Prompt containment of the Incident is necessary to minimize and isolate the damage incurred on the computer, network or device.

Eradication

In order to successfully eliminate the Incident, the investigation needs to determine the cause of the incident that resulted in the compromise of the computer, network, system or device.

Recovery

The recovery phase is key as it restores operations of the compromise and facilitates the resumption of normal operations.  In reference to systems, prior to the resumption process, it is paramount that validation checks should be performed ensuring that the system is secured against any repeated incidents, persistence of compromise and/or the likelihood of re-exploitation is reduced.  Furthermore, the system should be placed under surveillance to ensure that if the threat actor returns, unauthorized attempts may be detected early or thwarted.

Post-Mortem/Follow-up

As a follow-up, a post-mortem analysis of the compromised system should be performed by suitably qualified technicians, to discover the weaknesses that resulted in the Security Incident and other potential vulnerable areas, and to mitigate these where possible. Additionally, if the incident warrants, a digital forensic investigation may be required. In this case it is recommended that forensic specialists (DFS) be engaged to ensure the preservation of evidence, should the organization consider legal action against the perpetrator. Furthermore, it is recommended that law enforcement agencies be engaged to ensure that digital evidence is accumulated and preserved in a manner that is consistent with relevant legislative requirements.

Preparation – Emergency Response Team

Within the organization, there should be a clearly identified Emergency Response Team (ERT). Both management and experienced operations staff perform this function. However, the organization may call upon external resources to augment areas, which are outside normal operational staff areas of competency.

The ERT is engaged to promptly handle a Security Incident so that containment, investigation and recovery can quickly occur. This ERT has decision-making authority for facilitating the incident response process in an expeditious manner. The needs and resources of the organization also play a part in the selection of these team members.

ERT Structure

The ERT may be divided into two sub-teams, i.e. the Supervisory team, and the Site/Support team.

Supervisory Team

The responsibility of the Supervisory Team includes:

• making decisions on and reviewing steps taken to rectify matters

• communicating and translating technical information to:

• senior management; or

• company directors

• supervising and reviewing test results, based on the tests conducted, to verify the feasibility and effectiveness of the Security Incident response procedures
• cooperating with and supplying information to the site/support team so that their duties can be carried out
• coordinating resources, e.g. software and hardware acquisition (if required)
• maintaining proper records of events and actions taken
• performing scenario planning and identifying corrective actions for each scenario; and
• supervising and reviewing the update, including lessons learnt, on the Security Incident Response Plan.

Site/Support Team

The Site team will consist of mid-management and/or SysAdmin with the responsibility of the Site Team including:

• surveying and securing the systems and environment
• containing the Security Incident
• eradicating Security Incident and performing recovery procedures
• compiling “recovery kit”, e.g.:

• recovery procedures
• contact list
• boot disks
• software
• tools
• hard disk

• providing logistic and technical support when required;
• updating relevant authorities
• coordinating communications for the organisation with various external parties, if required; and
• updating and maintaining the Security Incident Response Plan.

Identification

When any staff member notices a suspicious anomaly in data, a system, or the network, the ERT may be engaged to investigate and verify such an event has occurred, which is time and resource consuming.

During the identification phase of an incident the operations team must be engaged to carry out a preliminary investigation of a suspected incident to ascertain if the incident is, in fact, a:

• compromise; or
• false alarm/false positive.

Should the operations group fail to ascertain the severity of an incident, or have need to escalate the incident, the ERT will assist and advise to resolve the incident.

Typical Incident Symptoms/Responses

To facilitate the task of identification, the following is a list of typical symptoms of Cyber Security Incidents, which include any or all of the following:

• A system alarm or similar indication within log files;
• Repetitive unsuccessful logon attempts within a short time interval;
• Unexplained new user accounts;
• Suspicious entries in system or network accounting (e.g. a network user obtains privileged access without going through the normal sequence);
• Unexplained new files or unfamiliar file names;
• Unexplained attempts to write to system files or changes in system files;
• Unexplained modification or deletion of data;
• Unexplained modifications to file lengths and/or dates, especially in system executable files;
• Denial/disruption of service or inability of one or more users to login to an account;
• Operation/Identification of a program or sniffer device to capture network traffic;
• Unusual time of usage (e.g. users login during non-working hours);
• An indicated last time of usage of a user account that does not correspond to the actual last time of usage for that user, and
• Unusual usage patterns (e.g. programs are being compiled in the account of a Finance user with no programming background).

Although no single symptom conclusively shows that a security incident is taking place, observing one or more of these symptoms prompts the observer to investigate events more closely.  A SysAdmin who encounters one or more of these symptoms should work with the ERT to determine whether there has been a security incident and the cause of the security incident.

Using the above-mentioned categories of Security Incidents as reference, the ERT can validate and provide advice on security incidents on a per case basis before proceeding with the other phases . All details in the Identification phase should be documented.

Protection of Incident Information

The protection of incident information is paramount to ensure the preservation and admissibility of evidence. The events detected and evidence collected while investigating this incident may, in the end, become the subject of legal proceedings – particularly if the organization elects to launch some form of legal prosecution after the incident.

Responsibility and Care of Duty

The organization has a responsibility and duty of care to inform the administrators of other organizations about the involvement of their systems so that they can take the necessary steps to respond to an intrusion. However, in the event of an ongoing legal investigation, the ability to inform other organizations may be restricted.  For example:

• action may affect the outcome of the investigation in some way; or
• users from the other organisation may, in fact, be the subjects of the investigation.

Containment & Contingency

The objective of the containment phase is to regain control of the situation by limiting the extent of the damage. The ERT Manager may consider isolating the compromised system from the rest of the network systems. However, this may disrupt operations if the compromised system is critical or many systems were affected by the Cyber Security Incident, as in the example of a ransomware outbreak.

Therefore, the ERT Manager must evaluate with management, on a per case basis, the risk of:

• Continuing operations, versus
• regaining control of the compromised system.

All attempts to contain the threat must take into account every effort to minimize the impact on operations.

Furthermore, a backup should also be performed on the system to maintain the current state of the system to facilitate the follow-up/post-mortem and forensic investigation later. The ERT Manager may also consider changing the system passwords.  This is to prevent the possibility of trojans, or persistence  being maintained on the compromised system that allows the intruder to return to the system via a backdoor.

Exercise Precautions

Depending on the incident to be contained, the function and criticality of the system, the organization will make a decision whether to:

• shutdown
• disconnect the system from the network
• disable services
• change passwords
• disable accounts; or
• to monitor system and network activity.

This decision will require management involvement/approval.

Shutdown

The need may arise to temporarily shutdown a compromised system when there is no other means by which to deny an attacker or intruder access to a system. This may:

• allow for further analysis of the incident; and
• prevent possible further damage to the system.

This does, however, pose the problem of having legitimate users also denied access to the system, and also potentially losing any in-memory compromise, and therefore should be executed with caution.

Disconnect

The following are alternatives to shutting down a compromised system:

• Disconnect the system from public networks.
• Disconnect the system from local area networks.
• Disconnect the system from corporate networks.

These alternatives offer both pros and cons for system users, for example:

• Allowing non-compromised systems to still carry out business functionality.
• Severing the compromised system communication from the attacker/intruder.
• Potentially quarantining the infected/compromised system from infecting/compromising other systems on the network.

Disable Services

If sufficient analysis has been performed by the organisation to limit the scope of an intrusion to specific services, and these services are non-critical in nature or have limited effect on functionality, then these services may be disabled. By disabling specific services that have been compromised:

• user continuity can be observed/provided, and 
• access to other services can retained.

Change Passwords

Whilst this is not a completely sturdy means of containment,  changing passwords associated with the accounts an intruder/hacker is using will immediately terminate that access path and attack vector.

Disable Accounts

Disabling accounts that an intruder/adversary has compromised is another means of terminating an access path/attack vector by which access has been gained. This again is not a dependable means of containment, however does provide a level of containment.

Monitor System and Network Activity

Indifferent of what other actions may have been taken, the need to monitor all system and network activities for unusual and suspicious events is a must.

The organisation upon discovery of a compromise should monitor the network to detect:

• attacks previously used by an intruder; and
• connections coming from systems you know to be used by and intruder.

While utilising this approach it becomes easier to identify subsequent intruder access attempts and may also disclose other access path/attack vectors not previously identified.

Legal Advice

When an intrusion has occurred and it has been determined that the intrusion will continue under controlled allowable conditions, the ERT Manager should seek further legal advice on the preservation of evidence and chain of custody, should prosecution be sought.

Eradication

After the containment phase, the organization should conduct further investigation to uncover the root cause of the Cyber Security Incident by analyzing system logs of various devices, e.g.:

• Firewalls
• Routers
• Hosts.

NOTE: It is important that a separate set of administrative tools are used for the investigation and not those in the compromised system.

In the event that the perpetrator/adversary has modified the system configuration, execution of any system tools may have dire consequences. For example, the intruder may have modified the CMD.EXE or Powershell applications of the compromised system.

The organization may search on other systems for signs of compromise, as intruders regularly establish more entry points into a network once they have gained initial access (referred to as persistence).  Such areas of interest would be:

• Same IP address range and/or segment of the network
• Systems on the same “trusted” domain
• Systems with the same services in common (i.e. DNS, FTP, HTTP, SMTP); and
• Systems with the same operating system.

Where possible a clean operating system should be reloaded into the compromised server/machine after the investigation and the system built to the standard operating environment (SOE). Many off-the shelf operating systems are not developed with security in mind. Hence, to increase the security defense of the system it must undergo a hardening process which should include:

• Applying all the latest patches
• Disabling any unnecessary services
• Installing anti-virus software; and
• Applying the Company’s security policy to the system.

Eliminate the means of attack

After an attack or incident has been identified it is paramount that the means which enabled the attack or incident is eliminated.

Virus Infection

In case of a virus infection, the eradication simply requires the removal or cleansing of infected files from all systems and media. This is done by utilising the antivirus/antimalware software.

Malicious code

Malicious code infestations may also occur. This is combated with the use of commercial and non-commercial malware detection tools. Such malicious code can be in the form of a:

• Backdoor
• Ransomware,
• Trojan horse
• Worm; or
• Hijacking program (e.g. BHO (Browser High-jacking Object)).

Network Intrusion

Network intrusions may result in a switch or router becoming controlled by an unknown entity. Enabling its use in propagating malicious activities. Such activities may be in the form of:

• DNS poisoning
• SMTP relaying
• Routing traffic to malicious sites.
• Packet capturing of network traffic.

Should a network device become compromised, the organisation recognises it is crucial to ensure that the device configuration is restored to its previously known good state.

Password Changes

All passwords relating to all systems on which the incident occurred need to be changed. This will be done in all cases. This may significantly impact the system as it will cascade from privileged users down to end users.

Restore Programs and/or Binary Files

Restoration is required of executable programs and binary files, from original or backup media, over potentially compromised files that an intruder may have:

• added
• changed; or
• deleted.

This is because users cannot determine what:

• hidden functions may remain; or
• critical functions may have been influenced by these changes.

The employment of cryptographic checksums and utilisation of integrity checking software can reduce this risk greatly, however, may be cost prohibitive for an organisation to deploy.

Recovery

Prior to restoring the system from a clean backup, it is recommended that validation takes place to ensure the eradication procedures have been properly performed. After installing the backup, the system must be monitored to determine if it is functioning normally before the organization restores it into full operations.

ERT personnel must determine how to restore compromised systems and networks with minimum risk of incident recurrence and impact to current operations. Furthermore, a network surveillance tool should be implemented to detect any unauthorized attempts such as additional scans or probes that may signal the return of the intruder.

Time Frame

Input from the organizations management and the operations group is required to formulate an achievable time frame for affected systems to return to normal operations. This time, frame will include:

• completion of incident analysis; and
• the eradication of vulnerabilities before returning to normal operations. 

However, due to operational needs, systems should be strictly monitored in parallel for any signs of further incidents or attack.

Enable Services and Applications

The organization will enable previously disabled services and/or applications that are either not vulnerable or for which mitigation techniques have been applied. Only services that are required by the users of the system will be enabled.

Reconnect and Validate

The organization will reconnect the restored system to its local network and proceed to validate the restored system. Verifying that the restore operation was successful and the system is functioning normally.

Monitor

The organization will closely monitor the previously infected/compromised system for any scans, probes or other suspicious activity that may signal the return of an intruder.  Monitoring efforts will focus on such signs as:

• Failed login attempts
• Attempts to access certain ports
• Scanning for ports and protocols which were utilised by the vulnerability; and
• Attempts to exploit new vulnerabilities;

Any occurrence of these will be analyzed further.

Follow-up / Post Mortem

The objective of a post-mortem analysis is to perform a detailed investigation of the Cyber Security Incident to:

• Determine its extent, and
• identify appropriate prevention mechanisms.

There are three options for performing a follow-up/post-mortem analysis as shown in the below table. The option selected will be determined by the ERT and severity of the Cyber Security Incident, the damage incurred by the organization, and whether legal action is to be taken.

Table 1 – Options for Performing Post-Mortem Analysis

Digital Forensics

Establishing a Forensic Laboratory

To conduct sound forensic investigations a forensic laboratory must be established. A forensic laboratory comprises of the following elements:

• Must be physically isolated (air gapped) and protected from standard/corporate offices/networks.
• Must have a physical controlled lock on forensic investigation rooms, or have a safe whereby acquired forensic evidence may be secured when not in use.
• Identity and Access Management, where those DFS staff have been vetted and adhere to the principles of Authentication, Authorization and Accountability (AAA) when handling digital forensic evidence and work files are stored, and a consultation area for the investigators and operational analysts.
• Appropriate hardware (server and workstation) and software which is validates and corroborates anti-tampering, integrity and authenticity (hash) of both physical machines and software
• Servers and the forensic workstations are on a dedicated forensic network, with no Internet connection and physically separated (air gapped) from other networks.
• Access to the forensic laboratory is restricted to system administrators and DFS staff that have a need to know via access control which is logged and auditable.
• All data transfers to or from the forensic laboratory by a DFS analyst must be recorded, in order to protect the chain of evidence.

Preparation

When commencing a digital forensic investigation, it should be established (where possible and in advance) the names and/or function of persons and/or names of DFS analysts who will be involved in executing the investigation of digital media which will be subject to the forensic investigation.

Authorization to carry out a digital forensic investigation should be provided by the relevant authority (commercial or by law enforcement agencies). This authorization document should specify that the digital forensic investigation and incident response may be extended to further digital devices found. Where appropriate, it should also specify data of potential relevance to the investigation may be requested from third parties such as Cloud Service Provider and/or Internet Service Providers.

General Investigation – Approach

Digital forensic investigations should only be conducted by DFS(s) to ensure admissibility of the evidence obtained in subsequent legal proceedings – a DFS may be required to testify as an expert witness during court proceedings.

At the start of the digital forensic investigation, the DFS must:

• document and take photographs of all digital media which shall be subject to the forensic investigation, as well as the physical surroundings and layout;
• Date/Time/Location/By Whom must be recorded;
• make an inventory of the digital media acquired during the seizure. The inventory must be documented in the “Digital Forensic Report”, and the relevant photographs attached as evidential reference material.

In general terms, the DFS should conduct a full digital forensic acquisition of the devices referred to above.

If possible and whilst onsite, the DFS should preview those devices to determine whether they may contain data potentially relevant for the investigation and whether a partial forensic acquisition would be appropriate. Pending the initial preview, the DFS may conduct a partial forensic acquisition of the data.

The assurance and right to privacy does not and shall not prevent the DFS from conducting a thorough digital forensic acquisition of the targets of evaluation/examination.

The DFS will create a security backup copy of the acquired data on site, time permitting, storing it on a separate digital medium, and verify that it functions properly prior to leaving the site.

In order to protect the chain of evidence, the DFS will make an inventory of the digital media acquired during the seizure. This includes not accepting digital devices from any person at any time during the digital forensic investigation. Only the authorised DFS shall accept digital devices, and inventory where appropriate, to conduct a digital forensic acquisition.

At the site of acquisition (seizure), the DFS shall draw up a “Forensic Acquisition Register” recording all activities relating to access, acquisition, collection, compilation and storage of the data for forensic investigation. All digital forensic copies created and their respective hash values must be recorded against the forensic acquisition inventory (as described above).

Any error, damage or other incident and any remedial steps taken shall be specified and documented and validated by the DFS and witnessed.  Where the digital medium was not acquired forensically, this shall be recorded and noted on the forensic acquisition inventory.

Objections made during the digital forensic investigation by the offender being investigated shall be recorded in the notes of the “Forensic Acquisition Register”. The DFS will forward any recorded objection which relates to personal data or procedural guarantees for legal advice where necessary.

The “Forensic Acquisition Register” will record and identify all persons actively involved in the digital forensic investigation. The “Forensic Acquisition Register” shall be signed by the DFS who carried out the forensic acquisition and if applicable witnessed by any additional on-site technical staff who assisted in the execution of their duties. The DFS shall retain a copy of the “Forensic Acquisition Register” and shall register this immediately upon return to the office/laboratory as part of the case file.

All devices containing information gathered during the digital forensic acquisition must be transported in a secure manner, for example (but not limited to):

• on hard-ware encrypted hard disks,
• anti-static bags sealed with security seals,
• protective/padded carry bags to avoid damaging the device(s)

When being transported from the seizure site to the laboratory, the items will remain under the physical control of DFS staff (e.g. by hand) at all times. This maintains the integrity of the chain of evidence.

Where a digital forensic image and a security copy have been made, they should be carried by different members of staff, if possible, but adhere to the same principles as defined above.

Remote Data Acquisition

The DFS may find that data of potential relevance for the investigation are stored remotely (i.e. within a cloud provider or third-party data center provider)

• If potentially relevant data has been identified as being stored remotely in a data center, the DFS will request that the target of evaluation/examination provides access to the data pursuant to any legal warrants.
• If potentially relevant data is held by a third-party operator on a wide area network or private cloud, the investigator shall ask the target of evaluation/examination or the third-party operator concerned to download the data using his/her credentials pursuant to any legal warrants
• If potentially relevant data is held by a public cloud service provider (e.g. Gmail, Yahoo Mail, Dropbox, etc.) or an Internet Service Provider, DFS may request that these be provided under legal warrants, adhering to jurisdiction boundaries.

Where feasible, downloading data stored on a remote site should be done in the presence of the DFS to guarantee that the complete set of data is provided and that it has not been filtered or altered which may impede the digital forensic investigation or render data inadmissible in a court of law due.

Examination of Material

Upon immediate return from the digital forensic acquisition (seizure-site), the DFS is to create an additional back-up copy of the digital forensic image (to disk) and place them in sealed envelopes with unique identification numbers (these may be maintained within a safe). This is the Security Backup Copy, which shall be stored in the Forensic Archives and not used as the working copy. The other is the on-site copy, which shall be utilized in the digital forensic investigation. This is the digital forensic evidence/case file and work files used as the working copy for investigative purposes. 

The laboratory must be protected by access control and where applicable CCTV cameras. The DFS shall transfer the on-site copy digital forensic image to the forensic file server in the forensic laboratory. This file becomes the forensic work file.

The DFS will take custodianship of the evidence collected during the digital forensic acquisition and conduct a preliminary assessment to determine whether data has been deleted or anomalies exist which draw conclusion that data has been modified, altered, tampered with, manipulated or copied, in alignment with the objective of the investigation.

Searching for potential evidence is a dynamic and drawn out process, and may involve several successive iterations of the digital forensic image, a minimum of two technical sweeps of the forensic image are required (a preliminary sweep, followed by an in-depth sweep).

The search/sweep process includes:

• looking for traces of deleted data in unallocated space,
• specifying keywords to be searched,
• inspecting images for steganography
• querying/establishing timelines
• extracting in-memory data
• making more complex searches such as special (regular) expressions.

The DFS shall identify potentially relevant information using the resources and facilities provided within the forensic laboratory. The DFS may print or make an electronic copy of relevant files, which should be attached to the relevant case file, and maintained within the secure confines of the forensic laboratory.  Any data transfer outside of the forensic laboratory must be recorded in order to protect the chain of evidence.

Figure 1 – General Investigation Work Flow

Upon completion of the examination of the digital forensic work file, the DFS shall prepare a “Digital Forensic Examination Report” summarizing the results of the forensic actions undertaken, listing all findings, and the methodology used, and define a list of all tools used to arrive at the hypothesis or provisional conjecture. A copy of this report must be attached to the relevant case file for archive purposes. Data maintained within the archive is subject to official records maintenance as per the judiciary/jurisdiction boundaries.

Re-Acquisition

Under the same criteria as for authorizing a digital forensic investigation, re-acquisition and examination of a forensic image may be taken in the context of a different investigation, whereby the data may be used for alternative investigation or prosecution purposes.

Before requesting re-acquisition, the DFS must assess on a case-by-case basis the potential relevance of such data taking into consideration:

• the time that has elapsed since the initial acquisition
• such as subject matter,
• mode of operation, and the
• legal and natural persons involved in the initial investigation.

Retention of Forensic Material

At the end of the case file’s administrative retention period, the digital forensic evidence file and work files are treated in accordance with official records maintenance as per the judiciary/jurisdiction boundaries and or document management principles.

Definitions

References:

 [1] Occupytheweb. (Julu 2, 2016). Live Memory Forensics) [online]. Available: https://null-byte.wonderhowto.com/how-to/hack-like-pro-digital-forensics-for-aspiring-hacker-part-14-live-memory-forensics-0168337/

[2] M. Souppaya. (2013, July). “Guide to Malware Incident Prevention and Handling for Desktops and Laptops”. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf

[3] Kristian Lars Larsen. (December 20, 2018). Seven important do’s and don’ts to follow when preserving digital evidence for civil litigation [online]. Available: https://www.datanarro.com/7-dos-and-donts-of-preserving-digital-evidence-for-civil-litigation%EF%BB%BF/ 

[4] Adams, R., Hobbs, V., & Mann, G. (2014). THE ADVANCED DATA ACQUISITION MODEL (ADAM): A PROCESS MODEL FOR DIGITAL FORENSIC PRACTICE. Journal of Digital Forensics, Security and Law, 8(4). Retrieved from https://www.researchgate.net/publication/262524990_Journal_of_Digital_Forensics_Security_Law

[5] Ademu, I., Imafidon, C., & Preston, D. (2011). A New Approach of Digital Forensic Model for Digital Forensic Investigation. International Journal of Advanced Computer Science and Applications, 2(11). Retrieved from https://core.ac.uk/download/pdf/25850684.pdf

[6] Bem, D., Feld, F., Huebner, E., & Bem, O. (2008). Computer Forensics – Past, Present and Future. Journal of Information Science and Technology, 5(3). Retrieved from http://www.cis.gsu.edu/rbaskerville/cis8630/Bernetal2008.pdf

[7] Kishore, N., Gupta, C., & Dawar. (2014). An Insight View of Digital Forensics. International Journal on Computational Sciences & Applications, 4(6). Retrieved from https://pdfs.semanticscholar.org/7db7/02479eb0b844c6deac0f254195dd0f086a09.pdf

[8] Lillis, D., Becker, B., & O’Sullivan, T. (2016). CURRENT CHALLENGES AND FUTURE RESEARCH AREAS FOR DIGITAL FORENSIC INVESTIGATION. Retrieved from https://arxiv.org/pdf/1604.03850.pdf

[9] Mushtaque, K., & Ahsan, K. (2015). DIGITAL FORENSIC INVESTIGATION MODELS: AN EVOLUTION STUDY. Journal of Information Systems and Technology Management, 12(2), 233-244. Retrieved from http://www.scielo.br/pdf/jistm/v12n2/1807-1775-jistm-12-2-0233.pdf

• Adams, R., Hobbs, V., & Mann, G. (2014). THE ADVANCED DATA ACQUISITION MODEL (ADAM): A PROCESS MODEL FOR DIGITAL FORENSIC PRACTICE. Journal of Digital Forensics, Security and Law, 8(4). Retrieved from https://www.researchgate.net/publication/262524990_Journal_of_Digital_Forensics_Security_Law
• Ademu, I., Imafidon, C., & Preston, D. (2011). A New Approach of Digital Forensic Model for Digital Forensic Investigation. International Journal of Advanced Computer Science and Applications, 2(11). Retrieved from https://core.ac.uk/download/pdf/25850684.pdf
• Bem, D., Feld, F., Huebner, E., & Bem, O. (2008). Computer Forensics – Past, Present and Future. Journal of Information Science and Technology, 5(3). Retrieved from http://www.cis.gsu.edu/rbaskerville/cis8630/Bernetal2008.pdf

• Kishore, N., Gupta, C., & Dawar. (2014). An Insight View of Digital Forensics. International Journal on Computational Sciences & Applications, 4(6). Retrieved from https://pdfs.semanticscholar.org/7db7/02479eb0b844c6deac0f254195dd0f086a09.pdf
• Lillis, D., Becker, B., & O’Sullivan, T. (2016). CURRENT CHALLENGES AND FUTURE RESEARCH AREAS FOR DIGITAL FORENSIC INVESTIGATION. Retrieved from https://arxiv.org/pdf/1604.03850.pdf
• Mushtaque, K., & Ahsan, K. (2015). DIGITAL FORENSIC INVESTIGATION MODELS: AN EVOLUTION STUDY. Journal of Information Systems and Technology Management, 12(2), 233-244. Retrieved from http://www.scielo.br/pdf/jistm/v12n2/1807-1775-jistm-12-2-0233.pdf
• https://www.ncjrs.gov/pdffiles1/nij/grants/248770.pdf
• International Standards Organization – ISO/IEC 27037 – Information Technology – Security Techniques – Guidelines for identification, collection, acquisition and preservation of digital evidence
• National Institute of Standards and Technology (NIST) – Special Publication 800-86 – Guide to Integrating Forensic Techniques into Incident Response
• David Watson & Andrew Jones (2013) Digital Forensic Processing and Procedures – Meeting the requirements of ISO 17020, ISO 17025, ISO 27001 and Best Practice Requirements