Template for: Incident response test for SMB size companiesType of test: Desktop scenario simulation

Estimated duration: 3 hours
Number of participants: Minimum 4 but can fit up to 10
Requirements:

  1. This scenario will likely not work for companies that have “always on” DDoS mitigation services.
  2. It will also not work if you are using Google mail for business or similar for email services.
  3. There must be network engineers or network security analysts present, if you do not have anyone like this, involved your best techs / security engineers.
  4. There must be business representatives present who can realistically prioritize efforts
  5. There can be CIO/CISO involvement and business line leaders / product managers. You choose for your company who you want to involve in this test

Management summary:

The purpose of this scenario is to test how the company responds to a cyber security incident and to use the responses in whichever form they might be to train all involved employees from IT to executives in their roles & responsibilities in an incident response situation. The scenario will feature a relatively advanced, financially motivated attacker that is able to find and deploy unknown exploits at scale both to deploy botnets and to disrupt your business. The attacker would be able to do more than is done in this scenario, but I believe the scale of this attack to be a good training exercise.

The scenario has been “Scripted”as a kind of role-playing exercise and it will require someone highly knowledgeable about the company and information security in general to function as the “Game Master” (GM) of this exercise.

The scenario plays out over a number of rounds. Each round starts with you handing out a description of what happened (in successive rounds, what happened since the last round) and then the participants must figure out how to deal with the situation. A good recommendation is to try to analyze the information given and assess possible alternatives as a group (lead by either the technical people present or whoever is available to do this – read scenario text for who is NOT available). Once the situation has been analyzed, the participants must inform the GM of what they try to do. The GM= the scenario manager will then be able to give feedback and tell them what happens depending on what the participants try to do. Once the allotted time has expired or they have exhausted all the options they can identify, the GM will increase the “round counter” and hand out the next round description notes.

There is also an amount of preparation that you have to perform in order to be able to carry out the exercise successfully. To continue past this point, select a GM for your exercise and give the GM access to this full document. Do NOT read on unless you are the GM chosen for this exercise.

GM Scenario preparation items

As GM you must:

-Do not allow anyone participating in the exercise or anyone who might “spill the beans” to participants to read anything in this document from page 2 and below. The unexpectedness built into the exercise is crucial for optimal simulation and training purposes

-Allow only participants or executives approving the exercise to know that:

  • You will be simulating a loss of a critical business IT service
  • The exercise will develop from the starting point to test responses in depth
  • Making errors is great – it’s even recommended to mess up because it increases the potential for learning. So if you **** up, don’t worry, no one will come after you for it, this exercise is meant to make everyone better

-If vendor/third party/ISP responses are requested, you must act as these

Research and make sure you know:

-Which set-up you have for email services for the company including:

  • Amount and type of servers running email including software versions
  • Where the servers are and how they are set up (cluster, LB) if run in-house
  • If run or managed externally, make sure you know how it is set up there and who is managing it, what the SLA’s are
  • DNS servers used / MX records

-Your company Incident response policy/processes and business continuity plan/disaster recovery plans

-Any SLA’s you have with third parties including ISPs

-Bandwidth available to your company per ISP per location you have email servers plus bandwidth available total at those physical locations

-SPOC’s (single points of contact) and/or Hierarchical escalation points for SLAs and outsourced services

From this point on this document will contain notes for the reader about the scenario – what actually happened will be described in RED TEXT. Make sure to edit out red text before printing the below documents for participants. Cut off each round into it’s own piece of paper to be distributed individually.

Scenario initiation description:Email service interrupted

Describe the setting the participants should imagine themselves in – it’s a Friday morning around 09.00 when something happens – the email service is interrupted and the goal of the participants is to find out what happened and try to prevent it from happening again.

  1. Company IT is notified by a flood of phone calls early on a Friday morning at around 09.00 that no one is receiving e-mails anymore
  2. Responsible managers cannot be reached via phone at this time (you tried)
  3. You can pretend to be gathered on a group phone call, in an office or meeting room (virtual maybe) or to be communicating via individual phone calls. Pick the option that most realistically resembles your company
  4. The participants should probably try to identify an Incident response team lead at this point to have someone in charge. Note down who.
  5. What doesIT and the businessdo? Note down responses.

Scenario round 1: Restoring service?

Let participants read the scenario initiation and then let them consider how to proceed. Virtual time: Friday morning 09.22

  • The technicians/engineers will do assessment
  • In all likelihood it will be chosen to perform some kind of incident response. Hopefully this gets authorized before attempted
  • Engineers&techs will try to repairthe email service. They should report a status to their regular reporting lines ->important here is that the tech engineers present specify who will be contacted how/by who/when.
  • At some point here the present-at-this-simulation managers/executives will probably decide to not activate the company BCP
  • Technical details will be revealed to IT as they request them from the scenario manager – Appendix 1
  • Ask the business what is the Business doing/planning in this situation if they do not start discussing this amongst themselves. Note down answers.
  • GM will inform of changes / new facts as needed

