Proposal Paper

CyberSter

Information_Security_Fundamentals_----_Chapter_8_Continuity_of_Operations_Planning.pdf

Home >Computer Science homework help >Proposal Paper

153

Chapter 8

Continuity of Operations Planning

Jeffery Sauntry

Contents Introduction ......................................................................................................171 Background .......................................................................................................171 Patience, Persistence, and Overcoming Organizational Resistance .....................172 Purpose and Scoping of CoOP .......................................................................... 174 Example of a Purpose Description (IT and Web-Centric CoOP) ......................175 Conducting Business Impact Analysis and Creating Workflow Diagrams ..........177 Documenting a Functional Overview of the Current Environment ...................180

High-Level Narrative ....................................................................................180 Example of High-Level Narrative and Supporting Diagram .....................181

Organizational Chart ....................................................................................182 Compliance Obligations ...............................................................................182

Example of the Compliance Section Building on the Previous Examples .....184 Summary of Critical Services and Essential Functions ...................................184

Example of the Critical Services and Essential Functions Section .............185 Contingency Operations ...............................................................................186 Incident Response Process Overview .............................................................186 Detected Events and Declared Incidents .......................................................187 Event Detection and Documentation ...........................................................189

Events Analysis and Triage ........................................................................190

Peltier, Thomas R.. Information Security Fundamentals, Auerbach Publishers, Incorporated, 2013. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=1375200. Created from apus on 2025-04-18 03:10:43.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

154 ◾ Information Security Fundamentals

Americans can always be counted on to do the right thing…after they have exhausted all other possibilities.

—Sir Winston Leonard Spencer Churchill (November 30, 1874–January 24, 1965)

British politician and statesman known for his leadership of the United Kingdom during World War II and the first

person granted honorary citizenship of the United States

Declaring Incidents ....................................................................................... 191 Incident Declaration Criteria ........................................................................ 191 Analysis of an Event Resulting in a Declared Incident ...................................192 Organizational Response to a Declared Incident ...........................................193 Communicating Incidents ............................................................................194 Declared Incident Closures ...........................................................................195 Postincident Review and Reporting ..............................................................195 Plan Management and Updates ....................................................................196

Practical Application of the CERT and NIST Guidelines ..................................197 Event Risk Categorization and Impact Guidelines .......................................... ...198 Event Category and Response............................................................................202 Response Team—Roles and Responsibilities ......................................................204 Alternate Facility Operations—Hot Site ......................................................... ..206 Alternate Facility Operations—Cold Site ..........................................................210 Reconstitution to Primary Facility .....................................................................210 Postincident Review and Response Evaluation ...................................................210

Incident Review Report Template Topics ...................................................... 211 Incident Management Performance Metrics ..................................................213 CoOP Review Exercises and Testing Procedures ............................................214

Employee and Partner Training and Test Procedures ..........................................214 CIRT Team Member Orientation .................................................................214 CIRT Team Tabletop Exercises ..................................................................... 215 Testing Scenarios .......................................................................................... 215 Functional Exercise ....................................................................................... 215

Plan Reviews .....................................................................................................216 Plan Holders .................................................................................................216 Training/Exercises .........................................................................................216 Common Appendixes and Supporting Documents .......................................217

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 155

Introduction Continuity of operations planning (CoOP) is an important core capability that every business needs, but few even attempt to do well, much less write down, implement, or actually test under real-world scenarios. Many organizations have never seriously considered the topic because it could be too complex, might cost some money, might not help them hit this quarter’s revenue target, and with a similar scorn they have for most forms of insurance, they may never even need it. For some reason, as Sir Winston Churchill suggests, most organizations will try almost everything else before actually putting a viable, complete, fully imple- mented, and tested CoOP in place. Government and industry regulations are major drivers that have forced some organizations to begin tackling the topic by requiring the establishment, testing, and proof of ongoing maintenance to demonstrate compliance or lose certain industry certifications. There are still too many corporations, government agencies, and small businesses that could real- ize tremendous benefits by implementing even limited continuity of operations plans. CoOP may not always be lead by information technology (IT) security professionals, but a thorough understanding of the topic, how security require- ments can be integrated into the plans, and mastering the industry’s best practices associated with creating a CoOP strategy should be a core competency of every member of a security organization.

Background As a security professional, you may be asked to lead or participate in the CoOP process. A key consideration for most CoOPs is the requirement that the safe- guards and standards of confidentiality, integrity, and availability be maintained even when operating during a disaster. It seems a very logical requirement, but one that becomes increasingly difficult to achieve when an organization has to relocate key processes to another facility. Factors such as having multiple tenants (e.g., some of your fiercest competitors could be co-located in the same recovery facility) and “easy everyday” tasks are hobbled by the lack of supporting infrastructure and poor planning that is all too common during a disaster. According to Abraham Maslow’s hierarchy of human needs, tier one needs are water, air, food, and sleep, closely fol- lowed by the second tier of “security needs,” which includes steady employment, good health, and shelter from the environment. There is a reason that food, water, and sanitation are part of the first supplies shipped in by first-responders after a nat- ural disaster and not computer cables and pallets of high-capacity storage devices. Consider how hard it would be to secure simple items to recover your operating environment if you didn’t have the tier one items available, much less the items you would need to recover your daily operations (e.g., electrical power, media, and backup copies of data files) if you didn’t start to think about them until after a

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

156 ◾ Information Security Fundamentals

natural disaster had occurred? The upside is that the process is straightforward and huge strides can be made to make your organization more resilient with even mod- est efforts to plan for outages and disruptions before they happen.

There are some emerging business trends that make continuity of operations much more practical than ever before. The globalization of many organizations can be leveraged by spreading business capabilities across multiple, geographically dispersed locations to minimize the effect of losing access to a single facility in an area affected by a local event. Telecommuting and other unified communication trends can be harnessed to leverage a broad pool of personnel that can remain in constant communication with one another even if the organization’s infrastructure is damaged or rendered inoperable by utilizing secure communication channels across public networks that may still be available during a disaster. Finally, virtual- ization can have a dramatic impact on the speed of recovery if properly leveraged. It will redefine how decades of IT security professionals have defined a “standby site” that can very literally be enabled with a few simple procedures versus large-scale logistical efforts that involve hours or days of acquiring and assembling hardware followed by man-days of installing operating systems, applications, and applying patches before even the first attempt could be made to restore data that may have been stored hours away in a separate physical facility. Virtualization, cloud comput- ing, and robust telecommunication provide new capabilities as part of CoOP that can assist organizations in achieving the security, availability, and confidentiality requirements of the new “always on” business model with limited or no interrup- tion even during disruptive events.

Patience, Persistence, and Overcoming Organizational Resistance There are good reasons to have a well-rehearsed and complete CoOP. Unfortunately, there seems to be a never-ending list of excuses that most organizations turn to in order to explain why they can’t master a program that can literally be the difference between keeping the doors open after a disaster or closing down operations forever. Understanding and anticipating the obstacles and objections will be critical to get- ting your organization’s program off the ground. The excuses take many forms and stem from long-standing personal, organizational, and institutional mind-sets. Senior managers to rank-and-file staff members will protest from participating and procrastinate when asked to contribute because a disaster hasn’t affected them before in their long and illustrious career. Despite the common adage that “hope is not a strategy,” these fine coworkers (aka ostriches with their heads in the sand) are content to gamble that it won’t happen “on their watch.” Besides, like most political kamikazes in any organization, by the mere act of proactively asking them about the topic or soliciting their participation in the planning process, it is clear that the big red bull’s-eye has obviously been placed on your back by someone in authority.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 157

If a plan is needed, obviously, you will be the de facto scapegoat if it doesn’t work. You might want to remind them of some of the statistics found later in this chapter and in Chapter 7 of this book, which they can ponder on in the unemployment orientation meeting surrounded by an ocean of their peers with similar skill sets who will soon be competing with them for jobs in a small geographic area they call home, which will probably soon be reeling from the economic devastation that is common after major disasters. Ironically, the organizations that did have a good CoOP in place may be the only ones still hiring because they have achieved the ultimate goal of any good CoOP or business continuity planning (BCP)—they are still in business.

Consider as well how to best overcome resistance and skepticism generated as part of the organization’s corporate culture or individual personal agendas. Many employees and departments tie a close association between the limited knowledge of their internal operations and the value they bring to the organization. Right or wrong, many employees feel their job security may be threatened if someone other than themselves knows exactly how a business process works because every- one knows “the show can’t go on without the star; coal stoker in the boiler room keeps the fires burning; it’s the locomotive that pulls the rest of the train, etc.” Simply explain that the senior management team has recognized that their role and function is so important it has been selected to participate in this important program, so that in the unfortunate event that a tragedy does happen, “the show” will go on. For even the most resistant participant, this approach normally works, especially when they consider the alternative of not being included in a program that is attempting to identify the core capabilities needed to keep the organiza- tion afloat. If it still doesn’t work, look for another employee with similar knowl- edge or go back to your executive sponsor to discuss alternative “motivational techniques.”

Uncooperative individuals will not be your only challenge in the early stages of developing the CoOP. Considerable amounts of the institutional knowledge you need to build out the plan may exist but may not be in a very useful or reusable format. With the exception of some government agencies or U.S. Department of Defense contractors, consider how much effort and organizational discipline it takes to document and capture the daily workflows that are required to keep an organiza- tion running smoothly. Many employees may know how to do their job or a specific task, but rarely will it be captured in a usable format that you can leverage to under- stand the key aspects of a business process, the risk associated with specific elements much less support any cause and effect analysis a disaster may have on it. The upside is that if a picture is worth a thousand words, a good Visio or Unified Modeling Language (UML) diagram will seem invaluable at this point if you are willing to invest the time to extract and capture this very important knowledge. Leverage the power of visual references to facilitate the conversation, map key dependencies, and talk about risk and threats to the business process with key stakeholders early in the planning phases. Not only will you gain credibility and cooperation with someone

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

158 ◾ Information Security Fundamentals

you may call on later to help support your protection recommendations, but these diagrams will also be very valuable to you later when you need to establish other key CoOP artifacts such as use cases, testing scenarios, risk/probability ratings for specific threats, etc. Patience, persistence, strong written and verbal communica- tion skills, and documenting complex tasks to a fine level of detail will require core competencies that you must demonstrate throughout the entire process. This time and effort investment will pay huge dividends to you professionally well beyond the scope of the CoOP project. Your value to the organization will increase dramati- cally as you demonstrate to senior management your new, deeper understanding of how the business works, which will provide you valuable insight on how to best protect it. It is this knowledge and application of your technical expertise that will have the greatest effect on your career.

Critical Success Factor—As you begin to develop the plan and solicit input from other staff members, set a good example by stressing the importance of maintaining the confidentiality of the plan. Assuring people that their input and the detailed knowledge of business operations will be properly safeguarded throughout the life cycle of the program will promote a degree of trust between parties and should improve collaboration efforts. Properly mark the CoOP and supporting documents with an appropriate data classification and corresponding limited distribution dis- claimers. Once the plan is complete, it should only be shared with employees or partners on a need to know basis, which is bound by current and binding nondis- closure agreements (NDA).

Purpose and Scoping of CoOP Determining and being able to articulate the purpose of the program is the first step of the planning process. Given the level of effort, staff involvement, and pos- sible expense associated with developing the program, it is typically sponsored by a senior member of the management team or the business owner. It is important to understand what and whom they expect to be included in the planning process. In many cases, it is useful to gain insight into the motivation and timing associated with implementing the CoOP program. There could be a particular risk that they feel is threatening the business, a requirement related to a contractual or regulatory requirement, or it has become necessary to support a strategic growth initiative (e.g., mergers and acquisitions, raising capital, divestitures).

