Let’s face it, there’s no such thing as 100% Security.  

And any good risk assessment results in a certain level of accepted residual risk.  It is this residual risk that we respond to, either by transferring the risk, mitigating the risk, or accepting the risk.  And risk acceptance is a two-step process:  escalation and monitoring.

The monitoring of residual risk is a process that includes many different sub-processes, but the most important of these is a solid Incident Response Program. Infotex has been teaching Incident Response since 2000.  We’ve watched as banks and hospitals and clinics and now retailers and restaurants all learned the hard way.  You can turn a lemon into lemonade, or you can allow an incident to destroy your business.

The stakes are now very high.  For example, Target reported losses of $111 million dollars in the quarter following the quarter following their huge data breach.  Hospitals and healthcare organizations are not only losing reputation, but they’re also susceptible to HHS fines of up to $1.20 million per incident.

So what constitutes a good incident response program?  What key objectives should be met in any proactive incident response plan?  How do we convince the management team to become involved in proactive planning?

These are all great questions that we hear again and again.

We could go on forever with each answer.  The best way to answer these questions is to check out our Incident Response Program Kit, which includes a policy, procedure, detection standards, decision tree, incident response team training materials, standard committee agendas, and incident response test guidelines.

(And there’s a 30 day money-back guarantee.)

But if you don’t like that answer, here’s some basics:

1) An Incident Response Program must start with a very simple Incident Response Policy, approved by ownership (Board of Directors), and known by all members of executive management.  The policy should establish the following key objectives:

• Notice to owners:  there is no such thing as 100% security.  Even with all we’re doing and spending to protect ourselves, an incident could occur.
• Thus ownership requires management to create, maintain, and test an Incident Response Plan.
• Definition of an incident (and possible classifications of incidents.)
• Management should create a multidisciplinary Incident Response Team to not only be called during an incident, but also to proactively train for the most likely incident scenarios, review detection reporting, and maintain the plan.
• The Plan must address how and when ownership, management, employees, customers, law enforcement, and regulators are to be notified in the event of an incident.
• Ownership will be notified when customers are to be notified.
• Customer Notification should, when possible, comply with a stated Federal Regulation, in order to avoid (in most states) having to comply with state law, which rarely is customized to the industry that regulated companies are in.
• Assign responsibility and accountability for Incident Response to a specific job title (usually the Information Security Officer.)

2) The Incident Response Plan must accomplish many objectives, including:

• Create the Incident Response Team roster, and identify the chair of the team (usually the Information Security Officer.)
• Provide for the training of that team, and require periodic meetings (we recommend monthly, many organizations settle on quarterly.)
• Establish classifications for incidents, the authority to call an Emergency Incident Response Team Meeting, and escalation duties.  Incident classification should be kept as simple as possible.  For smaller organizations, we recommend a three-tiered method:  Notification, Security, and Minor.  The Information Security Officer classifies incidents, and classifications can change through the course of an incident investigation.
• Establish authorities and time frame requirements for incident investigations.  Priorities to be maintained in an incident (which are usually 1) Protect human life and safety.  2) Protect customer information and assure organizational data integrity.  3) Maintain the financial institution’s reputation and control external communication.  4) Prevent damage to systems, and 5) Minimize disruption of computing resources.
• Establish guidelines to govern the response process, which are usually containment, eradication, recovery and follow-up (in that order)
• Establish the goals of an incident response, including proactive, reactive, and proactive reactive goals.
• The plan should be tested periodically (and name the period, which is annually for most organizations)
• Documentation of incident scenarios that are highly likely (such as a DDoS attack in banking, or unauthorized shoulder surfing in healthcare.)  Other high likelihood scenarios include vendor breach, malware, web defacement, unauthorized but accidental data leakage (somebody sending an excel spreadsheet to the wrong person.)
• Require the development of various tools, including a Decision Tree for proactive planning, not to mention training for the Incident Response Team, other Incident Response Team Training collateral, intrusion detection standards

3) Test that program.  We can’t stress enough how important it is to test your Incident Response Process, from intrusion detection / suspicious activity reporting all the way through containment and eradication through recovery and follow-up.  If this is new for you, you will be amazed at how much you can learn from a good tabletop incident response test.  Like disaster recovery plans, incident response plans should be tested with proper documentation, including a test plan that is published in advance and that identifies the scenario to be test, documentation of the actual test, and a post-mortem review with summary and action items entered into the organization’s normal project planning/tracking systems.  Results of the tests should be escalated to ownership.

Now this is where we come in.  We’ve been in the Incident Response Business since 2000, when we started our business to provide Managed Security Services to healthcare and financial institutions.   If you really want to start off on the right foot, let us help you develop your program.  We can watch your network, help you create your policy, plan, and tools, train your Incident Response Team, and test your incident response plan with that team.