WAR GAMES - Simulating Security Incidents

Why it's a good idea

There are a myriad of reasons to test in peace time, the controls and processes which collectively represent your incident readiness. These include:

• Validating your Incident Readiness - testing can confirm that you are as ready as you think you are, and that nothing has changed resulting in an end state which prevents you from initiating IR. 
• Assess Controls Coverage and Identify Gaps - testing can confirm your controls coverage is adequate as well as highlighting those gaps which you'd rather not have in the event of a real issue.
• Demonstrate value of investment - you've probably spent a lot of time and other people's money acquiring controls, attracting talent and preparing for the eventually of an incident. Internal stakeholders will likely already be looking for assurance that their investment has been worth while. 
• Demonstrate investment and commitment to interested parties - internal stakeholders considered, you'll likely have external parties who will have an interest in your incident response capabilities. In addition to your customers these might include regulators, certification or industry bodies and shareholders. 
• Maintain Awareness - there is never a good time to have an incident and chances are, when it happens, it will be at a bad time. Everyone has a day job to do but rehearsing incidents can ensure that the eventuality remains present in people's minds and they remain alert and prepared to respond. It also provides those same would-be respondents with some confidence that they are prepared. 
• Align Priorities - it might be the case that there is a known weakness or gap in your controls and procedures. Simulating an incident which highlights this can help illustrate this and realign priorities to ensure the deficiency is addressed before it can be exploited. 

Going About it 

Just like any other initiative, simulated incidents require adequate levels of sponsorship and planning to be successful. 

Buy in and sponsorship

Start by looking to secure backing from the senior leadership team. 

• Be candid, and outline the proposal in terms of benefits (above).
• Enquire if the leadership team have any specific areas of concern or scenarios they would want to run through. If there is something keeping them awake at night, start with that.
• Reassure them over any concerns around complexity. You should aim to start small then build your testing regime over time.
• Secure a sponsor - someone in the leadership team who agrees to settle disputes or receive complaints during the exercise. 
• Secure a deadline - the senior leadership team should (ideally) demonstrate their commitment to the initiative by setting a deadline for your first test. 

Stand firm

With sponsorship and a deadline secured you should look to begin planning your simulation. Warning - as soon as word gets out about what you're planning to do you'll likely start to receive questions and/or complaints. Some people might even look to make things ugly and derail the initiative completely. 

Likely sources will include those who consider testing activities less important than business-as-usual activities. You'll probably already be expecting issues with certain teams or departments. This is why adequate sponsorship is so important.

Try understand why people have issue and demonstrate that you can see it from their perspective. Rhetorically, a 'reality check' might defuse the situation and secure their support:

• There is never going to be a good time to have to handle an incident. 
• As an organisation, we need to be sure we're ready and able to handle incidents.
• The instruction has come down from the leadership team - it must be followed. 

Planning

Set objectives

Objectives of the exercise can be as high or low level as you want. An appropriate starting set might include:

• Objective 1 - Test the incident response processes of the company.
• Objective 2 - Exercise IR collaboration between teams and departments.
• Objective 3 - Identify improvements opportunities in security monitoring.
• Objective 4 - Raise overall awareness of current security threats.

Pick a scenario

Don't go full nation-state-cyber-war on your first attempt. Hopefully you've got some idea of your threats and what their capabilities are. In the absence of C-level steer, consider breach write-ups or if you're (un)lucky enough, any breaches or incidents reported by your competitors. If you're still struggling for inspiration have a look at @badthingsdaily, an account dedicated to incident scenarios.

First time scenarios to consider might include:

• DMZ Host Compromise - Your Ops Team / MSSP / ISP contact call to advise you that they have observed a sudden spike in traffic between a host or hosts in your DMZ and known-bad C2 destinations.
• DNS Hijacking - After receiving multiple complaints from a variety of sources over the weekend your 1st line support operatives realise that your primary domain has been hijacked and all sub-domains employed by the business no longer resolve to your IP space.
• DDoS Ransom Demand - Your Financial director calls you on Sunday evening after receiving a direct call from someone claiming to have a significant DDoS capability. They have threatened to target all your services unless the demands they have emailed over are met. 
• Ransomware on the central file-server - Service support contact you to advise that a user has detonated ransomware and that this has found the central file-server used by many employees. Many files appear to be encrypted now and the number of reports is rising. 
• Third-party with Remote access notifies you of a breach - a third party with persistent VPN connectivity to your data centre calls to inform you that they have suffered a significant and lengthy intrusion. They have engaged external expertise to assess the extent of the breach and to hopefully identify the source. 
• Law enforcement contact - a national branch of law enforcement notify your managing director of a potential breach. During an investigation of another breach they happened to come across a file store employed by a malicious party. During the course of the investigation they have found significant volumes of, what appears, to be your data.

Once you select your scenario you'll want to break it down into stages to allow you to work through the narrative in a way that allows you to explore the theme of the issue, review your controls and procedures to satisfy your objectives. 

Example Scenario Plan

Nominate and elect your adjudicators

The exercise needs someone at the helm. In addition to providing the injects which steer the simulation through the narrative they will need to be able to answer questions and make decisions which drive the scenario in the direction of the the objectives.

If you need to, change it up

Depending on how it's going you might find yourself wanting to change the script and focus on certain areas -or- if things aren't going well then switching things up save to prevent the exercise from becoming a flop. Don't be afraid to adapt the scenario to get the most out of the exercise.

Wrap it up

The end of the simulation isn't the end of the exercise. In addition to thanking everyone for their co-operation and commitment to the exercise, it's important to get participant feedback from everyone whilst it's fresh in their mind. Steps to consider when concluding the exercise include:

• Formerly concluding the exercise and communicating the 'stand down' order business wide. 
• Use a prepared questionnaire to capture feedback in line with objectives you set. 
• Request HIGHS, LOWS and NEAR MISSES as part of the feedback. 

Wash-up

Your after action reporting should concern itself with capturing critical observations and findings from the scenario and then go on to recommend an improvement plan. Areas of focus might include:

• Detection capabilities - controls coverage and deficiencies, time to detection, availability of and ability to render logs and evidence, observed issues with background noise and false positives. 
• Response capabilities - effectiveness of procedures and play books, familiarity of controls and supporting systems.  
• Handler performance - mastery of issue, identification of weaknesses and training needs, effectiveness of communications and stakeholder management.

Act on what you learn

Your critical findings, observations and recommendations should inform your view of the world and be used be to set priorities. In addition to sharing what you've learnt with your stakeholders be sure to update any gap and risk registers you maintain.

Reset the clock (to do it again)

Rehearsing incident response should be a repeatable affair not a once in a long-time or life-time exercise. From the moment you set out to test your capabilities you should aim to establish a maintainable testing regime which you can use to achieve and demonstrate continuous improvement. By acting on what you learn and demonstrating the value of testing to the organisation you can go some way to ensuring this happens.