Planning Your Information Security Incident Test

Was asking IT a mistake? The initial attitude of everyone else was that the scenario was inappropriate because software vulnerabilities are disclosed every day and incident response plans are not designed for such situations. Personally, I would have had more concerns that the proposed test was entirely centred on technology, which is only one, albeit important, aspect of incident response.

Is it a Good Incident Response Scenario?

Perhaps we should not be so hasty and instead consider the merits of the scenario – some vulnerabilities do lead to major incidents. Maybe the scenario should be tweaked to one where the vulnerability is being exploited; but how would we know it is being exploited? And then the more important question would be, “why wasn’t the vulnerability patched?”. What if the vulnerability is being exploited and we don’t know about it? The vulnerability could have been around for a long time before it was disclosed publicly, as they sometimes are. Should an old latent unpatched vulnerability be treated as an incident even if we are unsure if it is being exploited? If so, how old does the vulnerability need to be before it is considered an incident? How could it be determined whether privacy data was disclosed or if notification requirements are triggered?

An incident response test should be about testing the incident response plan – the whole plan. In that respect, the proposed scenario does cover many of the issues that need to be addressed in a good incident response plan:

• definition of an incident,
• identification of incidents,
• incident validation,
• who is involved in decisions,
• the relationship with security policies,
• ability to investigate the incident,
• appropriate action for recovery
• evidence collection, and
• notifications.

The proposed scenario has other advantages. It is easy to prepare and, as a desktop exercise, requires a minimal effort to run. The test can cover the roles of the non-technical business units, including information technology users, legal, communications, and senior management. This scenario should also meet policy or regulatory requirements for testing and check the organisation’s ability to comply with the notifications requirements in the Australian Privacy Act, and applicable regulatory requirements.

The Next Level

Congratulations on reading up to this point and not falling asleep, and congratulations to anyone who manages to not fall asleep during this test. It would be like watching a rerun of a C grade 1950’s horror movie where in the first few scenes an evil Superman-like character arrives, and the good guys are stocked up on kryptonite. Where is the tension, the horror, the blood? Our mate Charlie Farley does not announce what vulnerability he has found or what he is planning ohttps://tesserent.staging.spic...n doing.

If you really want to find out how well your organisation is prepared for responding to an incident, you need to make it feel real. It is time to bring in some professionals! You want the IT department to feel like they are the extras in Star Trek and not the regular cast. An incident response test can be as much of a training exercise as a verification of the plan. Penetration testers have the skills, means and ethics to play the role of the intruders in real-time.

A real-time test can uncover not only flaws in the plan, but also in the implementation of the plan. I have seen actual incidents where the operations centre detected strong evidence of an intrusion (anti-virus software was disabled) and responded by sending the service desk a normal priority service request. By the time the service request was processed, the intruders encrypted the first part of every file on the servers – it did not take long. Had the incident been assessed properly, the damage could have been much less.

Most organisations have a test and development environment that could be used for the exercise. With some suitable preparation and rules of engagement, the effort for restoring the environment can be constrained. There is also that extra motivational element when using a test environment that comes when the IT department realises that they will be spending time restoring systems from backups.

It would also be a pity if the effort restoring systems was wasted because the means for the intruders accessing systems was not found and blocked – the only achievement could be that evidence of the original attack is destroyed. Hopefully, the organisation’s backup and restore processes work well; after all, proper preparation and recovery are important parts of a good incident response plan and need testing too.

Selecting the Scenario

The correct scenario for an organisation very much depends on their maturity, and not all will be ready for a simulated cyber-attack, or more worryingly, for a full incident. I genuinely think it was a mistake to ask IT to assist in the planning of the incident because they are one of the key teams being tested. So why ask them for help with the planning of the test?

If there is one consistent lesson that I have learnt from the incidents I have been involved with, it is that the organisation inevitably could have been better prepared. Every incident leaves the organisation with a sense of dread and horror when they realise that they are victims, and every incident throws different challenges. It does not need to be a major incident such as a fraud, total failure of the storage system, or ransomware, it could be something as simple as sending an email with a lot of privacy information to the wrong recipient or not setting the correct access permissions to customer data on a website. What is important for the test scenario is that it seems real to the response team and is unexpected.

An important consideration in selecting a scenario is the type of incident that is likely to occur – we cannot choose which incidents are going to occur. If an organisation is at risk of a ransomware attack, then it needs to be prepared for it. Not all organisations have a strong IT capability, and planning a response, that accounts for that is important. It could be that the appropriate response is limited to isolating key information technology assets and then calling for assistance.

The Value of Incident Response Testing

Often a key factor for outcomes is communications:

• within the organisation for coordination and oversight,
• externally under the various notification obligations and
• externally, including to clients and partners, for managing reputational risks.

Just having confidence in this one aspect can be make a large difference to the reputational damage an organisation suffers.

Each type of incident can teach the organisation something new and add to their competence and confidence in responding to an incident. That is why a post incident review is so important.

Incident response testing can be a regulatory requirement for some organisations or part of their policy. Ultimately organisations have a choice. They can design and run safe tests where they know the outcomes and they will “tick the box”. Or they run tests that are a real challenge and vital preparation for handling serious incidents when they occur.

Preparation is key – preparation for identifying incidents, preparation for responding to incidents, preparation for notifications, and last but not least, careful preparation for testing the incident response capability of the organisation.

For assistance with any aspect of information security incident response planning or other aspects of cybersecurity, please contact us.