Security Engineering: The Next Generation of Business Continuity Planning
By James G. Barr

Business continuity is a business management discipline that provides for the continuous operation-or rapid recovery-of a firm's critical business functions in the event of a disaster or other major disruption. Business continuity, like business itself, is dynamic, changing (or, perhaps more appropriately, evolving) according to economic conditions. To date, the evolution of business continuity has occurred in three distinct phases:
Phase 1: Disaster Recovery - Emphasizing the recovery of mainframe applications and data, beginning in the late 1970s;
Phase 2: Business Recovery - Emphasizing the recovery of IT and non-IT business functions, beginning roughly in the mid '80s; and
Phase 3: Business Continuity - Emphasizing disaster prevention and uninterrupted operations, beginning in the early '90s.

Table 1: The Evolution of Business Continuity Planning

While the science (or, perhaps more accurately, the art) of business continuity has progressed rapidly over the past thirty years, there are several large-and lingering-issues that must be addressed.

Issue 1: The IT Legacy

Born to recover computer systems, and largely presided over by IT staff, business continuity is still primarily focused on information technology. Non-IT risks, such as the destruction of manufacturing facilities, the loss of key personnel, and the adverse effects of globalization, are ignored. Strip away the "business" facade and, for many firms, business continuity is still old-fashioned disaster recovery.

Issue 2: The Lack of Business Management Integration

While business continuity often borrows on related disciplines, such as enterprise security and crisis management, the relationship is usually temporary, and often informal. (Not surprisingly, this same isolation is often manifested in matters of enterprise security, where physical security is handled separate and apart from information security.)

The lack of integration produces a curious result. Certain risks, such as the destruction of a data center, become business continuity risks, while other risks, such as the disclosure of confidential online data, become enterprise security risks.

The general effect is that business continuity risks receive less attention in terms of prevention (the primary goal of enterprise security), while enterprise security risks receive less attention in terms of recovery (the primary goal of business continuity).

Clearly, an integrated approach to risk management, combining both business continuity and enterprise security, would afford greater protection.

Issue 3: Questionable Return on Investment

Business continuity has often been likened to life insurance: You only get paid when you die. While it's important to safeguard a firm against disasters or other business-ending events, this apocalyptic approach to business continuity produces several unintended consequences:
Small-to-medium-sized enterprises (SMEs) are unengaged;
Business continuity protocols are not applied to operational problems, such as the protection of personally identifiable information (PII); and
Business continuity is not "built into" new products, and new processes.

The Next Generation of Business Continuity Planning

One obvious prescription for improving business continuity planning is to integrate business continuity and enterprise security to provide complete and holistic risk management solutions.

This new discipline, we'll call it Security Engineering, would operate to:
Minimize risk potential (through enterprise security); and
Mitigate risk effects (through business continuity).

Security engineering would also incorporate elements of related disciplines, including:
Business Reengineering;
Crisis Management;
Emergency Management; and
Quality Management.

To help understand the distinction between security engineering and conventional business continuity and enterprise security, consider the following examples:

Table 2 concerns the Disclosure of Confidential Online Data, normally an issue for enterprise security. The first column describes a standard response, driven by enterprise security. The second column describes a potential security engineering approach, combining elements of both enterprise security and business continuity.

Table 2: Risk of Disclosure of Confidential Online Data

Table 3 concerns the Destruction of a Data Center, normally an issue for business continuity. The first column describes a standard response, driven by business continuity. The second column describes a potential security engineering approach, combining elements of both.

Table 3: Risk of Destruction of a Data Center

Traditional Business Continuity Response	Security Engineering Approach
Implement Business Continuity Establish a computer "hot site." Prioritize critical applications. Store data backups in a secure offsite location. Develop a comprehensive business continuity plan.	Implement Business Continuity and Enterprise Security Establish a computer "hot site." Prioritize critical applications. Store data backups in a secure offsite location. Develop a comprehensive business continuity plan. Install fire detection and suppression equipment.

