Six Questions To Help Build A Security Incident Plan

No IT security system is perfect, so if an incident happens in your workplace, you need to know the drill. In a recent research paper, Gartner analyst Rob McMillan identified six key questions that any kind of business security plan needs to address.

While the questions are designed for chief information security offices (CISOs), they are worth thinking about if your work involves you with IT security in any way. You might not be able to make much difference to the answers if you're further down the food chain, but knowing what the procedures and reporting lines are can make you much more useful when the crisis hits.

You can't plan for every eventuality, but McMillan points out that it's not enough simply to have basic backup plus procedures for issues you've actually had to deal with in the past:

Enterprises that do not have realistic and well-tested plans for managing all realistically foreseeable incidents are ill-equipped to contain the damage and control the outcome.

These are the six questions he advocates using to build and assess a plan:

1. Who cares about security policy and what do they expect? This list includes not just internal management and IT staff, but also your business partners (who will want to know when services will return to normal) and external regulators (who will want to be assured that sensitive data hasn't leaked or been corrupted).

2. What are the top priorities if an incident occurs? This varies a lot by industry. For an online shopping site, restoring service quickly is likely to be critical. In a government organisation, identifying the perpetrators might be rated as the major concern. In a medical system, ensuring everything is functional before recommencing treatment might top the list. Defining this in advance makes much more sense than panicked decisions after an incident occurs. The excerpted slider pictured shows one way of ranking these priorities.

3. Who is responsible for dealing with an incident? If there's a CSO or CISO, it's likely they'll lead any security response, but there'll also need to be a team of other workers with defined roles. Other C-level executives may want involvement, but their ability to actually resolve issues is likely to be minimal.

4. How can we define issues that actually matter? Not every potential security "incident" needs an in-depth response. Port scans are extremely common, for instance, and need to be mitigated against, but don't on their own represent a major issue. Having a clear scale of issues saves wasting time across the board.

5. Will the relevant people be able to do what's needed? In large hierarchical organisations, change takes time, but during a security incident, time is a luxury. Having definitions for exceptional circumstances under which responsible parties can execute decisions that would normally require higher levels of approval will ensure responses can happen fast enough if needed.

6. Has everything been documented? There might be a well-developed understanding amongst most staff on how to deal with security incidents, but that's not helpful if staff change or when contentious questions arise. Document everything. This is especially important where external service providers (whether outsourcers, cloud computing organisations or contractors) are involved.

Got your own security incident plan building tips? We'd love to hear them in the comments.

Evolve is a weekly column at Lifehacker looking at trends and technologies IT workers need to know about to stay employed and improve their careers.

WATCH MORE: Tech News

Comments

    Assuming you're talking about a security breach and not just probing from outside, the basic steps I follow:

    -Limit the breach. If you have to take your whole web presence down to make sure things don't get worse, do it.
    -Identify the cause and extent of the breach.
    -Patch the security hole on all clean servers, and take them back online.
    -Finish up your forensics.
    -Wipe and rebuild all compromised systems before you put them back into service.
    Be very careful restoring from backups.

    You should also add 'Notify anybody affected as to the extent of the breach at the earliest reasonable opportunity' in there if it applies.

Join the discussion!