Forensic Readiness: A Primer

Incident Readiness with forensics is becoming rapidly established as an integral part of information security, forming parts of standards and guidelines such as PCI DSS and CESG’s Information Assurance Maturity Model.

Security had long been seen as a financial black hole, a necessary requirement or a compliance hurdle. Now as the maturity of organisations shift to investing in security is a business enabler, so too should forensic readiness be seen as a core tenet of successfully managing information securely. A poorly managed security incident can heavily impact an organisation, from increased downtime and sanctions or fines, to increased negative publicity and public exposure. This article presents an overview of some basic measures to take toward preparing for security incidents and forensics investigations, in short allowing organisations to effectively manage the identification, containment and follow up of an investigation.

How should organisations ensure that they are best equipped to prepare for incidents so that they do not have a significant impact on their business? The following key points have been successfully implemented by MWR InfoSecurity’s clients and are a starting point for all Security Managers.

1. Accept that Incidents will occur

The first step in preparing to manage security incidents is to ensure that your organisation (supported by governance) has the right mindset. ‘It won’t happen to us’ is far too often an informally accepted understanding but is not an appropriate strategy; it wasn’t going to happen to TJX 1, ACS Law 2, Heartland 3 or Hertfordshire County Council 4 but they have experienced the very public implications of major security incidents where their strategy could be argued not to have worked effectively. Trying to prevent incidents from occurring is clearly of importance but an acceptance that effectively managing the ones that do occur is just as important to your organisation.

That is not to say that you should panic at every alert or implement over-zealous security controls, but an awareness of the threat that your organisation faces is critical in managing any security incidents. Enacting a response plan for any potential incident, even if the process later proves the incident to be of little or no risk, ensures that responders are suitably experienced and encourages an atmosphere to report, investigate, close and continue.

A survey by the Ponemon institute in 2008 5 revealed that “first time” intrusions cost more than similar respondents who had suffered previous intrusions. Organisations that have a practiced and responsive incident handling team will suffer lower costs when confronted with a serious breach.

2. Educate Staff

It is a rare occurrence for an incident to actually be detected by a trained and capable first responder. It could be a staff member targeted with a phishing email, a third-party reporting data loss or the IT helpdesk reviewing abnormal behaviour. For this reason your entire organisation needs to be clear on how and where to report incidents so that the appropriate experts can respond rapidly.

First, staff need to be able to recognise a potential security incident. MWR have reviewed a number of incidents where late detection, caused by staff not having clear information on how to recognise and report incidents, has resulted in a significantly higher impact. Erring on the side of caution offers at best, an early response and limited impact and at the very least offers experience and training for your response staff. It is also vital in this case that the reporters of a security incident are not victimised or else future reports may not be so forthcoming.

Secondly, staff need to be made aware of who to report an incident to. Many cases have escalated needlessly because of late detection, due in part to a lack of clear reporting structure for security incidents. Smaller organisations may want to nominate line managers for forwarding incident reports. Larger organisations would benefit from setting up dedicated email and phone contacts or support websites with submission forms. In each case this information must have high availability to be effective; regular emails, poster campaigns ,workshops. Once sufficiently established, the benefit to response times can be measurably improved.

3. Keep response plans flexible

At the early stages of an incident (once detected) information is likely to be limited in its scope and accuracy. Whilst honourable in intent, a rigorous procedure is normally not the best approach particularly when new information is rapidly being discovered that can change the focus and direction of an investigation. An incident response plan should therefore be flexible enough to cover any potential incident whilst remaining well defined so as to ensure a considered and thorough approach. MWR have noted a number of ‘template’ incident response plans in use that, whilst allowing an organisation to meet compliance requirements, offer little benefit when used in practice.

The best approach for defining such a plan is to define key milestones in an incident response situation where reporting and discussions occur. The exact duration of these milestones can vary to account for different requirements or responses. Such an approach ensures that all incident response team members are working towards the same goal, new information is regularly circulated and helps to reduce the risk of multiple responders acting independently which can end up hindering more than helping the investigation.