Expect that the initial scope of the plan will typically be described in broad or abstract terms (e.g., patient electronic medical record or e-Commerce site) or general business functions/processes [e.g., accounts receivable, build-to-buy pro- cess, enterprise resource planning (ERP) system, or new customer acquisition]. At this point, don’t worry about all the components in the supporting technical infrastructure, but try to verify if there are any specific risks or threats they are

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 159

particularly concerned about so you can incorporate them into your final plan for discussion with the other members of the team. Attempt to identify if there are any targeted windows for recovery or tolerable outage periods that should be incorporated into the plans’ objectives. It is very important to be able to capture and articulate the scope, goals, and objectives when you are discussing it with others. By properly framing the conversation and including or excluding certain business processes, you will be able to focus your plan development efforts more effectively. Don’t try to boil the ocean and take on too much (e.g., 100 business processes, 10 facilities, the entire IT infrastructure) on the initial version of your plan. You want the plan to be ambitious and complete, but it can quickly die under its own weight and complexity if not properly limited in size and scope. Once you have the plan completely implemented for a few business processes, it is easy to expand and adapt to others.

Critical Success Factor—The visibility of executive management support dur- ing the planning process will often mean the difference between your success or failure. Suggest to your executive sponsor that you craft some e-mail message con- tent summarizing the program, objectives that clearly set the expectation that key stakeholders’ active participation is expected in the coming weeks. Ask that your sponsor send the message to each of the critical team members that are expected to participate in the CoOP process to jumpstart the program, establish it as a high- priority project with senior executive visibility, and it will get you off on the right foot with the other members of the team.

Example of a Purpose Description (IT and Web-Centric CoOP) This disaster recovery (DR)/CoOP provides the required instructions to support contingency operations for disruptions to the <business function(s)> of <company XYZ’s> <geographic location> operations. This plan addresses events and declared incidents that could disrupt the network, communications, and ability to generate revenue through critical online assets and retail store operations across the organi- zation. It contains operational procedures to address limited service interruptions, <business function(s)> outages, and situations that could threaten the security of the communication and application infrastructure.

<Company XYZ> is prepared to respond to a wide range of events, emergen- cies or threats that may disrupt operations. Emergencies are any unplanned events that can potentially cause death or significant injuries to employees, customers, or the public; that can shut down an organization, disrupt operations, cause physical or environmental damage, or harm the organization’s public image. Government- declared emergencies run the gamut from fire, hazmat incidents, weather-related incidents, terrorist activity, cosmic/radiological incidents, civil disturbances,

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

160 ◾ Information Security Fundamentals

or human illness pathogens and often limit employees’ physical access to the <Company XYZ’s> <geographic location> operations or facilities. IT or cyber- related threats to the <Company XYZ’s> production environment can affect the confidentiality, availability, or integrity of the Internet-facing assets that are used to generate revenue for the organization. Technology-centric threats range from malicious code, hacking, intellectual property theft, and phishing attacks that can result in data loss or compromise adherence to industry and government compli- ance regulations.

<Company XYZ’s> CoOP is designed to optimize the response of the organi- zation by quickly identifying and responding to any of these threats quickly and methodically. The response capabilities of the organization have been developed to provide a robust operational capability that is not dependent on a single facility or in the case of the supporting IT infrastructure, a single critical device or point of failure. The probability (likelihood that an incident will occur), frequency (how often an incident occurs), and the severity (effect of an incident) are factors that weigh heavily into the DR/CoOP process. Those events that could disrupt opera- tions are evaluated based on criticality and probability.

The (Executive or Committee) has identified the assets supporting the revenue- generating, new customer subscription and bill-paying capabilities as critical busi- ness services requiring a dedicated DR/CoOP. The main purpose is to ensure that <Company XYZ> is able to communicate and operate both during normal opera- tion and during a state of emergency with customers, subscription services, credit card processing partners, and employees.

Because the <Company XYZ’s> web presence is reliant on a combination of company-owned assets and leased services, this document sets forth the require- ments to maintain the continuity of the network, revenue-supporting applications, and associated mission-critical IT services necessary to keep the organization eco- nomically viable during disruptive events.

Specific DR/CoOP objectives and recovery goals:

1. To provide for the protection of lives, property, network and information assets supporting the <Company XYZ’s> Internet-facing sites, and support- ing infrastructure from outages caused by natural and man-made disasters or digitally enabled (cyber) threats.

2. To enable orderly and timely migration from primary to secondary data cen- ter resources as necessary to support revenue-generating portions of the orga- nization within a 4-hour response window.

3. To provide for quick continuation of essential network functions supporting the <Company XYZ’s> web site under emergency conditions in a disciplined response to the aftermath of a disaster.

4. To provide procedures and provisions for the utilization of alternate facilities as needed to continue essential support functions.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 161

5. To provide procedures to be followed in preparation for or in response to the aftermath of an emergency.

6. To return the <Company XYZ’s> web presence or support to normal opera- tions as quickly as possible after an emergency or declared event.

Conducting Business Impact Analysis and Creating Workflow Diagrams There are a wide range of techniques you can utilize to conduct a business impact analysis (BIA). Most follow a basic format to evaluate a wide range of threats against assets or processed deemed “in scope” for the CoOP. Most will require an evalua- tion of the adverse effect expressed as either a qualitative (e.g., educated guess) or quantitative (e.g., numerical value or financial effect) value. As mentioned in the previous example, purpose description, keeping the categories, and threat vectors generic is sufficient for most planning purposes, but not for each organization or some compliance requirements.

Adapting the BIA to meet the needs of the organization, audience, and regula- tors should dictate which type of BIA you conduct. If the organization’s decisions relies on hard and accurate cost figures, then using a technique that utilizes specific threats against a discrete number of critical business assets that relies on historical occurrences or threats with a high probability that can express the results of dam- age or negative effects in terms or lost revenue or recovery cost may be the best approach. Many organizations may not have the level of granular cost detail to make these computations possible. If that is the case, then establish this fact early with the executive sponsor, or use a BIA technique that will provide an appropri- ate level of detail to support planning purposes and any associated expenditures to protect critical assets. In other instances, there could be very specific requirements associated with how a BIA needs to be structured to meet regulatory or business requirements. For example, in businesses that utilize credit cards, there are specific standards and practices that must be adhered to as part of Payment Card Industry– Data Security Standard (PCI-DSS), which lists specific threats and protection tech- niques that are required to achieve certain levels of compliance that are required if a business wants to continue accepting credit cards for purchase payments.

Certain departments will help identify the risks and circumstances that need to be addressed under specific conditions that may need to be considered as part of your planning. Legal departments may need the CoOP to address circumstances such as “litigation hold” or record retention requirements that have to be main- tained even when an emergency has been declared and data processing has been moved to an alternate facility. Many business models, especially in service indus- tries, rely on a complex set of third-party service providers and the availability

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

162 ◾ Information Security Fundamentals

of these processes needs to be considered as an integral component of your plan. Business partners that provide critical services such as off-site storage of backup media, web hosting and content delivery providers, telecommunication, utility, property management, and credit card processing companies, or supplier/partners/ distributors with ERP systems integrated into your companies’ daily operations will need to be taken into consideration when assessing the “impact” of some risk factors as part of your BIA. The bottom line is that there is probably a best way to conduct a BIA for your organization, but make sure you adapt your approach to produce useful artifacts that will be readily accepted by the senior management and other members of the CoOP team.

The ITIL framework has a very good baseline processes for conducting a BIA as part of IT Service Continuity Management or via a risk management approach using the techniques found in the Management of Risk (MOR) series of publi- cations. Make a quick search of the publicly available templates via government- sponsored sites as well those that include publications by NIST (e.g., 800 series), Software Engineering Institute’s CERT program, state and local government sites or many universities’ sites, which have great templates that you can quickly adapt to your organization’s needs.

Another common challenge associated with developing a credible BIA is iden- tifying sources of current threats, trends, and associated costs with losses or data breaches. Keeping the content simple and relevant is crucial when tapping into industry reports. Start with simple threat criteria such as geographic location, industry-specific data, and then establish broad categories to compartmentalize the information you find that may be relevant to your organization or specific threats. Categories such as physical, IT/cyber, regulatory, and business process threats are a good starting place when gathering data about threats.

There isn’t a definitive, single place wherein everything is neatly packaged to fit in these categories. Use these suggestions as representative examples in addition to trade associations, professional certification groups, and government web sites to start building your CoOP content.

