Forensic Readiness Planning should form an integral part of an organisation's Incident Response Planning (IRP).

To define Forensic Readiness Planning in one sentence: Ensuring that an organisation is collecting sufficient logs and storing them in a forensically sound manner in order to facilitate a thorough investigation of an incident and if necessary prosecute the attackers in a court of law.

By default most organisations do collect some logs from their network devices and various operating systems, however, most don't manage them or consider the "audit policy" which defines which events are recorded.

It is so frustrating to be called out to a cyber security incident, only to discover that the logs haven't been collected, or have been overwritten as it delays being able to identify the root cause.

Before we begin allow me to issue a word of warning, managing logs can have an effect on host performance, network utilisation and most of all storage.There is therefore a balance to be struck and the audit policy needs to be carefully tuned, it's better to have just enough than too much.

The Forensic Readiness Planning workshop is often a deliverable identified in our Cyber Risk Review Workshop which is a high level discussion with the client around what cyber security risks they face and in centred around numerous controls from various information security frameworks such as NIST and ISO27001.  It is more of a discussion than an audit and we would have already have an idea as to whether the client does collect logs and whether they have an effective SIEM in place along with a multitude of other relevant controls.

Once we have ascertained that the client's log retention is relatively mature, we start with a few use cases in a workshop and exercise the current audit policy and log management procedures, it is preferable to have the CISO in attendance and the risk owner if they aren't the same person, the Incident Response Team (if there is one) and most important of all, the IT administrators responsible for both the servers and the networks. Forewarn them about what you are aiming to achieve and make them look good as they are pivotal to your endeavours. If there isn't an Incident Response Team, suggest the workshop attendees become the nucleus of one.

At this point it is worth discussing whether the organisation needs to comply with standards around how long logs need to be retained for, be they National or International or other.If no retention times are identified, discuss with the workshop how long they should retain which logs for, consider the Insider Threat and the sleeping compromise.

By this stage of the workshop you'll know how effective their Incident Response Plan would be in a crisis, if indeed they have one. Whilst the IRP is a separate piece of work, elements of it are pivotal to the organisations forensic readiness. Outline in the workshop a few points which will be revisited at a later stage:

Points of contact. Check whether the client maintains contact information (in and out of hours) for their ISP, outsourced providers such as website, cloud datacentre etc. Communications with these external entities may be essential to the investigation.

Reporting. Are they legally bound to report an incident to the authorities/clients and if so when and to whom. Are they ethically bound to report incidents to their clients. As part of the IRP it is wise to have already engaged with a crisis comms/PR organisation and come up with boiler plate releases which may minimise reputational damage, trying to be articulate after fighting fires for 72 hours is never easy, far better to adjust pre-prepared communications.

Gossiping. Ensure that as part of the IRP, staff are to be told not to discuss the incident externally via any means, especially social media as this could prejudice the investigation as well as the reputation of the organisation. 

Appetite to prosecute. Whilst using the logs to investigate what has happened is one thing, many organisations may not wish to prosecute the attackers for a variety of reasons.This should be considered prior to going to the expense of collecting data in a forensically sound manner, though legal obligations must also be considered. It is worth considering this for each of the following use cases:

The first use case is an eternal attacker breaching the perimeter, pivoting and moving laterally through the network. What logs are currently collected from what devices and applications to track this movement?

The second is a successful spearphishing attack which is exfiltrating intellectual property from the desktop, try not to get bogged down in detail about the attack and keep it broad.

The third is an Insider either sabotaging the infrastructure or exfiltrating intellectual property. An important discussion point for the insider threat is whether the audit policy records successful read/write as well as failures, the latter is the usual, but won't identify which files your trusted insider or privileged attacker has accessed/changed. The logs collected on successful read/write can be huge and require a large of amount of storage.

These 3 use cases cover a multitude of sins, though are not extensive we would usually delve a little deeper in client specific use cases and especially covering the threat actors and vectors which they are likely to face.

The most important part of such a workshop is the action and remediation plan, it is also an iterative process which needs to be regularly revisited along with exercising the IRP.  We like to round off a Forensic Readiness Planning engagement with an actual breach (Penetration Test) which exercises both the IRP and FRP.

Please feel free to get in touch if you would like us to run a Forensic Readiness Planning workshop with you

© Computer Network Defence Limited 2019