Organisations developing their incident readiness capabilities can extend this by categorising incidents and invoking individual response plans to best deal with the incident. One example of such a set of incident response plans could classify an incident as either malware, denial of service, malicious insider or web server attack. This allows for teams to respond even quicker to an identified incident with the correct tools and procedures.

4. Enable communication

An absolutely critical part of managing a security incident is ensuring that the appropriate parties are kept informed. This will be largely dependent on the type of incident but could include internal staff, regulatory bodies, clients and third-parties and the media. Whilst this should not be so early on in the process that it could cause undue alarm (or be based on early information which turns out to be incorrect), it should also be sufficiently early to provide assurance that it is being dealt with appropriately. Taking an active part in communicating the results (and current stage) of the incident handling process offers assurance to those whose data might be compromised that it is being handled appropriately, and helps limit any inadvertent information leakage.

There is a danger that, should the organisation be fortunate enough not to suffer an incident, the cost of preparing for future incidents could be seen as unnecessary (see point 1). An important part of internal communication, particularly with financial controllers, is also the effect that incident handling procedures had for any particular incident. What impact would the incident have had if it went undetected? Did the incident response plan effectively limit the impact? Was there part of the process that could be improved? If an incident has been detected, contained and remediated in a timely manner, this was a success on the part of preparedness.

5. Enable Logging

If there is one thing that can cripple the investigation of an incident it is a lack of detailed logs. Logs are not only valuable post-exploitation however. In a recent investigation performed by MWR it was unclear how the attack was executed as logging was not enabled. A clean-up followed and logging was enabled, at which point the attacker struck again; this time the logs showed exactly how the attacker compromised the systems and the vulnerability was closed before further damage could ensue.

Performance or storage issues are often touted as reasons for not enabling logging but in the majority of instanced this is rarely the case. For all but the most high traffic sites log files should take up minimal space. These should ideally be stored on a separate system (to preserve their integrity in the event of a breach) which can be as simple as a file serve. The cost of such a solution need not be prohibitive either as basic storage can cost very little; ultimately a basic cost-effective solution is far superior to no solution.

6. Dedicate budget and resource

When organisation requires a period of cost-cutting it may seem somewhat excessive to assign budget to an unknown event or even dedicate resource to ‘emergency’ tasks such as monitoring logs during the period of an incident. Organisations that MWR have worked with have reported actually saving money through this process; when an incident disrupts normal working practices even a single day saved can more than outweigh the budgetary costs. With the pressures on delivery of day-to-day activities, maintaining vigilance throughout the investigation of a security incident often takes second place. Supporting information takes longer to gather, vital warning signals are missed and critically, the window of the incident from breach to containment becomes significantly larger.

Project managers will need to focus time and effort in managing any compliance programs, as a breach could place the organisation in remediation or at risk of fines. Organisations subject to PCI DSS requirements will need to carefully manage the program, along with their acquiring bank and the card brands, and data losses may receive fines from the ICO (Information Commissioners Office)under the Data Protection Act. It is also not unknown for acquiring banks to require a large sum to be frozen as a ‘goodwill gesture’ toward investigating and managing the breach. MWR have noted a number of instances where retaining budget for such a situation can mean the difference between sink or swim, particularly for smaller businesses with a less stable cashflow.

A survey by Solar Networks 6 found that “while 76% feel that they need to do more and their organization would benefit from more incident response tools, 44% say that they spend less than 25% of their overall security budget on incident response”. Whilst managing security incidents is the domain of the security team, dedicating budget to dealing with the impact of security incidents should be kept separate to the general security or IT budget. Security incidents are typically indiscriminate about the department that they impact and affect the organisation as a whole, be it through downtime, data leaks or fines. The company may need to respond with temporary work sites, increased staff capabilities, third-party relations or (most critically) an expert forensic investigator on retainer.

Summary

Organisations typically have limited experience in implementing incident management and forensic readiness and costs of implementation can be considerably reduced through support from suitable specialists. MWR have identified this need and developed a service that can help an organisation achieve these things and much more, for more information contact us and take a look at Foresight.