For a listing of natural disasters (in the United States) that could result in the loss of physical assets or entire facilities, start with this site populated by agencies such as FEMA for the areas in which your organization operates (http://www.fema. gov/news/disasters.fema).

Some state, county, or local governments provide even more detailed informa- tion that may be useful for your planning purposes. Many will be affiliated with professional associations such as the State Emergency Response Team (SERT) or regional associations. A good example is the Florida Business Disaster Survival Kit, sponsored by the Tampa Bay Regional Planning Council (http://www.fldisasterkit. com/index.shtml).

IT and cyber threat sources are a broad topic that has many sources that could be updated almost daily. Broad categories and annual trends that are expressed in layman’s terms will be most useful for planning purposes. Avoid being too

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 163

technical, there are more appropriate places in the CoOP for items such as archi- tecture diagrams and OSI threat models, which we will explore later in the chapter. Some of the most respected annual reports related to IT and cyber threats and fraud-related crimes include

◾ Computer Security Institute/FBI “Annual Crime and Security Survey” (www. gocsi.com)

◾ Ponemon Institute “20xx Annual Study: Cost of Data Breach” (www.ponemon.org) ◾ Verizon Business “20xx Data Breach Investigation Report” (www.verizonbusiness.

com/resources/reports) ◾ Certified Fraud Examiner “20xx Report to the Nations on Occupational Fraud

and Abuse” (http://www.acfe.com)

An example of industry-specific publications that cover industry trends and reg- ulatory compliance–related issues include examples from the information Security Media Group (iSMG) targeting banking, Government, and health care verticals (http://www.ismgcorp.com/research.php).

Many other examples exist from groups such as analysts, vendors, and trade associations, but remember to bring an objective and skeptical mind-set depending on the source and sponsors of any third-party publication.

For the category of business threats, consider the external third parties that your organization relies on for critical services or for products to support key busi- ness functions. Also, consider the risks that could be introduced by the connec- tions to either suppliers or, in many cases, your customers into your computing environment or supply chain. There is no universal template or single web site for finding info on these threat vectors, but for each third party service, consider sce- narios that could affect the confidentiality, integrity, or availability of your organi- zation. It can be helpful to consider a simple supply chain workflow that describes how goods, information, or services are produced, stored, packaged, sold, paid for, and ultimately, delivered in order to get started. Ask someone in the respective department about their workflow or business models, which includes third-party services, and you’re likely to hear phrases like “cash to order” from the accounting team or “build to buy” or “source to sell” from someone familiar with internal operations who understands the inner workflow of the organization’s ERP system. Carefully document these business processes, looking for opportunities to identify supporting processes, IT infrastructure connections, and application dependencies to external third parties.

Consider the workflow and interdependencies of the following business func- tions required to enable a basic business to consumer (BtoC, or B2C) e-Commerce site. High-level business functions such as marketing, sales, production of the elec- tronic content or physical goods, inventory management and distribution, and pay- ment may be as simple as a single web server hosted in a single facility. More likely, it crosses multiple facilities, employees, departments, and partners to run efficiently.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

164 ◾ Information Security Fundamentals

Consider the following departments and business functions to get your workflows diagrams started. Not each will be represented in every model or workflow, but it will serve as a broad topic list to consider when meeting with key stakehold- ers. Common business functions and departments include: Accounting, Accounts Payable, Advertisers, Accounts Receivable, Bank Credit Card Processing, Board of Directors, Business Partners, Content Providers, Copy and Marketing Materials Center, Customers, Customer Service, Design, End Users, Engineering, Executive Management Team, Facilities, Hosting and Managed Service Providers, Human Resources, Information Services (e.g., Database, Network Infrastructure, Security, Change Control, Help desk), International Divisions, Inventory, Legal Depart- ment, Mail Service, Manufacturing, Marketing, Motor Pool/Transportation, Packaging, Payroll, Publications, Purchasing, Quality Assurance, Receiving, Reception, Research and Development, Sales, Physical Security, Shipping, Suppli- ers, Telecomm, Utilities, and Warehousing.

Critical Success Factor—Always send a copy of your completed diagrams or workflows back to the original source of the information for verification of accuracy and completeness. They will appreciate the follow-up and often provide feedback or updates based on knowledge only they could provide about missing items or inter- dependencies you may not have been privy to as an external observer.

Documenting a Functional Overview of the Current Environment High-Level Narrative As the early stages of a CoOP come together, a high-level narrative that describes the business processes, critical services, or departmental priorities should be com- pleted. Too often, a CoOP team builds on legacy documentation that relies heavily on institutional knowledge to add context and understanding to cryptic system architectures or generic workflow diagrams. Once the scope and operating envi- ronment have been established, use the narrative to explain the main components, services, and business processes supported. This section will be particularly valuable to nontechnical or supporting staff that may have been a part of the workflow but may have never known how the components interrelated. By developing a simple diagram to accompany this description, establishing an orientation for new mem- bers of the CoOP team will be streamlined. It should be clear in the narrative that services, infrastructure, and partner connectivity will need to be incorporated into the CoOP if this business capability is expected to function effectively during a disruptive event. Internet service providers (ISP), telecommunications, networks, and detailed inventory and configuration documentation can be added here, often embedded as artifacts within the plan, or listed as appendixes to add technical depth to the narrative and diagram.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 165

Example of High-Level Narrative and Supporting Diagram

The diagram on the following pages represent the connectivity and core computing environment to support the <Company ABC’s> online presence. The core applica- tions are supported across three operating systems (Windows, Red Hat Linux, and Solaris). Most applications rely on an instance of Oracle to manage and maintain databases used to service customers, retail centers, or to serve web content. This Oracle instance is utilizing Data Guard to increase reliability and uptime and will be used to keep the data sets between primary and secondary facilities in sync. Ongoing management of the IT environment is accomplished using <Product A>, <Product B>, and <Product C> for activities such as application version control, patching and source code integrity verification to assist with governance and compliance man- dates. Core IT services required to establish and maintain the <Company XYZ’s> web presence and security include domain name service (DNS), Microsoft’s Active Directory (AD) for user and resource provisioning, and Virtual Private Network (VPN) for secure remote connectivity. Brick and mortar franchise facilities (aka retail stores) connect via IP-Sec VPN connections using preshared secret keys. These remote sites require connectivity to key applications hosted in the <primary data cen- ter city> facility to accomplish critical tasks such as managing inventory, capturing customer metrics, and posting credit card transactions via the on-site POS terminals.

Strategic partners for the <Company XYZ> operations include

CreditCard ABC—credit card processing and payments Reach Everyone PDQ—marketing services Electro Cash DEF—payments SuperWamo WebFarm—content distribution and acceleration

IT security mechanism include <security vendor of choice> malware (e.g., virus, worms, malicious code) protection, and intrusion detection systems (IDS) to address threats such as denial-of-service attacks (DoS) and other network-based threats. Firewalls are used to further segment the network from Internet traffic.

Contracts are currently in place with three vendors to provide support services for the BCP/CoOP. <Telco PDQ> is the primary vendor that provides a hot site facility in <secondary city> in the event that production has to be moved out of the <primary data center city> facility. The <primary data center city><Company ABC’s> production environment is hosted in a managed <managed services pro- vider> facility that has inherent capabilities to address short-term threats (e.g., lim- ited duration power outages).

Additionally, <BCP Contractor X> is under contract to provide cold site ser- vices for a limited number of applications at an alternate processing facility. This site would require many hours, if not days, to become fully operational to support the cold site applications. <Media pick up and storage company MNLOP> is pro- viding record and media retention services to support secondary facility relocation requiring access to backup media (Figure 8.1).

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

166 ◾ Information Security Fundamentals

Organizational Chart As mentioned in the Purpose and Scoping section, your executive sponsor should provide an initial list of contacts for you to interact with that manage or support the business processes considered “in scope” for the project. Use this initial list of con- tacts to create a functional organizational chart. This simple tool will be referred to often and expanded often throughout the plan’s life cycle. Consistently, one of the first questions asked by many new members of the CoOP team is, “Who else have you talked to?” Having an organizational chart of the internal and external par- ties, which includes functional responsibilities, will streamline many conversations related to who is responsible for certain aspects of the environment. It will also serve as the basis for your communication plan. Figure 8.2 is a sample of a functional organizational chart for an IT-centric CoOP.

Compliance Obligations This is a topic that should be near and dear to every security and compliance prac- titioner. As we often assert but don’t always achieve, here is our chance to make sure IT security and regulatory compliance’s needs are incorporated into the plan from the very beginning. Carefully review the data, assets, and business processes

Application 1 App 2 App 3 Cold site appl #1

Cold site appl #2

Cold site apps

Windows 2008

Solaris 10

RHEL ver. 4 and 5 Oracle

VMware hosted operating systems Database

Change control tool GRC tool Help desk

Software management utilities

Anti-virus Intrusion detection

Active directory DNS

VPNIT core servicesSecurity services

Telco PDQ BCP cold site

contractor Media

pickup co. External support vendors

Credit card processor ABC

Marketing services

Electric payments

Content distribution

�ird party service providers

Support for brick and mortar retail centers Basic business operations Connectivity (VPN ‒ IPsec) Point of sale (POS) Collect customer metricsRetail center

<Company XYZ> High level functional overview

production environment

Figure 8.1 Operational environment functional overview.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 167

to clearly understand the regulatory, compliance, and contractual mandates that must be maintained under normal operations and during DR operations. In addi- tion to the previously described high-level narrative, add a dedicated section to the CoOP that establishes these important commitments and describes how you intend to meet them. A representative from legal or the compliance team, if your organiza- tion has one, will be very valuable in creating content for this carefully worded sec- tion. Articulating these requirements and the steps the organization intends to take to meet these obligations will be valuable when discussing the CoOP with partners, service providers, and other third parties. Expect it to be reviewed in great detail by individuals that oversee and verify compliance, including auditors and examiners from respective government agencies.

Name 1

Support partners Name 15

CEO

Legal and compliance Chief technology officer

Managed SVC provider

VP of engineering

Project manager

Name 3 VP of IT

Name 6 Director of tech services

(Helpdesk)

Name 4 Human resources

Name 5 Director of database services

(Manages oracle environment)

Name 7 Director of operations

(Network operations centers and change management)

Name 7 Dir of infrastructure

(IT and Security POC)

Name 8 System engineering manager

(POC for windows, VMWare, POS, retail locations, avtive directory, file/print

services, messaging, F5, layer 7 switching and mobile infrastructure)

Name 9 Manager of unix and storage systems

(Storage area networks) Name 13

US NOC manager

Name 11 Lead engineer

change control and version control

(Code Level)

Name 10 Deployment tools and automation manager

Name 12 Operations lead

CompanyABC.com

Name 14 Overseas

NOC manager

Figure 8.2 BCP sample organizational chart.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

168 ◾ Information Security Fundamentals

Example of the Compliance Section Building on the Previous Examples

The content, data collection, and associated activities for <Company XYZ>.com’s web site have a material effect on the financial performance of <Company XYZ>. Implementation of any alternate site data processing or storage must maintain the same level of safeguards and data protection as the main data center.

All existing <Company XYZ> internal policies and procedures, including infor- mation security, ethics policy, and other human resources and workforce directives remain in effect during a declared event. This requires that all employees and sup- porting vendors maintain adherence to all agreements associated with nondisclo- sure and confidentiality.

These policies, procedures, safeguards, and compensating controls are required in part to maintain industry best practices and general requirements for compli- ance with the following:

◾ Gramm–Leach–Bliley Act (GLBA) ◾ Sarbanes–Oxley Act (SOX) ◾ European Union Data Protection Directive (EUDPD) ◾ Payment Card Industry Data Security Standard (PCI-DSS) ◾ Health Insurance Portability and Accountability Act (HIPAA) ◾ {Add your favorite regulatory compliance initiative here}

<Company XYZ> expects to maintain the data security and confidentiality standards via contractual obligations with alternate location, services, and data storage providers (e.g., Company A, Company B, and Company C). These contrac- tual obligations establish guidelines for performance by support providers, but do not specify tools, procedures, or technologies to achieve compliance demonstration. <Company XYZ’s> vendor selection process and contracts management organiza- tion, supported by the IT department, have conducted due diligence on the service providers to evaluate, through staff interaction, presentations, site inspections, and executed contracts, a demonstration of adherence to best practices and use of indus- try certifications to support ongoing compliance requirements.

Summary of Critical Services and Essential Functions To avoid any confusion or misunderstanding related to the resources and business processes that are being included in the CoOP, produce a comprehensive list of elements that will be provided in the event a disaster is declared. This serves two important purposes: (1) it explicitly articulates in technical or business terms what is in scope for the plan, and (2) it explains that during an emergency situation, many organizational capabilities may be suspended or rendered unavailable if they are not required to support critical business functions. Careful review of this section by all

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 169

members of the CoOP team is crucial to verify that the services and capabilities they require are being incorporated in the recovery plan. For example, if a help desk is to remain viable during a disaster to support recovery operations, have items such as e-mail servers, telephones, service desk application servers, and workstations been provisioned? In many cases, this section will be revisited during postincident reviews as assumptions and capabilities are refined during plan testing exercises.

Example of the Critical Services and Essential Functions Section

Essential functions are those computing and connectivity capabilities that are min- imally required to maintain and host <Company ABC’s> critical applications.

Critical services Network connectivity

MPLS WAN network connectivity VPN for retail locations and IT staff

Security policy enforcement Firewall Intrusion detection service (IDS) URL filtering Antivirus

IT core services Active directory DNS DHCP

Virtual environment, OS, application, and database software VMware ESX OS platforms: Windows, Solaris, and Red Hat Linux Oracle database

Operations Center (NOC) and help desk support <Primary Production Facility> <Secondary Production Facility>

Configuration management Change management Source code version control

If you are a fan of ITIL, you may have something to this effect:

Operationally, network and service management align with industry standards such as ITIL. These models separate IT management processes and func- tions into groups that drive a service management approach aligning the

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

170 ◾ Information Security Fundamentals

deployment and maintenance of IT infrastructure into meaningful services supporting business functions. As critical functions, only incident manage- ment, problem management, and a subset of configuration management and security management (focused on Internet access) is required to keep the net- work and critical applications running under emergency conditions.

Subsequently, all other functions and processes are not deemed necessary dur- ing an emergency or declared event. These noncritical functions will stop under emergency conditions in order to allow resources to focus on the primary goal, during an emergency, of maintaining the critical applications and/or restoring connectivity to the main processing facility in <Primary Production Facility or City>.

Contingency Operations Now that we have established the scope, identified some threats, and gathered some of the technical details associated with the business processes we are tasked with protecting, it’s time to develop operational plans to detect and react to a wide range of threats. These plans include the development of a series of steps to eliminate or minimize the damage caused by a disruptive event. There is a considerable amount of content in this section that establishes the foundation for implementing an effec- tive CoOP program. Many organizations utilize the following sections as the basis for conducting an orientation session for new CoOP team members. This section is designed to establish common terminologies, define various Critical Incident Response Team (CIRT) roles and procedures that will form the basis of the orga- nization’s operational procedures to implement the CoOP program. For organiza- tions that have an existing BCP plan that needs to be updated, try to map current terms and procedures into a similar operation framework that builds on historical terms and procedures. The goal should be to create a flexible and comprehensive process that mimics the capabilities described in this section. Organizations that do not have a plan to build on will have a bit more leg work to do as they establish new roles, procedures, and workflows to implement these program components.

Incident Response Process Overview Note that a number of concepts in this section were adapted from the CERT Incident Management and Control document published on May 2010 (http:// www.cert.org/resilience). It is a well-written document, sponsored and paid for by the U.S. Department of Defense, but tends to empirically lend itself best to large government agencies. The definitions and criteria are very good so they have been largely unchanged to allow for direct references back to the much more detailed text in the original publication. Additional content and consolidation of some top ics have been undertaken to provide supplemental material that is more fre- quently encountered in commercial settings.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 171

Detected Events and Declared Incidents Incident management begins with event identification, triage, and analysis. An event can be one or more minor occurrences that affect organizational assets and have the potential to disrupt operations. An event may not require a formal response from the organization—it may be an isolated issue or problem that is immediately or imminently fixable and does not pose an organizational harm. For example, a user may report that they have opened an e-mail attachment and now their work- station is not operating properly. This “event” may be an isolated problem (e.g., event caused by malware) or an operator error that requires attention but may not require an organizational response.

Other events (or series of events) require the organization to take immediate action. Upon triage and analysis, these events may be the basis for a “declared incident” by the organization. An incident is an event (or series of events) that sig- nificantly affects the organization’s revenue-generating assets or associated services. An event that results in an incident declaration requires the organization to respond in some way to prevent or limit any detrimental effect to critical assets or services.

For example, several customers may independently report that they are unable to place orders via the Internet (events). The problem is deemed to be caused by a DoS attack that is being targeted against the web portal (incident) that is pre- venting normal revenue-generating activities to operate normally. In this case, the organization must be able to recognize the attack, analyze the threat, and quickly develop a response to mitigate the effect of the incident.

The organization must be able to effectively monitor and identify events as they occur. In near time, they must be able to quickly determine when an event or a series of events constitutes an incident that requires a coordinated and planned response. To apply incident management processes, the organization must have a foundational structure for event detection, reporting, logging, and tracking, and for collecting and storing event evidence to support administrative or law enforce- ment activities.

The extent to which an organization can accurately identify the sources and intent of events improves its ability to manage incidents and their potential detrimental effects. At a minimum, the organization should identify the most effective methods for event detection and provide a process for reporting these events so that they can be consistently triaged, analyzed, and addressed. Staff should be assigned the task of monitoring various organizational processes (both technical and nontechnical) to identify and report events. Typically, the organization’s service desk is often the front line for collecting event data and for commencing the incident management process.

The most likely sources and of methods of event detection related to the IT and security infrastructures include

◾ Monitoring of technical infrastructure (e.g., edge devices, network traffic) ◾ Reporting of problems or issues to the organization’s service centers

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

172 ◾ Information Security Fundamentals

These commonly come to the operations center via one of the following:

◾ Reports from the customer service team of end user problems ◾ Escalations from help desk reporting widespread or severe problems ◾ Notification from engineering that they have self-identified or been informed

of a functionality defect in an Internet-facing application ◾ Observation of operations and line of business managers (e.g., normal rou-

tines and workflows don’t seem to be operating correctly) ◾ Environmental and geographical events reported via media outlets ◾ Reporting from legal staff, law enforcement, or first responders ◾ Observation of a breakdown in critical business processes or asset productiv-

ity (e.g., higher than usual number of credit cards being declined) ◾ External notification from other entities such as ISP, security service providers ◾ Results of audits or assessments (e.g., PCI or vulnerability scan result)

Figure 8.3 illustrates some common events sources (external and internal).

FacilitiesPublic officials (Mayor or Governor)

Customer Partners and

service providers

First responder (police, fire, EMS)

E X T E R N A L

E V E N T

S O U R C E S

I N T E R N A L

E V E N T

S O U R C E S

IT staff Customer service

Error from website

Automated event notification

International NOC operation

centers Employees

Help desk

Event

notification

Event

notification

Figure 8.3 Common event sources.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 173

Event Detection and Documentation Many organizations, even large, well-funded companies, may not have an effec- tive method for capturing and cataloging disruptive events. The CoOP activity process probably isn’t grounds enough to build a robust system from scratch; therefore, first attempt to adapt any existing help desk or event management workflows to support your program. In many cases, a less formal process for log- ging events as they are identified and tracked typically is handled by a traditional IT help desk. Identify and document how event logging and tracking is cur- rently handled to see whether it is sufficient for your plan or if it can be adapted to ensure that potentially disruptive events are properly handled through the incident life cycle. Almost any logging and tracking capability can be leveraged to facilitate event triage and analysis activities, provide status updates on an active event, and may be useful in the postincident review processes when trying to identify trends and or performing a root-cause analysis on historical events. Logging and tracking may also be used to support forensic activities when done properly.

Logging and tracking procedures should allow for the possibility that some events will escalate into declared incidents. As a result, additional information will be collected as the incident proceeds through the incident handling life cycle and subsequent response activities.

According to the CERT guideline, basic information about events (and inci- dents) should include

◾ A unique organization-derived identifier (help desk incident number) ◾ A brief description of the event (type of event) ◾ Event category (physical or technical, based on categories predefined by the

organization such as “denial of service,” “virus intrusion,” or “physical access violation”)

◾ Organizational assets, business services, and organizational units that were affected by the event (including the seriousness of the organizational consequences)

◾ A brief description of how the event was detected, who identified the original event, and any relevant details about the operating environment currently being affected by the event (e.g., business process, partner/supplier connectiv- ity, application, network segment, and operating systems)

◾ If the event has been escalated and is now a declared incident—indicate the individuals or teams to whom the incident was assigned for containment, analysis, and response

◾ Costs associated with the event or incident ◾ Relevant dates, times, and milestones (such as when the event or incident was

first detected or when it first occurred) ◾ Actions taken thus far in response to the event or incident

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

174 ◾ Information Security Fundamentals

Critical Success Factor—There are two points of view that should be considered related to event management and data collection. A derivative of the CERT param- eters listed above is by far the most common approach because it easy to implement using a simple form(s) and minimal infrastructure to capture basic information that will suit most organizations (e.g., a web-based help desk ticket with a default assis- tance request form that is easily populated with basic information and predefined pull-down menus for the most common situations). Alternatively, some large organizations with very sophisticated response capabilities often take a different approach to event data collection and crisis management as illustrated in the book, Business Continuity Management, by Michael Blyth (eISBN: 978-0-470-47772-4), which provides a library of “Crisis Information Capture Reports” that are very pre- cisely written to capture specific information based on the type of incident encoun- tered. It is a very comprehensive approach, but would take considerable effort on an organization’s part to integrate and train help desk staff on the wide range of incidents included in the library of scenarios. That being said, it is a very well thought out approach that reinforces that the type of information collected about an event can be largely dictated by the type of crisis being addressed. A suspicious package leaking a white powder being sent to a discrete data center mailroom and a distributed denial-of-service (DDoS) attack could both have de trimental effects on an organization’s IT and business operations, but consider the type of information that would be useful to describe each threat for the staff that is responding to an activation of the CoOP. How well would a one-size-fits-all web form address the types of scenarios you anticipate could disrupt your operations?

Events Analysis and Triage

The triage of event is an analysis activity that helps the organization to gather addi- tional information for event resolution and to assist in incident declaration, han- dling, and response. Triage consists of categorizing, correlating, prioritizing, and analyzing events. Through triage, the organization determines the type and extent of an event (e.g., physical versus cyber), whether the event correlates to other events (to determine if they are symptomatic of a larger issue, problem, or incident), and in what order events should be addressed or assigned for incident declaration, han- dling, and response. Triage also helps the organization to determine if the event needs to be escalated to other organizational or external staff (outside of the incident management staff) for additional analysis and resolution (e.g., Zero Day Attack).

Some events will never proceed to incident declaration if the organization deter- mines these events to be inconsequential. For events that the organization deems as low priority or of low impact or consequence, the triage process results in the closure of the event, logging in the knowledge base, and no further actions are performed.

Events that exit the triage process warranting additional attention may be referred to additional analysis processes for resolution or declared as an incident

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 175

and subsequently referred to the Incident Response Manager (IRM) for resolution. These events may be declared as incidents during triage, through further event analysis, through the application of incident declaration criteria, or during the development of response strategies, depending on the organization’s escalation cri- teria, the nature and timing of the event(s), and the consequences of the event that the organization is currently experiencing or believe are imminent.

Declaring Incidents Incident declaration defines the point at which the organization has established that an incident has occurred, is occurring, or is imminent, and will need to be handled by a cross-functional team (aka CIRT). Transition from event detection to incident declaration can be immediate, particularly when it is clear to the orga- nization that there are significant detrimental effects on an organization’s assets or associated services and a response is required to limit these events and their effects.

The actual time from event detection to incident declaration may be immediate, requiring little additional review and analysis. In other cases, incident declaration requires more extensive analysis. Each organization may need to establish predefined criteria developed from historical experience for threats that have a high probability of occurrence and significant detrimental effect to assist operational staff in deter- mining when to initiate an immediate incident declaration. Specific guidelines are covered in detail in the Event Category and Response section of this chapter.

Once an incident has been declared, the organization will immediately per- form additional analyses to develop and implement an appropriate action plan for responding to and handling the incident. This action plan may represent a routine activity (e.g., asking users to stop opening virus-infected e-mail messages, updating an IDS signature file, or implementing a new firewall rule) or a specifically designed response that is unique to the incident and requires significant levels of organiza- tion coordination and logistical support (e.g., notifying existing customers of the detection of a targeted phishing e-mail via the company web site, issuing a public press release, or contacting law enforcement).

Incident Declaration Criteria There can be many unique factors that must be considered in determining when to declare an incident. Through experience, an organization may have a baseline set of events that define standard incidents, such as a virus outbreak, unauthorized access to a user account, or a DoS attack. However, in reality, incident declaration occurs on an event-by-event basis based on the context and potential to disrupt normal operations. To guide the organization in determining when to declare an incident (particularly if incident declaration is not immediately apparent), the organization must define incident declaration criteria (specific guidelines are covered in detail in the Event Category and Response section of this chapter).

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

176 ◾ Information Security Fundamentals

These are examples of criteria that guide an organization’s determination of whether to declare an incident:

◾ Is the event common in the organization? Has it occurred before? Did past occurrences of the event result in an incident declaration?

◾ Is the event isolated (i.e., only one user has reported it) or are there multiple occurrences of the same event being reported across the enterprise (through the service desk or similar construct)?

◾ Is the effect of the event imminent or immediate? Is the organization already suffering some effects from the event? Is there a crisis that has been precipi- tated by the event?

◾ Does the event affect the availability of core business drivers such as a high- value service that produces revenue?

◾ Does the event constitute a violation of organizational policy, fraud, or theft? ◾ Is the life or safety of employees or external entities at risk? ◾ Is the integrity and operability of a facility at risk? ◾ Is the integrity and operability of a high-value service or system at risk? ◾ Are there other organizational effects that are imminent or are already being

incurred, such as damage to the organization’s reputation? ◾ Is there a potential legal infraction or possible future legal (civil or criminal)

concerns?

Analysis of an Event Resulting in a Declared Incident Event analysis is primarily focused on helping the organization determine an accu- rate impact assessment so an appropriate impact category can be assigned. In most cases, events that are assigned an impact level of medium or high will result in the immediate declaration of an incident. Response to a declared incident is refined by the CIRT team by examining its root cause and the effects that have already been detected or are anticipated by the organization. Analysis is performed to further understand the intent of the originating entity or threat, to develop and implement action(s) to contain its effect, and to recover from any resulting damage. It should also help the organization to determine whether the incident has legal or regulatory compliance ramifications.

Incident analysis requires a broad range of skills from across the organization. Depending on the nature of the incident, analysis may involve asset owners, IT staff, physical security staff, auditors, legal staff, as well as external stakeholders such as vendors and suppliers, law enforcement, and vulnerability clearinghouses. Incident analysis may involve staff to whom the incident has been escalated or assigned to by the IRM.

Activities that may be performed to analyze the underlying events associated with a declared incident include

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 177

Internal sources of information ◾ Interviews with those who reported the underlying event(s), as well as

those who are involved in its investigation ◾ Interviews of specific knowledge experts who have a detailed understand-

ing of the area affected ◾ Interviews of asset owners for assets (such as information) that have been

affected by the incident ◾ Review of relevant logs and audit trails of network and physical activity

External sources of information (request assistance as needed) ◾ Consultation of vulnerability and incident databases such as the

US-CERT Vulnerability Notes Database and The MITRE Corporation’s Common Vulnerabilities and Exposures List

◾ Consultation with law enforcement or first responders ◾ Consultation with contracted legal and audit staff ◾ Consultation with facilities or property management personnel ◾ Consultation with product vendors and software/hardware suppliers (if

their products are involved) ◾ Consultation with emergency management staff (if the incident is a safety

concern)

Organizational Response to a Declared Incident The nature of a declared incident implies that the organization has already incurred some negative effect, however limited, that requires the organization to react. Responding to and recovering from an incident often requires four primary actions from the organization:

◾ Immediate limitation or containment of the scope and effect of the incident ◾ Implementation of an appropriate response to stop the ongoing or future

effect(s) of the incident ◾ Repairing any remaining damage ◾ Restore organizational assets and services to the state in which they existed

before the disruption

Responding and recovering may also require a carefully coordinated collabora- tion between organizational units and external entities (such as service providers). Significant planning efforts are required to co-manage handling incident logis- tics, particularly if the incident is significant, catastrophic, or would result in an extended outage of revenue-generating operations for the organization.

Incidents that the organization has declared and which require an organizational response must be escalated to those stakeholders who can implement, manage, and bring to closure an appropriate and timely solution. These stakeholders are typi- cally internal to the organization (such as a standing CIRT or an incident-specific

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

178 ◾ Information Security Fundamentals

team), but in some cases, can be supplemented by external resources in the form of contractors or other suppliers.

Responding to incidents describes the actions the organization takes to prevent or contain the effect of an incident to the organization while it is occurring or shortly after it has occurred. The range, scope, and breadth of the organizational response will vary widely depending on the nature of the incident. Incident response may be as simple as notifying users to avoid opening a specific type of e-mail message or as complicated as having to implement the CoOP alternate processing location procedures that require the relocation of staff and critical services to a facility that is on another continent. The broad range of potential incidents requires the organization response capabilities include both simple quick-fix options and longer-lasting sustainable solutions.

Actions related to incident response include

◾ Containing damage (i.e., taking hardware or systems offline or by locking down a facility)

◾ Collecting evidence (including logs and audit trails) ◾ Interviewing relevant staff (those who are involved in reporting or analyzing

the incident and those who are affected by it) ◾ Communicating status and remediation plans to stakeholders, including

asset owners and incident owners ◾ Developing and implementing corrective actions and compensating controls ◾ Implementing continuity and restoration plans

Communicating Incidents Miscommunications or inaccurate information about declared incidents can have dire effects that far exceed the potential damage caused by an incident itself. As a result, the organization must proactively manage communications when incidents are detected throughout their life cycle. This requires the organization to develop and implement a communications plan that can be readily implemented to man- age communications to internal and external stakeholders on a regular basis. This plan should provide relevant information to these entities and control or limit the degree to which misinformation and conjecture can develop. It must also consider the needs of a wide range of stakeholders that have a vested interest in obtaining information about organizational incidents in a controlled and regular manner.

Stakeholders that may need to be included in an incident communication plan:

Always contacted during an incident ◾ Members of the incident handling and management team ◾ IT staff (if the target of the incident is the organization’s technical archi-

tecture and infrastructure) Could be contacted based on requirements associated with a specific incident

◾ Asset or service owners (if their asset is the target of the incident) and ◾ Middle managers and executives

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 179

◾ Business continuity staff (if they will be required to enact continuity or restoration plans as a result of the incident)

◾ Human resources departments, particularly if personnel safety is an issue ◾ Communications and public relations staff ◾ Support functions such as legal and audit ◾ Law enforcement staff (including federal agencies), if the incident may

have criminal ramifications ◾ External media outlets, including newspaper, television, radio, and Internet ◾ Affected customers or upstream suppliers ◾ Local, state, and federal emergency management staff ◾ Local utilities (power, gas, telecommunications, water, etc.), if affected ◾ Regulatory and governing agencies ◾ Shareholders (via corporate communication with senior executive approval)

Declared Incident Closures Incident closure refers to the retirement of an incident that has been responded to; there are no further actions required and the organization is satisfied with the remediation result. It also provides notification to those affected by the incident that it has been addressed and that they should not be subject to continuing effects. Incident closure is the responsibility of the incident owner or IRM. Only autho- rized staff should be permitted to close an incident. It should be immediately fol- lowed by a formal postincident review.

Postincident Review and Reporting Postincident review is a formal part of the incident closure process. The organiza- tion conducts a formal examination of the causes of the incident and the ways in which the organization responded to it, as well as the administrative, technical, and physical control weaknesses that may have allowed the original event to occur. To be effective, postincident review requires the input of all relevant stakeholders in the incident management process. This includes those who

◾ Reported the incident ◾ Detected the incident ◾ Triaged and analyzed the incident ◾ Responded to the incident ◾ Were affected by the incident ◾ Had the incident communicated to them

Postincident review will include a root-cause analysis. As deemed neces- sary by the CIRT, tools and techniques may include cause-and-effect diagrams,

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

180 ◾ Information Security Fundamentals

interrelationship diagrams, causal factor tree analysis, etc., in support of creating a postincident analysis report. This report should detail the organization’s recom- mendations for improvements in administrative, technical, and physical controls, as well as the incident management process. Any specific operational changes should be documented for easy reference by affected personnel (e.g., update to knowledge bases or help desk procedures to react to similar incidents in the future).

Areas that need to be addressed or could be modified after an incident:

◾ Update protection strategies and controls to protect assets and services from future incidents of similar type and nature

◾ Update policies to reflect lessons learned ◾ Update training for employees regarding the incident ◾ Revise continuity plans and strategies to protect and sustain services and assets ◾ Review and revise life cycle processes ◾ Review and revise asset-level resilience requirements, if necessary ◾ Revise incident criteria ◾ Develop standardized responses to common incidents ◾ Improve incident management processes

Plan Management and Updates The BCP/CoOP should be reviewed at a minimum of once a year. If an incident has dramatically changed any operational procedure or protection mechanism, then the plan should be updated as part of the postincident response process.

At a minimum, the following management and control work products should be reviewed for ongoing applicability and accuracy:

◾ Event reports, including sources of event detection ◾ Incident management plans ◾ Incident response strategy ◾ Event and incident status reports ◾ Incident communications plan ◾ List of incident stakeholders (verify contact info) ◾ Incident management policies, procedures, standards, and guidelines ◾ Incident knowledgebase (e.g., help desk knowledge database) ◾ Event and incident evidence documentation procedures ◾ Incident declaration criteria ◾ Incident escalation procedures and categorization criteria ◾ Postincident analysis reports ◾ List of incident management process improvements ◾ Contracts with external entities

Critical Success Factor—It is very important to set the right tone for the post incident review meeting. The facilitator should open the meeting by stating that

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 181

the objective is to improve the organization’s ability to handle future incidents. The facilitator should highlight elements of the response that went well and sug- gest areas of improvement. Encourage participation and candid feedback, but care- fully moderate any attempts to begin finger-pointing or transferring accountability because something didn’t work well during a recent incident. Focus the discussion around the process, facilities, and technology elements of the plan to avoid any unnecessary stress associated with attacks directed at individuals, departments, or partner’s capabilities/performance. Senior level HR or executives that can manage the meeting properly can help keep the exchange constructive.

For the remainder of this chapter, we will focus on the practical applications of what we have learned from publicly available and private sources regarding this point and begin to translate the theory into a practical program. Remember this advice from Sun Tzu relating to planning and preparation as you begin to develop your own CoOP:

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.

Practical Application of the CERT and NIST Guidelines Any event, or series of events, can become the basis for a declared incident. The following sections are designed to provide common guidelines for classifying and developing a response for events likely to occur within the <Company ABC’s> operating environment. As part of the incident response process, the IRM will need to make an assessment of the event/incident’s effect and assign an appropriate severity level. This severity level will be based on the potential effect on the opera- tions or reputation of the <Company ABC’s> entities. An incident’s severity level drives the immediate technical and long-term organizational response. The severity level is determined as part of the Triage and Analysis phase of the response plan. It is initially a subjective evaluation by the IRM as to the risk and potential effect an incident may have on the organization or ongoing <Company ABC’s> revenue- generating operations.

As incident management activities and defensive actions are applied, subse- quent event assessments may cause an event to be reassigned to a different severity level. For the purposes of this document, the focus will be primarily on medium to high-level events that would require an incident declaration with a CIRT response. The other severity levels (e.g., low) would typically be managed as part of normal operations by NOC or IT department personnel, but are described here for clarity and documentation purposes.

Figure 8.4 is a high-level overview of the event management process. Specific event categorization, response, and role-specific responsibilities for the CERT team are covered in details in subsequent sections of this chapter.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

182 ◾ Information Security Fundamentals

Event Risk Categorization and Impact Guidelines As part of normal business operations, events will be detected and reported by both internal and external sources. The technical teams and supporting management team need to conduct an initial assessment of the event to determine if it has the potential to disrupt the <Company ABC’s> operating environment. As part of the event evaluation during the triage and analysis process, the technical team will eval- uate an event to determine if it is a possible threat. The help desk or NOC personnel will assign an initial level of risk. Depending on the nature and source of the event, defensive actions or implementation of compensating controls will be deployed to

Yes

Notify NOC supervisor

Event detected

Gather information to determine

source, impact and criticality

Verify correct impact level

Incident declaration

CIRT virtual team meeting

Notify IRM (Incident response

manager)

Determine whether or not to declare

an incident

Apply additional defensive action

Determine whether to cutover to hot site

Notify required partners

Cutting over to alternate data processing facility

�reat contained

�reat detected

Apply defensive action or

compensating control

Hour 1 Hour 2−4

Triage and analysis conducted to

determine defensive action

plan

Initiate manual cutover tasks

Notify executive management team of decision and current status

Update helpdesk, customer service or other impacted party

Initiate manual cutover tasks

Hot site cutover activities

Cold site cutover activities

If alternate site processing extends beyond 3 days

Notify executive management team

of decision and current status Update helpdesk,

customer service or other impacted party

Verify cold site operational readiness -Network connectivity

-Hardware and infrastructure -Database

-Critical applications -Support services

Reestablish critical and supporting services for

secondary applications and business processes

Verify hot site operational readiness -DNS redirect and addressing updates

-Network connectivity -Virtual infrastructure

-Database -Critical applications

-Support services

Re-establish critical and

revenue supporting services for

internet facing

applications Verify partner and retail and PCS connectivity

-VPN connectivity -Credit card processing

-Critical applications -Support services

Figure 8.4 Event detection and incident response workflow.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 183

offset the risk and potential effect. This could be as simple as updating an IDS sig- nature file or implementing a new firewall rule. Evaluation of the residual risk asso- ciated with a specific event (post countermeasure implementation) will determine whether it should be escalated to the NOC manager. Upon consultation with the NOC manager, a decision will be made whether or not to contact the IRM.

As part of the incident response process, the IRM will need to verify the initial assessment of the event/incident’s effect and assigned risk. Declaration of an incident will typically be reserved for events categorized as medium or high risk. Specific sources of physical and cyber/IT events as well as risks associated with regulatory compliance impact are included in the matrix below. In general, events that will be classified as medium or high risk will have one or more of the following characteristics:

◾ Any event that adversely threatens the confidentiality, integrity, or availability of the <Company ABC’s> operating environment, information systems, or networks

◾ Any serious violation of the <Company ABC’s> computer security or accept- able use policies

◾ Any violation of a mandatory requirement associated with a contractual, regulatory, or industry regulation

◾ Any unexpected or unauthorized change, disclosure, or interruption to the <Company ABC’s> information resources that could be damaging to cus- tomers, partners, or the reputation of any covered <Company ABC’s> entity

Risk and Impact Guidelines for Common Events

Source of Risk High Medium Low

Sarbanes– Oxley

1. Potential significant effect on revenue or earnings

2. Material effect on financial statements

3. Could result in serious fines or legal action— including request for litigation hold on business records

4. Potential significant business interruption

5. Could result in communication to Board of Directors if it occurs

1. Potential moderate effect on revenue or earnings

2. Potentially material to the financial statements

3. Could result in management letter from external audit firm (significant issue)

4. Failure to comply with legal or regulatory requirements in a specific instance

5. Potential business interruption

6. Should be communicated immediately to management

1. Slight to no effect on revenue or earnings

2. Not material to the financial statements

3. Not related to any major external audit findings or issues

4. Failure to comply with legal or regulatory requirements is not serious or an isolated case

5. Minimal business disruption

6. May need to be communicated to functional or business unit leader if it occurs

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

184 ◾ Information Security Fundamentals

Risk and Impact Guidelines for Common Events

Source of Risk High Medium Low

PCI (leverage documents such as the PCI Self- Assessment Questionnaire to populate this section)

1. Electronic media discovered that contains unencrypted magnetic stripe (aka track) data for transactions no longer required for normal business reasons

2. External network vulnerability scan reveals internal IP address is reachable from the Internet

3. Unencrypted console access method discovered (e.g., telnet access)

4. Laptop that stored unmasked primary account numbers (PAN) on unencrypted portable media was stolen from an employee’s rental car

1. Card holder data being transmitted with strong encryption key that hasn’t been changed in 2 years

2. Encrypted VPN connection discovered between Development/QA and production environment

3. Laptop of recently terminated employee containing sensitive data was returned with the personal firewall disabled

4. Unencrypted copies of cryptographic keys used to create strong cryptographic keys found on a trusted employees personal laptop

1. Wireless access point discovered with default user ID and password enabled

2. Active user IDs discovered assigned to employees that are no longer with the organization

3. Insecure service (SNMP with default community string) discovered on system transmitting encrypted card holder data

HIPAA (leverage sources such as the HIPAA HiTech Act directives to populate this section)

1. Administrative credential on system containing Electronic Protected Health Information (EPHI) was compromised by a brute force attack initiated outside the institution’s trusted network

2. Unauthorized active FTP connection dis- covered on Oracle database server used to store EPHI

3. Web site vulnerability assessment reveals that patient portal for major insurance provider is sus- ceptible to SQL injection and cross- site scripting attacks

1. Wireless access using WEP encryption being utilized to transmit files that contain EPHI information

2. Two hundred and fifty patient paper records found in dumpster behind primary care provider office in a shared office park

3. VPN activity log reveals that a terminated employee user ID was accessed twice since they were separated from a primary care physician’s office

1. System containing EPHI is not using current antivirus signatures

2. System containing EPHI is not to current OS and platform hardening standards

3. Shared user IDs being used by nursing staff in a primary care provider office for common area PCs

4. Weak passwords discovered during quarterly host vulnerability assessment

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 185

Risk and Impact Guidelines for Common Events

Source of Risk High Medium Low

Physical events (duration of outage dependent)

1. Severe storm that will affect the facility beyond carrier or facilities Service Level Agreements (SLAs)

2. Hurricane

3. Terrorist attack

4. Building bombing

5. Building fire

1. Tornado

2. Long-term utility or service provider outage

3. Chemical spill resulting in limited duration evacuation of facility

4. Water damage or facility flooding as the result of sprinkler failure or fire containment in adjacent areas

1. Short duration power outage or brownout that is expected to last less than 1 hour

2. Short duration water shortage

3. Short duration infectious diseases threat (stay at home recommendation for noncritical staff)

4. Property theft of device that may contain sensitive data on encrypted media

Cyber or IT events

1. Successful penetration and compromise of primary database by unauthorized user

2. Successful DoS attack with a significant effect on operations

3. Significant loss of confidential data

4. Loss of mission- critical application or system management tool

5. Admin or root user ID compromise

6. Illegal file server share or cross-site scripting detected

7. Site defacement that may have a significant financial or public relations effect

1. Penetration or DoS attack detected with limited effect on operations

2. Small number of systems compromised with no confidential data loss

3. Disruption of noncritical system or application for short duration of time due to network congestion or heavy traffic load

4. Widespread instance of new malware (e.g., virus/ worm or botnet) that cannot be handled by IDS or antivirus solution

5. Detection of unapproved content with only a small risk of negative financial or reputation effect

1. Isolated instance of new virus or malware that cannot be easily quarantined or neutralized by IDS or antivirus solution

2. Significant level of network probes, scans, or similar activity of concentrated reconnaissance

3. Intelligence received concerning threats to systems that may be vulnerable (e.g., security patch or configuration change)

4. Penetration or DoS attempt with no effect on operations

5. Abuse of privilege attempt using a root or admin user ID

6. Individual system failure of a noncritical system or management capability

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

186 ◾ Information Security Fundamentals

Risk and Impact Guidelines for Common Events

Source of Risk High Medium Low

Interruption of payment processing

1. Payment processing suspended or interrupted for more than two hours

2. Fraud detection and notification by credit card issuer that may indicate targeted identify theft

1. Payment processing suspended for less than 2 hours

2. Credit and debit card declines on automated renewals increase beyond daily average

1. Credit card or PayPal transaction denials affecting less than 1% of daily expected revenue target

2. Temporary loss of connectivity to a single credit card issuer (transactions being held for final processing and reconciliation by member bank)

Source of cyber event seems to originate from client or business partner computing environment

1. Long duration, targeting activity is adversely affecting ability to conduct normal business transactions

2. Analysis indicates a compromise of critical asset is being attempted via automated scripting against specific infrastructure components

3. Countermeasures or compensating controls are not able to minimize effect or isolate sources to stop the inappropriate activity

1. Persistent activity having a limited effect on normal operations

2. Traffic or intensity of network activity increasing steadily and could result in degrading company asset performance

1. Limited effect seems to be an isolated incident

2. Limited duration that can be contained by existing security tools or compensating controls

Event Category and Response As events are logged and evaluated by help desk and NOC personnel, an appro- priate response is necessary to mitigate risk and minimize potential damage. This section describes the categories of potential effect, event characteristics, examples of representative events, and recommended organizational response(s). As mentioned previously, medium to high impact events require the attention of management and could result in a declared incident.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 187

Event Category and Response Matrix

Impact Level Description Example Events Action

Low These events are not expected to escalate or create a situation that would result in an incident declaration

1. Isolated reconnaissance by potential hackers

2. Password policy violation by an employee

3. Detection and removal of virus during a scheduled scan

1. Log utilizing existing system management and help desk procedures

2. No escalation or management notification required

Medium Event has the potential to affect critical business activities or IT operations and may escalate into a declared incident

1. Repeated reconnaissance by potential hackers on from a single sources or IP Address

2. Malicious code or botnet attack blocked by existing security infrastructure or compensating control

3. Detection of deliberate and ongoing attempts to gain access to a system

1. Take defensive action as appropriate

2. Record critical incident information

3. Consult with NOC manager as part of triage, analysis, and countermeasure evaluation

4. Recommend whether to escalate or declare as an incident

5. Escalate to IRM

High Event has escalated beyond a previous classification or has recently been discovered as having a detrimental effect on the <Company XYZ’s> Internet- facing assets, the reputation of the organization, violates the organization’s security policy, could potentially result in a violation of regulatory compliance, or result in adverse legal action

1. Unauthorized access or theft of data from sensitive systems (e.g., financials or client records)

2. Financial fraud detection utilizing any of <Company XYZ’s> computers or resources

3. Improper use of high-level accounts such as root or administrator

4. Defacement of Internet-facing <Company XYZ’s> web site

5. Successful DoS attack resulting against any network infrastructure, communications component, or revenue-generating resource controlled by <Company XYZ’s> or a contracted service provider

6. Unauthorized modification of hardware, software, or configuration of a critical system

7. Theft of a computer system or storage device known or suspected of containing sensitive data

1. Capture event and incident data to provide to the IRM

2. Activate the incident response plan by declaring a high-priority incident

3. Initiate CIRT communication plan via call tree

4. Host CIRT virtual team meeting

5. Record events associated with incident sequentially

6. Identify any additional subject matter experts or support staff that could potentially be called upon to assist and, at the IRM’s direction, ask them to participate in initial incident CIRT virtual team meeting

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

188 ◾ Information Security Fundamentals

Event Category and Response Matrix

Impact Level Description Example Events Action

Business driven (medium to high)

Events could cause financial or reputational damage

1. Unusual or transaction that exceed predefined limits

2. Excessive disruption of normal financial services (e.g., high number of credit card declines)

3. Fraudulent activities detected by the business unit

4. Unusual system or customer activity reported by non-IT staff (e.g., customer service indicates a phishing scam e-mail has been sent to more than 25 customers)

1. Take defensive action as appropriate

2. Record critical incident information

3. Consult with NOC and business unit manager as part of triage, analysis, and countermeasure evaluation and decide whether to declare an incident

4. Escalate to IRM

5. If possible, refer to specific institutional guidelines as appropriate (PCI)

Response Team—Roles and Responsibilities As potentially disrupted events are detected, members of the <Company XYZ’s> IT department and the executive management team will be called upon to assist in evaluating the risk and in developing an appropriate response. This internal team is made up of technical employees, IT managers, <Company ABC’s> executives, and supporting organizations such as hot, standby, and cold site service providers. This section describes the roles and responsibilities correlated with the three levels of impact. It is to be used in conjunction with any <Company ABC>-approved com- munication and distribution plans that designate specific employees and organiza- tions corresponding with these roles. It is designed to be flexible; based on a wide range of potential threats and sources of assistance that the organization could call upon to deal with any declared incident.

Incident Response Team—Roles and Responsibilities

Impact Level

Staff Member or Team Responsibilities

Low Help desk, NOC engineers, systems and network administrator

Real and near-time monitoring of all information assets and support services

Initiate proactive or defensive action to protect against further effects of a harmful event

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 189

Incident Response Team—Roles and Responsibilities

Impact Level

Staff Member or Team Responsibilities

Low NOC manager Manage operational monitoring environment

Receive and track incident data

Determine effectiveness of initial defense action or compensating control

Manage decision process initiate event triage and analysis required before event declaration

Determine initial effect classification of an event(s)

Contact the IRM if an event is detected that will result in an incident declaration of medium or high impact

Low to medium event escalation

NOC manager Notify the IRM of details and determine if an event declaration is required

Provide ongoing information to IRM on the effectiveness of defensive or ongoing countermeasure activities

Review and update technical information provided by system administrators, help desk or customer service team

Review incident response technical details and complete any outstanding fields

Initiate logging and records collection to support CIRT virtual team recovery activities

If employees or customers are affected by event, verify that on-duty help desk is aware of situation and operational effect

Low to medium event escalation

Help desk, NOC engineers, systems and network administrator

Provide continuous updates to NOC manager on the effectiveness of countermeasures or event containment activities

Gather data and complete incident declaration form and forward to appropriate NOC and IT functional manager

Low to medium event escalation— triage and analysis activities

IRM (initially, a NOC manager until additional support or escalation is required)

Review incident declaration documentation and discuss current and short-term response with NOC manager

Evaluate effectiveness of countermeasures and containment activities to determine if risk has been reduced to a low level

Determine if event has been given proper impact classification

As needed, initiate CIRT virtual team meeting (see Comm Plan)

Assume responsibility for directing the incident response

Notify senior executive team, if appropriate, of event declaration decision

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

190 ◾ Information Security Fundamentals

Incident Response Team—Roles and Responsibilities

Impact Level

Staff Member or Team Responsibilities

Medium- or high-risk event has resulted in a declared incident

IRM (depending on the situation, the duties may be transferred to a more senior operations manager)

Verify content of incident response declaration form and distribute in advance of CIRT virtual team meeting

Lead CIRT virtual team meeting to review event detection, ongoing response, and to gather input on best mitigation strategy

Direct NOC manager or IT staff on remediation efforts

Declare a primary <Company ABC’s> partner facility that will be supporting production data processing and hosting in the short-term and long-term

Notify vendors/external service providers as appropriate (e.g., hot site company, cold site company, off-site media storage company)

Set short-term and long-term milestones to support any relocation activities

Initiate any manual cutover activities required to restore services

Provide help desk and/or customer service with periodic updates and set expectations for restoration of critical services

Communicate activities to senior executive management

Manage event through to reconstitution back to main data processing facility

Collect artifacts and data that will be useful in postincident review activities

Alternate Facility Operations—Hot Site The incident response workflow illustrates that, in some instances, an event will prompt the declaration of an incident that requires that business activities or IT operations will need to be transferred to an alternate facility to avoid prolonged disruptions. According to the Florida Business Disaster Survival Kit (www. fldi sas ter kit.com), here are the definitions associated with hot sites.

Hot Site—A site (data center or work area) provides a Business Continuity Management (BCM) facility with the relevant work area recovery, telecom- munications, and IT interfaces and environmentally controlled space capable of providing relatively immediate backup data process support to maintain the organization’s mission-critical activities.

Hot Standby—A term that is normally reserved for technology recovery. An alternate means or process that minimizes downtime so that no loss of pro- cess occurs. Usually involves the use of a standby system or site that is perma- nently connected to business users and is often used to record transactions in tandem with the primary system.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 191

These types of facilities are experiencing very exciting changes in terms of capabilities and technology architectures that will make them viable for a much broader range of clients. Historically, hot sites were either maintained in another facility owned by the same company or contracted via a managed service provider to provide nearly identical hardware and operating environments to provide recov- ery services very quickly. For most companies and government agencies, the capi- tal and operating cost to duplicate their most important business functions was beyond their financial means. Even as companies expanded globally, which should have facilitated the distribution of business operations across not just geographi- cally isolated facilities but, in some cases, across continents, only a few were able to take advantage of this new opportunity to improve resiliency. Even if important issues such as localization (e.g., providing services and products in local languages) could be accomplished, the cost of duplicating hardware, slow connectivity links across long distances, and restrictive licensing by software and service providers, until recently, continued to hinder all but the largest organizations and government agencies.

The maturity of virtualization (e.g., hardware, software, and cloud computing) technologies, faster connectivity, secure remote access, and data aggregation capa- bilities is now affordable for almost every tier of organizations. The availability of these innovations is making the reality of having a standby capability available to almost every organization in any industry vertical.

Virtualization has many business benefits and even more potential returns as a mainstay in many organization’s CoOPs. Many organizations have migrated many IT production facilities to heavily rely on this architecture. This has huge ramifi- cations for organizations that want to maintain a hot standby or remote hot site capability. Hot standby environments are easier to achieve as the same management capabilities that maintain the production virtual computing environment are sim- ply replicated and maintained in near-time at remote facilities. The same virtualiza- tion management tools that are used to maintain and update production virtual machines can be leveraged to quickly update in near-time, archived versions, or libraries of key server and client images. Using high-speed storage area networks (SANs), gigabit transfer speeds, and large amounts of RAM allocated to the pro- cess, security standards can be quickly maintained to the latest corporate standard for each virtual server or desktop instance including updates to operating systems, configurations, applications, and patches. Other organizations will simply choose to mirror a production facility with an exact virtual replica in an offsite location that can almost completely automate the synchronization of transaction-intensive data- bases or rapidly changing web content using dedicated tools that compensate for environmental conditions such as WAN latency, encryption at rest and in transit, and error correction in near real-time. Over time, this high-availability architecture will not only be the cornerstone of many CoOPs but will also provide additional benefits beyond fault tolerance and deliver increased application and service per- formance through true distributed processing, which supports higher transaction

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

192 ◾ Information Security Fundamentals

performance and quicker responses to distributed client requests. Additional avail- ability benefits will be derived for other key hot site support activities as more media handling and secure storage is adopted in the cloud. Backup copies of key docu- ments, forms, call list, vital files, application source code archives, and other elec- tronic assets on secure, remotely maintained collaboration servers (e.g., SharePoint) will also speed up many of the recovery processes that historically relied on hard copy or portable magnetic media that only existed in a single physical location that could be difficult to reach during a natural disaster.

The global market demand for increased speed and resiliency of global tele- communication networks has also transformed the way organizations can design CoOPs. Dedicated, buried high-speed links between primary processing facilities and backup data centers will soon be eclipsed by dynamic, secure connections that can use sophisticated routing algorithms to bypass slow or unavailable paths in favor of less congested links over great distances. The ability to burst large amounts of data during off-peak periods, securely store data in the cloud, and dynamically build and tear down highly secure connection as needed across robust, fault- tolerant public networks can result in tremendous gains in performance, availability, and confidentiality for most organizations. These new capabilities across hardwired connections are complimented by advances in wireless technologies that add yet another layer of redundancy for the transmission and communication requirements of CoOPs. A CDMA or 4G carrier network connection may not be ideal network connectivity for normal transaction processing or e-mail traffic, but if it allows a critical business function to operate even at a reduced throughput, it may be suf- ficient to keep the business running for a short period.

The ability to communicate with CIRT team members has been affected even more dramatically by the proliferation of network and personnel connec- tivity options. Telecommuting has evolved beyond company-provided leased lines between specific locations and dedicated PBX systems that could only route calls to your primary work phone number. The proliferation of advanced portable technical capabilities carried by most consumers opens a wide range of communication and data exchange operations even if an organization’s primary data and telecommunication facilities have been rendered inoperable. Most IT and management team members carry a smart phone device, can use personal devices to connect to corporate resources via approved VPNs, have access to pri- vate voice over IP if not video conferencing capability (Skype), personal e-mail accounts, multiple phone numbers, and free conference bridge services in addi- tion to the capabilities provided by most companies. Even important commu- nication tasks such as contacting CIRT team members via call trees or cascade systems have been automated via recent corporate investments in technologies such as unified communication and crisis management and alert services. This is especially true in university environments and utility companies in which commu- nicating with entire student bodies or every employee has been highly automated

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 193

in response to increased personnel safety associated with natural disasters or acts of violence.

There are some additional challenges that have emerged as a result of all these new capabilities that should be addressed by every organization as part of their CoOP process. As critical data or services are moved out of corporate-owned facili- ties or are being performed by business partners instead of employees, compensating controls need to be established to maintain the organization’s security posture and demonstration of regulatory compliance. Carefully worded terms and conditions in vendor contracts and service agreements should explicitly establish ownership, cus- todianship, and accountability for critical topics such as maintaining computing environment standards and safeguards to meet appropriate compliance mandates. The legal, compliance, and purchasing professionals in your organization should be included in the due diligence and execution of these agreements. Consider including terms and conditions/clauses that protect your organization’s right to inspect and verify that data and services are being provided according to agreed upon standards and guidelines. For example, if contracting with a service provider that is providing a multi-tenant virtual environment using shared hardware for use as a standby site, you should verify how critical tasks such as separation of data is maintained. It is best to explicitly address all key concerns in writing and maintain accurate records to avoid any confusion about roles or accountability responsibili- ties. Your CoOP should include provisions with all key vendors to address data loss (e.g., lost or stolen media), security and compensating controls, incidents handling, and computing environment maintenance activities while operating at an alternate processing facility. Carefully consider the complexity and logistics of maintaining your production environment capabilities within the confines of someone else’s managed facility (e.g., management reporting, exception handling, VPN access for IT and development staff, virus protection, IDS, OS hardening, applying patches, reviewing activity logs, application performance management, and database main- tenance activities) can quickly become overwhelming and very cumbersome if not properly planned for proactively.

Critical Success Factor—It is very important to consider two things very care- fully before implementing a hot site environment. (1) If there are weaknesses in critical security processes or procedures, they will likely be amplified or get worse when migrated to a virtual implementation. Consider how difficult it will be to address topics such as threat management, role-based access control, change management, data loss prevention, backup, and recovery if these tasks are further abstracted beyond company-owned facilities that you cannot secure via additional compensating controls (e.g., physical access, employee badging). (2) If you plan to migrate data, services, or business processes into a third-party facility, shared virtual environment, or cloud-based architecture, make sure there is a method and procedures to migrate it back to within your organization’s control if you need to switch vendors or if you are not happy with that facilities’ performance.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

194 ◾ Information Security Fundamentals

Alternate Facility Operations—Cold Site There exist some business cases that require some organizations to still maintain cold sites. Considering the benefits of modern standby virtual architectures for IT components, it is expected that they will be less frequently utilized moving for- ward. For organizations that have determined that the sensitivity of data, specific hardware or equipment (e.g., manufacturing or printing), or where physical secu- rity is paramount, a cold site may be your only option. There are third parties that can be contracted to provide these services if your organization doesn’t have the facility or capacity. In most instances, every operating cost and capital expense is at least doubled to keep the two facilities in sync. For this reason, many industries will set up “reciprocal agreements” with similar business partners to pool resources or distribute the cost of equipment if the collective requirements can be satisfied with universal components. A great example is when utility companies (e.g., electrical) operating in different states set up agreements to assist with recovery efforts if one is struck by a natural disaster and a similar capability can supplement repair and restoration activities (e.g., linemen, bucket trucks, generators, and trailers).

The other consideration with cold sites is that in many cases the recovery pro- cess takes significantly longer than hot or standby sites. Setting up hardware, load- ing software (OS, application, data) from portable media, and patching to current corporate standards is labor-intensive and may be complicated if physical access to the cold site is hampered by bad weather, limited transportation options, or signifi- cant distance away from the primary production facility.

Reconstitution to Primary Facility After an incident has been addressed, the primary processing facility has been deemed safe to resume operations, and appropriate steps have been taken to pre- pare it for resumed processing, then reconstitution activities to the primary facil- ity can proceed. These procedures can be generally described in the CoOP but, in practice, typically involve very specific operational and technical procedures to maintain proper sequencing to reestablishing capabilities in a specific order of tasks that enables foundational elements, verifies operating capabilities of internal and partner connectivity and capabilities, and establishes synchronization between envi- ronments before cutting back over to the primary processing facility. For many orga- nizations, this will be a series of manual and automatic tasks and procedures that are frequently performed in a reverse sequence of the hot or cold site cutting over.

Postincident Review and Response Evaluation Upon the completion of reconstitution, and once normal operations have been reestablished, it is very important that the CIRT and any affected parties evaluate

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 195

the performance of the organization and its partners in responding to a declared incident. The following sections contain a framework of the topics that should be discussed and evaluated. Additionally, there is an optional section related to perfor- mance metrics that may be requested by senior management as part of the postin- cident review to quantify performance, impact, or associated cost of improving the organization’s response capability. The content in these sections was adapted from the CERT Resilience Management Model version 1.0 and various NIST publications.

Incident Review Report Template Topics Preparation

1. Were the location and supporting procedures to invoke the BCP/CoOP easy to access and known by all required parties?

2. Could more education of users or administrators have prevented the incident altogether or minimized the effect?

3. Were all of the people who needed to respond to the incident familiar with the incident response plan?

4. Were any actions that required management approval clear to participants throughout the incident?

5. Did the available staff have sufficient skills to do an effective job of respond- ing to the event?

Event Identification/Detection 1. Does the organization know exactly when the initiating event first occurred? 2. How soon after the incident started did the organization detect it? 3. Could different or better logging have enabled the organization to detect the

root cause event sooner? 4. How was the initial event detected? 5. How was the event routed to the help desk or NOC? 6. Should the event have been detected sooner by other monitoring capabilities

currently in place? 7. Were the technical/business processing activities being effectively monitored,

including exception handling?

Communication 1. Were the appropriate people available when the CIRT virtual team meeting

was initiated? 2. Did technical staff effectively document all their activities to facilitate the

initial CIRT virtual team meeting? 3. Were appropriate individuals outside of the standing incident response team

notified and available for the CIRT virtual meeting? 4. Were incident details communicated appropriately to stakeholders at a level

commensurate with their involvement (e.g., executive management)?

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

196 ◾ Information Security Fundamentals

5. Which communications channels were most effective or helpful? 6. Which communication channels were rendered inoperable or ineffective dur-

ing the declared event? 7. Did all the information flow from the appropriate source?

Response 1. How smooth was the process of invoking the incident response plan? 2. How well did the organization follow the plan? 3. Was the initial impact level correctly assigned on initial event detection? 4. Were originating events properly identified and logged? 5. Were proper procedures used to collect supporting technical and counter-

measure effectiveness results? 6. Were disruptive events efficiently triaged and analyzed for root causes? 7. Was the incident properly declared according to the plan and response criteria? 8. Was the incident response properly escalated to designated stakeholders? 9. Did the initiating event originate from a known source of vulnerability or was

it a new attack vector/unanticipated disruption?

Containment 1. How well was risk mitigated/damage minimized once the originating event

was accurately identified? 2. Were preventative controls applicable to the originating event working

properly? 3. Did any other compensating controls assist with the containment? 4. Did the compensating controls meet their stated intent in support of resil-

ience or failover requirements? 5. What environmental conditions allowed the originating event to occur? 6. Did the available staff have sufficient skills to do an effective job of containment? 7. If there were decisions made on whether to disrupt service to internal or

external customers, were they made by the appropriate people? 8. Are there changes that could be made to the environment that would have

made containment easier or faster? 9. Was there an easy and effective method for technical staff to document all of

their activities in support of ongoing CIRT activities?

Recovery 1. Was the recovery complete? 2. Was any data permanently lost? 3. Was there sensitive data that will likely never be recovered?

i. Are there any associated mandatory reporting requirements? 4. If the recovery involved multiple servers, users, networks, etc., how were deci-

sions made on the relative priorities, and did the decision process follow the incident response plan?

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 197

5. Was a postincident review performed to improve the process? 6. Were proper forensics procedures used to collect and preserve evidence in the

event data needed to be handed over for administrative procedures? 7. Do any changes need to be made to administrative, technical, or physical

controls to improve BCP/CoOP response capabilities?

Incident Management Performance Metrics An organization may elect, as part of their BCP/CoOP, to collect specific perfor- mance metrics to evaluate the benefit and effectiveness of the organization’s abil- ity to meet management-defined operating objectives. Senior management should evaluate the data collection and reporting capabilities associated with the BCP/ CoOP to provide effective oversight and performance validation.

The following represents a set of operating parameters and metrics that may prove valuable to monitoring and evaluating the ongoing performance of the orga- nization against the CoOP.

◾ Percentage of operational time that high-value services and assets were unavailable (by both users and customers) due to declared incidents

◾ Percentage of incidents that exploited existing vulnerabilities with known solutions, patches, or workarounds

◾ Number and percentage of events or incidents handled in a specific period ◾ Number and percentage of events or incidents that are contained in a specific

period ◾ Percentage of incidents that require escalation ◾ Percentage of incidents that require the involvement of law enforcement ◾ Number of events or declared incidents that have been logged but not closed ◾ Average time between event detection and incident declaration, response, or

closure ◾ Percentage increase in the volume of events and declared incidents in a spe-

cific period ◾ Extent of consequences to the organization due to incidents by incident type

(also referred to as magnitude; often provides insight into the difficulty to detect and remediate damage associated with specific events)

◾ Percentage increase in the elapsed time of the incident life cycle by incident type (the goal is to determine if a particular event or incident is more difficult than another to handle)

◾ Number and percentage of recurrence of specified events or incidents (look for patterns)

◾ Percentage increase in resource needs (training, skill building, technology investments, or additional FTEs/contractors) to support the incident man- agement program

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

198 ◾ Information Security Fundamentals

◾ Number of post-incident review activities that resulted in control changes or improvements to the CoOP process

◾ Number of risks in which corrective action is still pending (by risk rank) ◾ Level of adherence to process policies, number of policy violations, number

of policy exceptions requested, and number approved ◾ Number of process activities that are on track per remediation plan ◾ Resource needs to support the remediation process ◾ Costs to implement the recommended changes

CoOP Review Exercises and Testing Procedures However beautiful the strategy, you should occasionally look at the results.

—Winston Churchill

Establishing the initial BCP/CoOP is an important early milestone for protecting an organization’s business interests. To be effective, the plan and supporting activ- ities need to be maintained via a vigilant performance review life cycle consisting of ongoing updates, adaptations, and practical exercises to verify the program’s effectiveness. Employee orientation training, active participation in tabletop sce- narios, and practical drills will provide an environment for CIRT team members to understand assigned roles and responsibilities while simultaneously building confidence in response capabilities in a controlled environment. Partner and sup- porting organizations should be invited to participate in at least one annual test of the procedures to verify that contact information, contractual arrangements, and response capabilities support and meet your organization’s SLAs and recovery windows.

Employee and Partner Training and Test Procedures There should be at least an annual tabletop and practical test of the BCP/CoOP. Below is a list of the minimum training for all critical members of the CIRT.

CIRT Team Member Orientation This is an overview of the business continuity/continuity of operations program. Each CIRT team member should attend once per year. This should explain the plan from conceptual overview, event sources, incident declaration, prioritization, communication plan, response procedures, hot and cold site capabilities, and res- toration plans. It should include role-specific responsibilities for each CIRT team member.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 199

CIRT Team Tabletop Exercises Shortly after the completion of the CIRT team member orientation, the entire team should participate in a tabletop exercise with a focus on handling a wide range of scenarios utilizing approved recovery strategies. Leaders (IRM) from both the pri- mary production and secondary facility should lead some of the tabletop exercises to verify an understanding of the roles, response and escalation procedures, and long-term support responsibilities.

Testing Scenarios The event category and response matrix is an excellent source of scenario materi- als as well as any historical organizational events that result in a declared inci- dent. Additionally, NIST Publication 800-61 Computer Security Incident Handling Guide rev 1 provides a wide range of scenarios and supporting technical informa- tion related to response and technical considerations that would prove valuable dur- ing this training. This is available at http://csrc.nist.gov/publications/PubsSPs.html.

Specifically, the following scenarios, located in Appendix B of the NIST docu- ment, would serve as relevant training material for many CIRT teams:

Scenario 1: Domain Name System (DNS) Server Denial of Service Scenario 3: Worm and DDoS Agent Infestation Scenario 4: Use of Stolen Credit Card Numbers (Business Generated Event) Scenario 5: Compromised Database Server

(Could be expanded to highlight regulatory compliance consequences) Scenario 8: Outbound DDoS Attack Scenario 10: Hacking Tool Download

(Highlights enforcement of Appropriate Use Policy and HR Involvement) Scenario 12: Telecommuting Compromise

(Could be customized to reflect VPN connectivity and supporting remote facilities)

Functional Exercise Hands-on testing of hardware, connectivity, and partner support capabilities to alternate processing facilities should be carefully rehearsed before testing in the production environment. Scenarios should be adapted from the tabletop exercise and based on the most likely and disruptive events established in the Risk and Impact Guidelines for Common Events for your organization. It cannot be empha- sized strongly enough how important proactive communication and coordination across employee and partner organizations is before and during functional exer- cises. Every effort should be made to minimize even the potential effect on normal production and revenue-generating activities. Permission from senior management

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

200 ◾ Information Security Fundamentals

should always be received in writing before any functional exercise. Methodical record-keeping, event and activity sequencing, rollback procedures, milestones, checkpoints, and alternate communication channels should be established for each functional exercise.

Plan Reviews Annual plan reviews, tabletop, training, and functional exercises should be recorded as part of the ongoing management of the CoOP life cycle. This is an important activity that is a regulatory requirement for some organizations. For each plan review, the following information should be captured:

Plan Holders

Enter the dates when plan reviews were conducted. Incident response team leader (name) Alternate team leader (name) (Name) (Name) (Name) (Name)

Training/Exercises Enter the dates and number of participants for each activity. Each exercise type is expected to be conducted at least once per year.

Activity Date Conducted Comments

Orientation

Team exercise

Team leader

Functional exercise

CIRT team leaders: attach participant sign-in sheets, evaluations, and comments to meeting notes to document ongoing inclusion of relevant parties and maintenance of the plan.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

Continuity of Operations Planning ◾ 201

Common Appendixes and Supporting Documents There are many additional data sources, artifacts, and documents that can be used to supplement an organization’s CoOP. Call trees, contact lists, network architec- ture diagrams, equipment inventory and configuration, backup or hard copies of critical device configurations, manual cutover procedures, and related documents are the most common. If creating the plan for the first time, remember to leverage artifacts and content created in previous sections. For example, utilize the func- tional organizational chart as the basis for your contact list and call tree if neces- sary. As part of the annual review or testing exercises, take every opportunity to verify that the plan and its contents are up-to-date because personnel, roles and responsibilities, business practices, and new business partners change frequently in most organizations.

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .

C op

yr ig

ht ©

2 01

3. A

ue rb

ac h

P ub

lis he

rs , I

nc or

po ra

te d.

A ll

rig ht

s re

se rv

ed .