Forensic Readiness Guide
Parent topic: Forensic Principles
About this document
This document is the Ministry of Justice (MoJ) IT Security Forensic Readiness Guide. It is designed to help protect MoJ IT systems by providing guidance on how to develop a Forensic Readiness Plan.
How to use this document
The purpose of this guide is to provide a consistent approach to forensic readiness across all MoJ IT systems and designed to supplement the guidance provided in CESG GPG No.18.
HMG Security Policy Framework (SPF) Mandatory Requirement (MR) 9 states that:
Departments and Agencies shall put in place an appropriate range of technical controls for all IT systems, proportionate to the value, importance and sensitivity of the information held and the requirements of any interconnected systems.
To comply with this requirement, the MoJ shall:
Have a forensic readiness policy that shall maximise the ability to preserve and analyse data generated by an IT system that may be required for legal and management purposes
The policy on forensic readiness is covered in the Forensic Readiness Policy document. This document sets out the MoJ guidance on implementing that policy and developing a Forensic Readiness Plan.
This document is intended to provide guidance on the development of a Forensic Readiness Plan for MoJ IT Systems, including IT systems hosted by third party suppliers on behalf of the MoJ.
Demonstration of Compliance
The CESG Information Assurance Maturity Model (IAMM) sets out the minimum maturity level Government departments should attain. Forensic readiness is captured as a basic requirement in Level 1 and the MoJ need to demonstrate compliance against this requirement.
This document is split into three sections:
- Definition of capability and requirement – this section provides guidance on the type of forensic capability which should be provided and the high level requirements associated with delivering a forensic capability which can support the implementation of a Forensic Readiness Plan;
- Developing a Forensic Readiness Plan – this section provides guidance on developing a Forensic Readiness Plan for an IT system or IT domain.
- Staff, education, training and awareness – this section provides guidance on what staff training and awareness should be made available in-order to support the implementation of the Forensic Readiness Plan.
A template Forensic Readiness Plan is available in Appendix D.
Definition of capability and requirement
The Forensic Readiness Policy document states the MoJ requirements on the need for IT forensics; each MoJ IT system or IT domain shall have or be explicitly covered by a Forensic Readiness Plan. The policy also outlines four principles which shall be followed. For reference, these are:
- Preservation of Evidence - the forensic investigation process shall preserve the integrity of original evidence by providing sufficient security, legal advice and procedural measures to ensure that evidential requirements are met. Any processes applied to copies of evidence must be repeatable and achieve the same results.
- Aptitude for task - any task in a forensic investigation shall be conducted by a person assessed to be suitably trained and competent to carry out that task.
- Documented Methodology – all investigations shall follow the documented methodology outlined in the forensic readiness plan, with an audit trail of all processes applied to evidence. A chain of evidence shall be created and preserved demonstrating where evidence has been stored and whose care the evidence has been in from point of capture until presentation.
- Conformance - investigations shall be conducted in a manner which respects MoJ policies and assumes full cooperation from all internal and external staff members.
Resources and capability
CESG GPG No.18 provides guidance on the level of forensic capability that should be developed consummate to the Segmentation Model and Business Impact Levels (BILs) of the IT system or IT domain in question.
Most MoJ IT systems attract a BIL of 3 for Confidentially, Integrity and Availability and are classified as ‘Deter’ in the segmentation model. As such, CESG GPG No.18 considers that a Forensic Readiness Plan developed to capability level 2 is sufficient. It is anticipated that the majority of MoJ IT systems will fall into this capability level; however, this must be assessed on a system by system basis as part of the system Accreditation process. Further details on the process can be found in the Accreditation Framework.
People and resources
The MoJ Security team is responsible for the IT Security Incident Management Process and charged with responding to all IT security incidents.
The MoJ intends to use a mix of internal and external resources to ensure that its forensic investigation capability can quickly and efficiently react to potentially incidents thereby minimising disruption to business.
Note: The Forensic Readiness Policy states that each forensic investigation must have named Forensic Investigation Owner.
Evidence collection and storage
The responsibility for the collection and management of evidence is likely to be split between the MoJ, IT service providers and an external forensics provider. At all stages of a forensic investigation process (refer here ), all evidential items collected from MoJ sites (or from MoJ IT equipment) must be managed and under the control of the Forensic Investigation Owner. Using CESG GPG No.18, it is important to ensure that the procedures are laid out in the Forensic Readiness Plan.
Internal and external reporting and communication
The Forensic Readiness Policy outlines the need to ensure appropriate internal and external reporting. To ensure consistency of approach, as the Forensic Readiness Plan sits within IT Security Incident Management, the trigger points for internal and external reporting must align with the relevant Incident Management Plan; refer to the Incident Management Plan and Process Guide for further details.
Note: Responsibility for escalation normally resides with the Information Asset Owner (IAO) and/or the Forensic Investigation Owner. Where responsibility for an investigation has been escalated to the Departmental Security Officer (DSO) or Senior Information Risk Owner (SIRO), further escalation responsibility will also reside with them.
The impact upon any ongoing operational activity must be considered before external reporting and escalation is invoked. The forensic investigation process (refer here ) must allow for the chain of evidence to be passed to any authorised outside agencies (e.g. Law Enforcement) where applicable.
Building an evidence-based case
A forensic investigation needs to go beyond identifying a wrongdoer or discovering how an incident occurred; it is required to provide a body of evidence that can stand up to detailed scrutiny, possibly by outside authorities. An investigation may involve many separate facts, both technical and testimonial, that are gathered together and presented as a logical argument.
A forensic case consists of:
- The use of a technical forensic investigation methodology to build a consistent body of evidence that is applicable to its context e.g. presentation to a court of law or disciplinary hearing.
- The ability to record testimonial evidence, including witness statements attesting to the facts around an incident and its investigation by a forensic expert.
- The presentation of available facts in a logical, unbiased argument.
The forensic investigative capability of the selected external provider must follow a predefined forensic methodology to acquire evidence in a consistent manner, suitably transport and preserve it, and present it as legally admissible in any subsequent proceedings.
Developing a forensic readiness plan
Scenario based planning
It is important to consider the circumstances in which a Forensic Readiness Plan will be invoked. Scenario-based planning is all about examining the different circumstances and incident types which are likely to result in a forensic investigation, then building the forensic readiness plan around those scenarios.
Table 1 provides a list scenario class types which are detailed in CESG Implementation Guide No. 18. It is anticipated that for the MoJ, the most pertinent classes are class 1, 2, and 3; record management systems may also need to consider class 5.
|Class 1 - Crime||Scenarios involving criminal offences and law enforcement.|
|Class 2 - Internal||Scenarios relating to internal (e.g. disciplinary or audit) investigations.|
|Class 3 - External||Scenarios relating to external attack (e.g. by a hacker).|
|Class 4 – Civil Dispute||Scenarios involving civil disputes (e.g. over a contract).|
|Class 5 – Regulatory Compliance||Scenarios where information is to be provided in compliance with a regulatory requirement (e.g. under the Freedom of Information Act).|
Each scenario should be documented in full with a summary contained in the Forensic Readiness Plan (refer to Appendix D). Table 2 provides an outline for how each scenario should be documented. It is recommended that this is included as an appendix to the Forensic Readiness Plan.
|Scenario||Scenario name and brief description.|
|Typical Synopsis||Provide an example(s) of the scenario type. This is not meant to be exhaustive and there can be many variations on a theme.|
|Typical Diagnostic Indicators||Produce a list of possible sources that may first raise suspicion that an incident of that scenario type has occurred. Refer to Appendix A for possible incidents.|
|Typical Digital Evidence Sources||Generate a checklist of potential initial sources (in approximate order of significance) of evidence that would be useful to an investigation in that scenario type. Refer to Appendix B for guidance on digital evidence sources.|
|Typical Workflow||Generate a workflow checklist of activities which should be followed. This does not need to be a precise list as each incident may have unique characteristics and take the investigation in unpredictable directions. Refer here for further details.|
|Typical Desired Outcomes||A checklist of the outcomes / outputs of conducting a forensic investigation.|
Criteria for conducting a forensic investigation
The decision to conduct a forensic investigation is a risk management decision, set against a cost/benefit analysis and any obligations stemming from any legal or regulatory requirements.
Developing forensic scenarios (refer here) plays an important role in understanding the inputs into the decision making process. Table 3 outlines the decision making criteria along with the considerations which should be applied.
|Risk Management||It is important to ascertain the risk and issues associated with any incident and consider whether the impact of conducting a forensic investigation will have a detrimental effect on MoJ IT systems or business processes.|
|Cost/Benefit Analysis||The costs associated with conducting a forensic investigation might outweigh the benefits of the desired outcomes. There may be a requirement to discuss those outcomes with the MoJ ITSO and/or external forensic provider to understand the options available.|
|Legal / Regulatory requirement||Where there is a legal or regulatory requirement to conduct a forensic investigation, this must be fed into the decision making process along with an analysis of what level of forensic investigation is required to satisfy that requirement.|
|MoJ Authorisation||The decision to conduct a forensic investigation resides with the IAO and/or ITSO.|
Incident management and forensic investigation process
The IT Incident Management Policy sets out the MoJ requirement for incident management where forensics investigation form part of the incident management process. As such, the forensic incident management process is an extension of the overall incident management process.
CESG Implementation Guide No. 18 provides a generic forensic investigation process flow. Table 4 lists the step-by-step forensic investigation activities which are expected to be included in the Forensic Readiness Plan (refer to Appendix D), along with the role/s responsible for completing each activity.
|1||Decision to conduct a Forensic Investigation||MoJ Security team / MoJ ITSO|
|2||Agree the scope of the forensic investigation||MoJ ITSO|
|3||Provide a Single Point of Contact (SPOC) for incident management and co-ordinate forensic activities||Forensic Investigation Owner|
|4||Establish a forensic investigation||Forensic Investigation Owner / MoJ IT System Manager / External Forensics provider|
|5||Collection of evidence||MoJ IT System Manager / External Forensics provider|
|6||Analysis of evidence||Forensic Investigation Owner / MoJ IT System Manager / External Forensics provider|
|7||Production of forensic reports||Forensic Investigation Owner / External Forensics provider|
|8||Approval of forensic reports||SIRO / IAO / MoJ ITSO|
|9||Long term storage of evidence if required||MoJ IT System Manager / MoJ ITSO|
|10||Provide specialist digital forensics legal advice to investigations||External Forensics provider|
|11||External reporting and liaising||MoJ Security team / MoJ ITSO|
|12||Act as Expert Witness for legal proceedings (if required)||External Forensics provider|
|13||Post incident remediation analysis including production of lessons learned||Forensic Investigation Owner / External Forensics provider|
|14||Approval of post incident remediation||SIRO / IAO / MoJ ITSO|
|15||Implement required changes to support investigation and post incident activities||MoJ IT System Manager / IAO|
Note: The Forensic Readiness Plan and associated investigation process should align with the relevant business continuity plan and MoJ policy on records management.
When the decision is made to conduct a forensic investigation or preserve evidence in a manor which does not preclude a forensic investigation, it is vital that a clear set of procedures are included within the Forensic Readiness Plan to ensure evidence is not lost or tampered with.
Appendix C contains a generic set of procedures which are designed to be enacted during the first stages of a forensic investigation (steps 1 to 4 in Table 4) to ensure information is stored in a forensically safe manner. Each Forensic Readiness Plan (refer to Appendix D) must contain a set of forensic procedures.
Each Forensic Readiness Plan must consider the Key Performance Indicators (KPIs) and Service Level Agreements (SLAs) required. This ensures that when required, the Forensic Readiness Plan can be executed in a timely and efficient manner.
To support continuous improvement, the Forensic Readiness Plan must be updated annually with the following information:
- Current and target forensic capability levels;
- Status of the plan and associated scenarios;
- Status of any exercise and feedback from those exercises;
- Status of staff or external provider competency levels (including register of formal certifications);
- Current and past investigation knowledgebase and active issues (to be managed by the MoJ Security team);
- Status of the current review cycle.
Staff, education, training and awareness
Good information usage and risk management practice demands appropriate training of all individuals coming into contact with MoJ IT systems; this must include relevant aspects of the Forensic Readiness Plan.
Ongoing general MoJ IT security awareness training must integrate forensic readiness awareness into the existing courses, and ensure at least annual refreshment for all staff on the current policy and procedures. This includes the communication of any required incident response procedures to ensure admissibility of evidence.
For the roles outlined here, more in depth forensic readiness training may be required. This must be considered during the development of the Forensic Readiness Plan. It may involve utilising external training courses and material to train first responders and other key individuals involved in developing and delivering the Forensic Readiness Plan.
Appendix A. Guidance on risks and incidents
Business risks that require reduction or mitigation through the use of forensics come from a variety of sources and cover several different types of incident/crime.
Table 5 provides some examples of incidents which may require a forensic investigation:
|Incident Category||Nature of Incident|
|Creation or planting of viruses or malware||The deliberate introduction of these files could pose a major threat to MoJ information security. Infiltration of systems in this way potentially causes issues such as downtime, unpredictable behaviour and/or data non-availability.|
|Damage or modifications to computer equipment or data||The deliberate or incidental damage of a computer system may disguise unauthorised activity previously carried out on that device. Examining modifications of equipment may reveal planted devices, such as key loggers or modems used to bypass normal security mechanisms.|
|Disciplinary issues through inappropriate use of MoJ IT systems||This could include: the storage of pornographic or other images or files; email abuse such as SPAM; connecting systems to unofficial networks; attempted unauthorised access to computer data or programs; or unapproved upload/download of information to the Internet. Refer to the Acceptable Use Policy for further details.|
|Email SPAM/Denial of Service Attacks||Internal connections may be used to attack other internal or external targets. An investigation may look for evidence of the tools used by hackers.|
|Financial crimes, identity theft, fraud, forgery, theft of funds, blackmail or extortion||The misuse of a computer to steal people’s identity for financial or other gain may leave evidence in IT systems or on portable media. A forensic study of disks, equipment, logs and email records plus other devices (e.g. mobile phones) and non-digital evidence (e.g. printed documents, written notes) may provide investigators with evidence to prosecute individuals.|
|External||Many outside parties, from teenagers acting alone to hostile foreign governments, may attempt to compromise the security of MoJ IT systems.|
|Internal Authorised||Authorised users may abuse MoJ IT systems by conducting unauthorised or illegal actions. These could include storage of offensive material, stealing information for an outside agent, providing (or selling) information to someone external to the organisation, the unapproved upload/download of information to the Internet or internal illegal file-sharing.|
|Internal to External||Users may use MoJ IT facilities to facilitate crimes against external parties. Examples would include mass emailing, hosting illicit Peer-to-Peer (P2P) clients (for music propagation etc) or launching attacks against websites.|
|Internal Unauthorised||Staff members may attempt to circumvent controls to gain access to material they do not have authorisation to view. A cleaner attempting to access a restricted file system would be an example of this.|
|Target Systems||If a MoJ IT system has been compromised through a security incident it may be necessary to collect evidence from that system to understand the method and source of the attack.|
|Telecommunications Crime/Hacking||The use of a computer to attempt unauthorised access to computers or networks is common. A forensic investigation might gather evidence from multiple devices, including router and firewall logs to establish the source and perpetrator of the attack.|
|Theft of intellectual Property/Protected Data||The unauthorised copying or removal of programs or sensitive data may involve the use of removable disks or other storage, such as a media player. Copyright theft would be an example of such a crime. Forensics can be used to prove a particular piece of equipment was used in such an incident, even if the perpetrator has attempted to cover their tracks.|
Appendix B. Guidance on sources and forms of digital evidence
Computers, networks, storage devices and their peripherals may be used in the commission of various incidents or crimes, or can themselves be the target of an attack. As a result, digital evidence may be collected from a variety of sources. Table 6 and Table 7 following provide a set of examples:
|Backup media (tapes, disks, etc.)||Actions that took place over a period of time, or in the past, might be recreated using backup media, or backup (archive) files stored on a device.|
|CD-ROM / DVD / memory sticks / floppy disks||Storage media are often used for stealing data or intellectual property. An understanding of storage techniques, and protective / concealing technologies such as encryption is required to reveal hidden data.|
|Digital cameras and video devices including CCTV||Increasingly, camera and video images are used as evidence. An investigation must handle this media appropriately to preserve evidence. Such systems need to have the same time source as IT for synchronisation purposes, as should Access Control systems. Ministry of Justice personnel are responsible for the upkeep of CCTV on MoJ sites.|
|Hard disks (internal and external)||Hard disks or removable media devices or phones may contain evidence in deleted or hidden files, folders or partitions not normally visible to users.|
|Media players / games consoles||These devices appear to be innocent entertainment devices, but may be used as mass storage or wireless transmission devices and include PC synchronisation capabilities. Recent generations of this type of technology have extremely large storage capacity in a physically small device.|
|Mobile Phones||Modern mobile phones contain contact information and call logs (inbound and outbound). They also have significant data storage capability, and the ability to synchronise data with a PC. They can also be used to wirelessly connect a PC to the Internet or simply connect directly to the Internet, often with the majority of functionality of a PC both online and off.|
|PC||This is the main unit which contains the hard disks and motherboard. Investigations may include: Copying volatile memory; Copying the BIOS; Examining hardware for unauthorised modification; Examining seals and asset tags.|
|Routers / Modems / Bridges / Firewalls||Configurable network devices often contain logs which can be used to attribute a machine to a course of action, and generally contain configuration information showing how the device was connected at a given time. It should be noted that a well known issue with device-specific logs such as these is that they do not record the system operating context within which they have been deployed and used. As this context changes dynamically and drifts away from any notional configuration over time, it is generally thought that examining such logs more than six months after an incident is of very little value.|
|USB / Firewire devices / Wireless cards, PCMCIA cards, and ‘flash’ memory cards||An array of devices can be connected to PCs through these ports and may need investigating. Interactions via this route can be subtle, and either innocuous or malicious. For example, some modern mobile phones charge themselves via the USB connection – and it can be difficult to distinguish this type of use from an inappropriate data upload/download. Furthermore, many USB connected devices automatically synchronise selected data with the PC, so a user may not be aware of the data transfer that has actually taken place. Memory sticks (or memory keys) are another class of USB device where care must be taken as their small physical size allows them to be used covertly with ease, and the latest generation of these devices includes the facility to automatically invoked data capture.|
Software and other artefacts:
|Application software||Some applications, such as accounting packages, may hold records of fraud or employee records and activities.|
|Operating System (OS) components and the registry||The OS is the software which controls the operation of the PC or phone. Security is enforced by the operating system, so attempts to subvert a PC frequently, starting with an attack on the operating system files. The registry is specific to Windows-based PCs and is the central repository of system management information. Examination of the registry can reveal: What devices have been connected; What application software has been installed and uninstalled; Usage history for applications; The state (configuration) of operating system components.|
|Application and Middleware Log Files||Many applications and middleware (particularly the large enterprise varieties) produce their own log files for various activities. An investigation may involve the detailed study of this information, or of the servers holding this information. Investigators need to be aware of any attempt to subvert log files in support of malicious activity.|
|Email records||IT systems can hold records of recent email activity, and mail servers retain extensive logs and records. Organisation policy may dictate an email retention period, such as seven years for everything. An investigation may involve the detailed study of this information, or of the servers holding this information.|
|System Log Files||IT systems produce log files for various activities. An investigation may involve the detailed study of this information, or of the servers holding this information. Investigators need to be aware of any attempt to subvert log files in support of malicious activity.|
Note: Different evidence sources require specific handling and documentation. This will need to be managed by the Forensic Investigation Owner.
Appendix C. Forensic procedures
This section contains a set of forensic procedures which should be enacted in addition to contacting the relevant IAO/Line Manager and the IT Security Manager when an incident occurs.
These procedures are designed to ensure as much evidence is preserved as possible, and to facilitate the transfer of equipment and material to a forensic investigator for further inspections.
As outlined here, consideration must be given to the strength of case required to proceed; therefore, a preliminary business impact assessment should be made based on whether any of the following are present:
- Evidence of a reported crime.
- Evidence of internal fraud, theft or other loss.
- Estimate of possible damages (a threshold may induce an escalation trigger).
- Potential for embarrassment/reputation loss.
- Any immediate impact on customers, business partners or profitability.
- Recovery plans have been enacted or are required.
- The incident is reported under a compliance regime.
For computer equipment which is switched on, the following process must be applied:
- Secure the area containing the equipment.
- Move people away from the computer and power supplies.
- If attached, disconnect any modem.
- If the computer is attached to the network remove the network cable from the data point.
- Do not touch the keyboard or mouse.
- Do not take advice from the computer’s user/owner.
- Allow any printers to finish printing (further evidence may be printing).
If equipment is removed before the investigator arrives then the following steps must be performed:
- Record what is on the screen and take photographs if possible.
Switch off the computer by pulling the power cable from the computer, not from the power socket.
Note: For laptops, remove the battery before pulling the power cable.
When removing the power supply always remove the end attached to the computer and not the socket. This will avoid data being written to the hard drive if an uninterruptable power supply is fitted. Then:
- If possible, label and photograph all the components in situ. If no camera is available draw a sketch plan;
- Label the ports and cables so that the computer can be reconstructed at a later date;
- Carefully remove the equipment and record serial numbers/asset tags;
- Ensure all items have been signed and completed exhibit labels attached;
- Search the immediate area for diaries, notebooks or pieces of paper that may contain passwords;
- Consider asking the user if there are any passwords, and if given, record them accurately;
- Make detailed notes of all actions in relation to the seizure of the computer equipment;
- Remove the computer equipment to a secure location.
For computer equipment which is switched off, the following process must be applied:
- DO NOT switch the computer on.
- Secure and take control of the area controlling the equipment.
- Move people away from the computers and power supplies.
- Confirm the computer is actually switched off – some screen savers can give the appearance that the computer is switched off. Check the hard drive and monitor lights to confirm this.
- Be aware that some laptops may power up by opening the lid.
- Remove the battery from laptops.
- Unplug the power supply from the computer. A computer that is apparently switched off may be in sleep mode and may be accessed remotely, allowing the alteration or deletion of data.
Appendix D: Forensic Readiness Plan template
|IT Security – Forensic Readiness Plan|
|IT System / IT Domain Name||[Enter the name of the IT system or domain.]|
|System Description and Scope||[This section should describe the name and purpose of the system, including the protective marking level of the information it holds. Diagrams may prove useful where there is a complex interaction between systems covered in this statement/standard. It is important to include notes of where a part of a system is excluded from the scope of this plan e.g. an application which is managed by another function.]|
|Responsibilities and Ownership||[Complete a statement detailing who has ownership and who will be responsible for the administration of this plan. Where a third-party or managed service provider is responsible for all or just a component of the plan, a clear reference should be made to contractual responsibilities. Points of contact regarding forensic readiness should also be noted.] [Note: Each role outlined here must be named in this section.]|
|[Name of Scenario 1]||[A summary of each scenario developed must be contained in this section, with full details provided as an appendix to the plan. Refer here for further details.]|
|Process and procedures|
|Process||[This section must contain a step-by-step plan of activities to be followed during a forensic investigation. Refer here for further details.]|
|Procedures||[This section must contain details on the initial forensic procedures which should be followed once the decision to undertake a forensic investigation has been made. Refer here for further details]|
|KPIs / Performance measures||[Include details on the KPIs and SLAs associated with this plan. Refer here for further details]|
|Continuous improvement||[Include details on the continuous improvement measures associated with this plan. Refer here for further details]|
|Training and awareness|
|Capability and staff training||[Include details of how staff training measure outlined here are met.]|
|IT System Manager||[Enter the name of the IT System Manager.] [DATE OF APPROVAL]|
|Information Asset Owner||[Enter the name of the Information Asset Owner.] [DATE OF APPROVAL]|
|System Accreditor||[Enter the name of the system Accreditor.] [DATE OF APPROVAL]|
Note: It is a legal requirement in the UK to hold communication logs for up to 12 months from the date the communication took place (although not the content).