TODAY’S DISASTER RECOVERY — A Holistic Approach to Remediation
By Joe Oleksak & Steve Odegaard
Security Assurance
Universal Advisor , 2005 Issue No. 1

Like many medicines, Disaster Recovery Planning (DRP) corrects the symptoms of a disaster rather than the source. For example: fire breaks out and partially destroys\ your building and data center. A quick dose of business continuity, hot-site management, conversations with insurance agents, and your organization is back on its feet. For these “traditional disasters,” this is often the most efficient and cost-effective approach to recovery. However, with the introduction of “non-traditional disasters,” such as the compromise of internal and external systems, the unauthorized access of personal and business data, and malicious code compromises such as the SQL Slammer, Blaster, and Love Letter worms, this traditional remedy may only be short term, with adverse long-term effects.

These “non-traditional disasters” (commonly referred to as incidents) often leave systems and data infected with malicious code, root kits, and back doors, which, if left undiagnosed, could lead to further corruption of your operating environment, systems, and data. When incidents cause immediate symptoms, the diagnosis is relatively simple, and traditional disaster recovery efforts will inoculate the source. But what happens when an undiagnosed source, such as a Denial of Service (DOS), shuts your systems down? Disaster recovery efforts successfully bring your systems back up, only to find a week later that the systems have gone down again. Moreover, what happens if a hacker or unknown virus successfully controls, edits, or manipulates devices and data within your network for an unspecified period of time? How would you identify this source? How quickly could you recover? Could you recover?

Are You Prepared?

What can your organization do to prepare for such a disaster? Employ a holistic approach to traditional disaster recovery by implementing or formalizing your existing Incident Response Plan (IRP). Simply put, a formalized IRP will better prepare you to identify and respond quickly and effectively to an incident — ergo, the better chance you’ll have to minimize any damage caused by the incident.

When developing or formalizing an IRP, consider how your organization will perform the following functions:

• Identify/detect/analyze an incident
• Contain or eradicate a problem and prevent reinfection/recurrence
• Log events
• Educate users to raise security awareness and promote security policies
• Build a centralized incident reporting system
• Establish escalation procedures that lay out actions the company should take if an attack turns out to be protracted or especially damaging
• Update service-level agreements to include provisions for security compliance, and spell out reporting requirements and maintenance of systems (including contingency plans) in the event of an incident
• Decide in advance what circumstances merit calling the authorities
• Plan how and when employees, customers, and strategic partners will be informed of the problem
• Establish communication procedures should this become a media event

The IRP and DRP have distinct roles in remediation. Consequently, each should remain separate solutions; however, they should contain hooks into each other to ensure that both traditional and non-traditional disasters are addressed properly.

Who Should Be Involved?

An IRP should designate a contact to whom employees should report suspicious events and who’ll track changes in procedures, as well as a contact who’ll report incidents to outside agencies, including law enforcement, regulatory bodies, and information-sharing organizations (such as InfraGard, ISACs, etc.). It should also contain a list of the incident response team members’ names, titles, and 24/7 contact information, along with their role in a security breach. Remember — much like traditional disaster recovery, your IRP should have a designated team responsible for remediation. Incident Response Planning is not just an IT department responsibility; an effective IRP team should include representation from:

• Executive management
• Each critical business area
• The Disaster Recovery team
• IT Administration
• IT Security group

Further, your IRP should include items such as:

• Contact information for vendors contracted to help during a security emergency, as well as Internet Service Providers (ISPs) and other relevant technology providers
• Contact information for major customers and clients who might be affected
• Contacts at the relevant law enforcement agencies (such as the computer intrusion squad at the local FBI or the crimes investigator at your local police)

Too Much Effort?

It sounds like a lot of effort with little return, but consider this: The 2004 E-Crime Watch survey conducted among security and law enforcement executives by CSO magazine (in cooperation with the United States Secret Service and the Carnegie Mellon University Software Engineering Institute’s CERT® Coordination Center) showed a significant number of organizations reporting an increase in network, system, or data intrusions. Forty-three percent of respondents reported an increase in intrusions versus the prior year, while 70 percent reported at least one intrusion during 2004. In other words, unauthorized attempts are being made to connect to your systems and corrupt your networks and data while you read this article. How sure are you that these attempts are being identified and dealt with properly?

In Conclusion

“Non-traditional disasters” can be as catastrophic as a tornado and, therefore, must be treated as disasters. Think your informal response procedures will suffice? Informal IRP procedures are no longer accepted as a viable solution to incident response. Federal regulation (GLBA, HIPAA, Sarbanes-Oxley, etc.), Security Industry Standards (COBIT, COSO, ISO17799), Industry Regulators (FFIEC, FDIC, OCC, etc.), and some state laws (California Privacy Law SB 1386, for example) all require the implementation of a formalized IRP. Knowing all of this, how can you afford not to formalize your IRP?

Don’t have the time or in-house expertise to develop and implement an IRP? Help is out there in different forms! The following is a small listing of resources to help your organization better prepare for incidents.

NIST — Computer Security Incident Handling Guide Recommendations of the National Institute of Standards and Technology (http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf)

CERT Coordination Center — Computer Emergency Response Team, Carnegie Mellon University (http://www.cert.org)

DOD-CERT — U.S. Department of Defense Computer Emergency Response Team (http://www.cert.mil)

FedCIRC — Federal Computer Incident Response Center (http://www.fedcirc.gov)

FIRST — Forum of Incident Response and Security Teams (http://www.first.org)

IAIP — Incident Report Form (http://www.nipc.gov/incident/cirr.htm)

InfraGard — Information sharing between private industry and the FBI (http://www.infragard.net)

SANS Institute — Incident response, intrusion detection, computer forensics (http://www.sans.org)