In the movie “Pulp Fiction”, the character Jules, played by Samuel L. Jackson, is trying to get information from another character, Brett, in a...shall we say...stressful situation. Jules finds Brett's communication abilities to be…lacking.

After noting Brett's intelligence ("Look at the big brain on Brett!"), Jules asks Brett a series of questions. In response, Brett stammers "What?" several times. The response from Jules is priceless:

Jules: What country you from?

Brett: What?

Jules: 'What' ain't no country I ever heard of, do they speak English in 'What'?

Brett: What? 

Jules: you speak it? 

Brett: What? What?

Jules now points a .45 to Brett's head in an attempt to motivate him.

Jules: Say 'What' again! C'mon say 'What' again. I dare ya. I double dare ya...!

Needless to say, communications between Jules and Brett have broken down.

Effective communications and collaboration are vital to reducing the mitigation timeline associated with incident response efforts. Sure, communications during normal day-to-day operations may be nailed down in your organization, but there is a clear difference between those organizations who proactively prepare communication procedures for incident response and those who simply wait and try to address things on the fly. The difference is often easy to spot when evaluating how effectively information is passed between incident response teams, vendors and third-party support during an incident.

With this in mind, I present a few questions you should be asking yourself and your organization, as well as any other parties supporting your organization, from an incident response perspective.

(FYI: If you answer no or I don’t know to any of these questions, you probably have some work to do)

The top 10 questions you need to answer before a security incident occurs:

  1. Who are my organization’s primary incident response team members?
  2. Who are my secondary incident response team members? (in the event the primary responders are out sick, on vacation etc)
  3. Who is my escalation point at my ISP in the event of a DDoS attack? (Not the 1-800 number for first tier support, but the people you need to speak with to implement blocking and other ISP capabilities)
  4. Who is my direct contact at my Managed Security Service Provider and what capabilities do they have to support my efforts?
  5. Does every member of the incident response team have this information (team members, communication lines and escalation contacts) so that any member can act in times of crisis?
  6. What are my extended communication plans with hardware and software providers (border router, firewall, load balancers, web application firewall, DDoS mitigation)?
  7. Do I have a plan to stand up and invite all of these teams to an incident response conference bridge if I experience an incident?
  8. Do I have an alternate communication plan if the attack is focused on crippling regular means of communication(email, phone, conference bridge availability)?
  9. Does my organization have internal communication channels established for instant messenger type functionality?
  10. Who is the incident manager during an incident? This question can become complicated when you have multiple third parties in the mix! And what is the expectation for receiving and sending updates to and from them?

Hopefully, you are able to answer these questions with confidence. I suspect, however, that many readers will have a challenge answering them with authority.

Remember, even if you can answer the questions with a certain level of comfort, it does not mean the process will work. One way to test the plan is to wait for an incident and determine how effective your communication plan was. But that isn't a particularly proactive approach. Alternatively, you may elect to stage tests of the plan by simulating real attacks. At NTT Security, we offer clients and prospects walk-throughs of personalized attack scenarios. In either case, reviewing the performance of the plan will let you know how much work you need to do to cover the gaps.

A little bit of planning goes a long way but a lot of planning goes even further. When it comes to effectively mitigating security incidents, identify your gaps through a lot of planning…then close them before they result in an incident.