Scenario round 2: Oops

Virtual time: Estimated 09.45
Email is down again. Who does what?

  • IT/security teams should investigate in-depth to find out what’s going on
  • Scenario Manager will inform of changes / new facts as needed
  • What is the business doing/planning
  • At some point here executives should consider if Incident response should be escalated to some kind of business continuity response (more resources allocated for that normally) but they will probably still decide to not activate a BCP at this point, because IT techs/engineers/security will probably convince them that they can still fix this. If the company BCP procedures get activated, proceed to planning for the steps to complete this process and give GM feedback as needed

Scenario round 3: What is actually going on?

Virtual time 10.00: E-mail goes down again;An employee (probably marketing or executive with access to your in) has just before this received an e-mail, which the GM will hand-out at this point.

What does the Incident response team leader now do? IT/Tech/engineers/security do what?

-IT/Tech/engineers/security should describe the problem and possible solutions`

-What is the business doing/planning?

-How does the company management present react to the letter?

  • If the company BCP has not been activated yet at this point: GM should ask the question – is it time to consider moving from incident response to business continuity response procedures? Would it make sense?If the company BCP procedures get activated, proceed to planning for the steps to complete this process and give GM feedback as needed
  • If needed or if it’s decided at some point to pay the ransom, show letter 2 (Appendix B)

Scenario round 4: How do we fix our business services?

Virtual time: (Unestimateableuntil the scenario is running, since it will take an amount of time for IT/tech/engineers/security to find out what’s really going on). At this point, you are back in business, your e-mail services are up and not going down again. What are the learning points? What are the action points for future improvement? GM note down all responses.

If needed or if it’s decided at some point to pay the ransom, show letter 2 (Appendix B)

The end.

Incident response team leader checklist:

This check list should be handed out if the participants select an incident response team lead. If not, do not hand it out at all, but inform the participants of it’s existence after the termination of the exercise.

  1. Remind Business Management tore-consider the decision of whether or not to activate the BCP when appropriate.
  2. If a BCP has been activated, instruct each team and get from them an action plan(if you require them to do anything) and define success criteria, approve/discuss these with the incident response team as a whole

Appendix A: Letter from the attacker

From:

To: in

Hi There

I see you having some troublez with e-mails. Your mail service has stopped working two times. I hvae good newz for you! I help trouble go away, it’s easy! Send bitcoins equal (Modify if needed: 10000 USD) to 1P6k9i4MDaZzHLNTpCpxFqtnncF8BFfzqG

And all is stop.

Signed: Your helpful friends.

Appendix B: Letter 2 from the attacker

From:

To: in

Hi There

I see you having some troublez with e-mails. Your mail service has stopped working two times. I hvae good newz for you! I help trouble go away, it’s easy! Send bitcoins (Modify if needed: 50000 USD) to 1P6k9i4MDaZzHLNTpCpxFqtnncF8BFfzqG

And all is stop.

Signed: Your helpful friends.

Appendix C: All the gory details for the GM to know

So, you’re facing an attacker that wants to earn some fast cash by holding your company for ransom. The attacker will initially DoS your mail service by sending initially some crafted packets that exploit a known, unpatched vulnerability in your mail system. You can find one, if not just make it up. Should your existing mail service be fully patched, the attacker will use an 0day to crash the mail service – find the exact service/one of the exact services that would work for this and make up an 0day for this. It doesn’t matter that real attackers would not use an 0day for this purpose, this is only an exercise and the point is to bring your mail service down without using more than 1 packet. The goal of incident response is to try to identify this packet and somehow mitigate it (logfiles won’t help, nothing short of a PCAP will be enough to write a signature to drop this if you have perimeter devices that can do so).

Once you try to mitigate the crafted DoS or restart the mail service more than twice and ignore the ransom note, the attacker will use a massive DDoS attack to take you down again the third time, even if the ransom has been paid – the ransom amount will just increase (see letter 2 Appendix B). Adjust the amounts in letter 1 and 2 to be a significant impact to your company’s business.

Incident response during this exercise should include things like trying to mitigate on the perimeter if you have anything to do so, calling ISP’s to get ISP-side mitigation, bringing on board a fast DDoS mitigation service possibly and discussing longer term plans for this. Incident response could choose to reach out to a CERT or consultants/Incident response companies for assistance with finding out the cause of the crashing mail service, if they do so, just play along because it will become obvious once the ransom note arrives.

You might have to be creative to re-mess up things if they get fixed too craftily by sneaky engineers, but you can do whatever you want, this is roleplaying and you are the GM, your word is law, even if someone should say “but that’s not how it works” or “that’s impossible” – these situations should be avoided at all cost, but if it happens just explain the complexity of being the GM and say that you have to move the scenario forward to reach the learning points.

When participants ask questions you may have to make up additional details that fit into the scenario, remember your word is law.

The attacker is trying to show your company that he/they can bring down any part of your infrastructure they want, when they want to, and to get you to pay the ransom as fast as possible. Pure profit motive.