Increased media attention on cyber incidents, strong data protection legislation and regulatory interest in security has brought increasing investment and progressive improvement in proactive security within companies.
This usually takes the form of a manager responsible for information security, and the introduction of technical security controls. However, I have seen companies struggle with optimising the use of these controls both in defending against attacks, and responding effectively to an incident when an attacker breaches these controls.
Companies need to focus on developing an incident response corporate mindset. As well as evaluating the adequacy of their information security capability based on the real risks they face, they need to identify potential threats applicable to them gleaned from real incident scenarios.
The first step is to prevent an incident from occurring. Decisions on choosing preventative measures should not be made in isolation. A key element of this step is to learn from past incidents.
As standard practice, companies should conduct periodic risk assessments of systems and applications in order to determine adequacy of controls and make any necessary decisions on investment and improvements.
However, I've observed that there is often no clear understanding of the applicable threats, such as organisation-specific threats or industry-specific threat, when undertaking risk assessments. This is because organisations rarely organise, report or analyse security incident information through a cohesive process. This, in turn, prevents them from learning from their own experience and those of their peers.
Risk assessment decisions and control choices tend to be made on the basis of hearsay or perception of industry best practice obtained from news feed chatter or, sometimes, it's even based on what the security team thinks would be interesting to implement.
Ideally, these security risk assessments should be based on real threat scenarios identified using incident information, using an organisation's own experience i.e. its own incident database combined with the experience of others like industry incident databases such as the CERT Insider Threat Database, or the DataLossDB created by the Open Security Foundation.
Companies could also benefit from the advice of an incident response specialist who could advise them on the correct allocation of resources toward prevention.
We all know that even the best defences will eventually be breached, but I've come across many companies that are ill prepared when this happens. Some of the key elements of good incident response practice are:
- An incident response procedure document that includes a key contact list for team members and others within and outside the organisation
- Clearly assigned responsibilities in the event of an incident
- Run books for key incident scenarios
- Skilled personnel
- Physical infrastructure like a ‘war room' for central communication and coordination in the event of an incident and a secure storage facility for securing evidence and other sensitive materials from the incident
- Incident response tools such as digital analysis forensic devices and software to analyse data, sniff packets, create disk images, preserve log files, and save other relevant incident data
- Documentation for OSs, applications, protocols, and intrusion detection and anti-virus 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 companies never go through the process of accumulating these resources in preparation - even where they do usually as a result of audit action, they do not maintain it. I find contact lists, environment baselines, run books and even software licenses are often out of date and this is discovered only in the event of an incident.
Another interesting challenge relates to the skill of incident response personnel. Only a very large organisation is able to provide the diversity or volume of incidents to allow incident handlers to maintain their level of skill.
One way to mitigate these difficulties is to hire a firm that specialises in incident response to support the company in the event of an incident. This could work, but I have often observed that the paperwork, including contractual agreement and signed non-disclosure agreements, is not usually in place so precious time is lost in sorting these issues out post incident.
Even when the paperwork is in place, the relationship needs to be an active partnership to be effective. In the response capability list mentioned earlier, you can see that a large part of the preparatory work - creating IT environment baselines, contact lists and setting up incident reporting processes - are still the responsibility of the organisation.
It is useful to seek external help with incident analysis, forensic tools and skilled personnel but companies still need to do their bit to ensure all the necessary up-to-date information is available to these people when dealing with an incident.
Furthermore, the overall responsibility for managing the incident rests with the company, so the incident response procedure must clearly define these roles and responsibilities. Although companies could seek the help of specialist organisations to help them with the process of accumulating the resources needed in preparation, this needs to be a collaborative exercise with strong involvement from in-house staff.
Detection typically involves:
- Monitoring alerts from internal systems in the form of intrusion detection systems, anti-malware, integrity monitors and logs
- Publicly available information on vulnerabilities and exploits
- Incidents raised by people
While technical monitoring is plagued by false positives, the most effective mechanism is alert and educated people. The importance of people as monitoring mechanisms cannot be overstated especially in the case of insider threat - be it sabotage, theft or fraud.
The most important requirement to harness this powerful resource is an easy-to-use and widely-advertised incident reporting system that is backed up with a culture of follow up. Follow up is crucial because users will quickly stop reporting incidents if they get the impression that they are not being followed up.
Containment, eradication and recovery
Once an incident has occurred, your organisation may be in a mad scramble to recover from the situation. The key areas to focus on in this stage are responsibility and communication. If you are using a specialist partner for incident response, it is important to remember that you can delegate tasks but not responsibility.
Your partner will have the necessary technical skills to deal with the incident but will not be in a position to make decisions or manage internal and external communications.
Should the incident be reported to law enforcement agencies? Who within the organisation should be informed regarding the situation? There is a trade-off between effort spent on evidence gathering and recovery from the incident. The level of diligence on evidence gathering will be determined by whether or not there is an intention to prosecute.
It is at this stage that the level of preparedness of the organisation, and how well rehearsed its relationship is with its incident response partners, both come to fore.
Ill-prepared companies panic when dealing with an incident and a mutual blame game between the company and its incident response partner ensues. When choosing a partner, it is important to evaluate not just their technical capability but also their ability to understand your business so that, using their knowledge, you can make informed decisions regarding the impact on your business and minimise the risk of litigation.
Finally, it is important to reflect on the incident to understand:
- How well did we perform in dealing with the incident?
- Were the documented procedures followed? Were they adequate?
- What would we do differently next time?
- Could communication within the organisation and with partners have been improved?
- What corrective actions can prevent similar incidents in the future?
- What should we watch for in the future to detect similar incidents?
The output from this process should drive improvement of all aspects of the incident response process.
In summary, companies need to start focusing on improving their ability to react to a cyber incident to complement their ability to stop them from occurring.
They need to use their reactive experience to drive the optimisation of their proactive security measures and a good, well-rehearsed incident response process is a necessary starting point for this.
Sandeep Kumar is a computer security and forensics professional.