Security Engineering Challenges

Like most new developments, security engineering faces a number of challenges.

Challenge 1: Limited Support for Expanded Business Continuity Services

While the concept of security engineering may seem controversial, advocates can point to the prestigious Business Continuity Institute (BCI), which supports a similar initiative called "Business Continuity Management" (BCM). Termed "the unifying process," BCM is a model framework that encompasses ten (10) business management disciplines, everything from disaster recovery to knowledge management.

Table 4: BCI's BCM

Challenge 2: Possible Jurisdictional Disputes

The process of unifying business continuity and enterprise security would require the cooperation of numerous individuals, including the:
Business continuity officer (BCO);
Chief security officer (CSO);
Chief privacy officer (CPO);
Chief information officer (CIO); and, of course, the
Chief executive officer (CEO).

In addition, the process would require a realignment of responsibilities and, potentially, personnel.

Challenge 3: Initial Integration Expenses

In addition to organizational adjustments, the establishment of a security engineering function would require expenditures for:
Development of security engineering protocols and procedures;
Security engineering training and education; and
Evaluations of security engineering efficiency and effectiveness (i.e., security engineering ROI).

Opportunities

For the business continuity professional, security engineering offers the chance to make relevant contributions on a daily basis. Here are just a few of the new initiatives that security engineers-formerly business continuity planners-might pursue.

Table 5: Potential Security Engineering Initiatives

Initiative	Sample Security Engineering Actions
Secure Personal Digital Assistants (PDAs) from Theft and Abuse	Restrict PDA access to individuals with legitimate business needs. Establish standard PDA models to facilitate security and technical support. Provide a means of encrypting all confidential PDA data. Train PDA owners to protect their devices against loss or theft. Develop a procedure for reporting lost or stolen PDAs. Create a team to evaluate the impact of any compromised PDA. Codify PDA ownership responsibilities with a corporate policy, including sanctions for intentional violations.
Safeguard the Organization from Biological, Chemical, Nuclear, or Radiological Attacks	Develop Evacuation Plan. Develop "Shelter In-Place" Plan. Conduct regular Evacuation and Shelter In-Place Drills. Establish liaison with local emergency management officials. Procure and deploy weapons of mass destruction (WMD) detectors, especially radiation detection devices. Develop salvage priorities and protocols. Identify temporary alternate workspaces.
Audit Business Partner Enterprise Security and Business Continuity Plans	Identify business-critical business partners (BPs). Request production of BP enterprise security and business continuity plans. Evaluate BP plans, noting any essential deficiencies. Encourage BP officials to correct such deficiencies. Identify alternative BPs if present provider plans remain inadequate. Insert a clause in standard business partner contracts and service level agreements requiring prospective business partners to maintain-and surrender for inspection-evidence of comprehensive security and business continuity plans.

Why "Security Engineering?"

Okay, the basic idea is to integrate business continuity with enterprise security, providing a form of "cradle to grave and beyond" protection for critical business functions and vital enterprise assets. Why call the union of these two disciplines "Security Engineering?" Why not call it "Continuity Engineering" or some other formulation?

The answer is marketing. As even its most diehard advocates will confess, "business continuity" is a tough sell, whereas the term "security" resonates with virtually everyone. As Machiavelli might attest, "bringing about a new order of things" is tough enough, without weighing down the concept with legitimate-but self-limiting terms-like "business continuity" or "disaster recovery."

Conclusion

Security Engineering is the next logical step in the evolution of business continuity planning, combining the recovery elements of business continuity with the prevention elements of enterprise security. For business continuity planners, security engineering offers the opportunity to apply business continuity protocols to everyday business operations-and business problems. The planners benefit-and so do their organizations.

About the Author

Jim Barr is a leading business continuity analyst and author. A member of "Who's Who in Finance and Industry," Jim is also the managing editor of Faulkner Information Services' "Security Management Practices," an online security journal. Jim can be reached at jgbarr@msn.com.