Join Thousands Who Have Benefitted from the Virtual Event of the Year - WATCH NOW Should all incidents be treated the same? Seems like a simple question, but the answer can have big implications.

Think about an email outage that causes a few users to contact the service desk, complaining they can’t get to their email. If the outage is due to a configuration issue after an update for the server, then the impact on the organization can be quantified to the lost productivity for the impacted employees. But if the outage is due to some malicious activity and the email outage is the first indicator of a larger security breach, then the impact to the organization can be very far reaching.

The Service Desk: IT’s Security-Incident Front Line

For most service teams, incident management is focused on resolving incidents quickly and getting employees and users back up and running again. That approach works for most types of incidents, but as with the above example, security-related incidents should be handled differently because of the higher potential risks and impacts. Even with dedicated security teams, the service desk will be IT’s face and front line when a security incident occurs, so it needs to be an integral part of a coordinated response. Throw in the fact that service teams often act as the hub for communication and coordination during major incidents and the case becomes even stronger.

Since the worst time to plan for how to deal with a major security incident is in the middle of one, service teams need to proactively plan and prepare for how to handle security incidents. Otherwise, as one IT director said, “You’re trying to build the airplane while on final approach.” Given the increasing frequency and threat of security-related attacks, for most organizations it’s a question of “when” a major security incident will occur, not a question of “if.”

A Security Incident Management (SIM) Plan

One suggestion for service teams developing their Security Incident Management (SIM) plan is to do so in coordination with not just other IT teams, but ideally also with other departments that may potentially need to be involved. Why? Because a major security incident may have business impacts well beyond the scope of the immediate IT issues, such as legal responsibilities, privacy risks, and governance questions. That’s not to say that everyone should be involved with each security incident, but a response plan should be comprehensive in dealing with and mitigating the risk from a wide range of potential impacts.

When you start developing your SIM plan with the extended team, define the roles and responsibilities for each involved team. Think about leveraging a RACI model (Responsible, Accountable, Consulted, Informed) to help map out these roles and responsibilities based on type and scope of security incidents. Find and agree on the touch points for each team, not just the Security team. Don’t wait until a breach occurs to determine who needs to approve specific actions; make it part of your SIM plan, along with response times and alternative approvers so requests don’t “hang” during critical moments.

Also think about what data and information you need to capture during an incident. This can help in the moment when trying to figure out the incident scope and response, but also afterwards when things settle down and you’d like to evaluate and improve your response.

Similar to a pilot preparing for a flight, create checklists for what needs to be done, including for operational tasks like isolation, shutdown, recovery, and testing for different types of services, applications, devices, assets, and CIs. Leverage automation tools to remove as many manual steps, checks, notices, and approvals as you can; it’ll reduce the risk of things “falling through the cracks” when you’re in the middle of a security response.

Once you have your SIM plan, train and regularly practice the plan with your staff. Train them to identify possible security incidents. Use practice runs to check the thoroughness and effectiveness of your procedures, looking for areas to improve.

SIMilar to Your Disaster Recovery Plan

Your SIM plan is similar to your Disaster Recovery (DR) plan—it’s good to have it ready but you hope you don’t need to use it. But should you encounter a security incident and need to activate your SIM plan, be sure to invest time soon after the incident to determine how you would improve your response. Plan to review the incident before memories fade, and gather the data and information collected during the incident.

During a review with the response team, investigate and determine the background for the incident. Answer the “news reporter’s” questions of “Who, What, Where, When, How and Why” for the incident. Keep in mind that some of the answers and information may be needed for legal proceedings.

Also evaluate the overall response. Analyze and grade how quickly threat identification, mitigation, and recovery happened. Gauge the effectiveness of current defenses and training, look for areas to improve, and apply lessons learned to be better prepared.

For major incidents, prepare a report for the executive team along the lines of an “After Action” report used in the military. Summarize some of the findings from your review, including an analysis of the speed and effectiveness of the response. Don’t forget to include possible financial and legal implications that the extended team can provide.

Sample Questions

Here are some sample questions you may want to consider asking in your review. You may have more, but these are meant to help you get started as you work to improve your response to security incidents:

  • What type of incident was it?
  • How was the incident first detected?
  • Was the severity initially gauged?
  • How well did the response plan work? Any steps not followed? What steps helped? What steps didn’t help?
  • Was response leadership clear? Was it effective? Does anything need to change?
  • Any data or insights that could have helped?
  • Was communication among teams effective and timely? What worked well? What didn’t work well?
  • Any other teams that should have been included? At what stage?
  • What could be improved to handle the next incident?

Forewarned is Forearmed

Security breaches and incidents, or at least attempted breaches and incidents, are bound to occur given today’s threat landscape. But being forewarned is forearmed. Service teams—along with the rest of IT and the organization—can be better protected and prepared, with well-documented plans for a coordinated team that’s ready to respond to and mitigate the risks from future incidents.