Create a three page policy for business continuity for the White House security staff.
The information to use as a resource for your policy is provided below (taken from SunGard Availability Services at www.sungardas.com, limited use for educational purposes) and also in your reading for the week (See Appendix 1 for policy information).
•    Plan purpose: for example, to allow company personnel to quickly and effectively restore critical business operations after a disruption.
•    Plan objective: for example, to identify the processes or steps involved in resuming normal business operations.
•    Plan scope: for example, the work locations or departments addressed.
•    Plan scenarios addressed: for example, loss of a primary work area, loss of IT services for a prolonged period of time, loss of workforce, etc.
•    Plan assumptions:  for example, you may want to call out the number of work locations impacted at any given time that key personnel are available for any recovery efforts, or any assumptions you may have made about vendor or utility service availability.
Use the headings and rationale below to prepare the business continuity plan for the White House security staff. Go to http://www.whitehouse.gov to obtain ideas on security concerns.
PLAN SECTION:
Recovery Strategies and Activities

After the initial introductory section, there are usually a number of paragraphs about the strategies outlined in the plan, as well as the specific personnel undertaking the recovery and the recovery activities. Examples of sections that you may want to consider for your own BC/DR plan include:
Recovery Strategy Summary: In this section, a plan will typically outline the broad strategies to be followed in each of the scenarios identified in the plan Introduction section. As an example, if “loss of work area” is identified as a possible failure scenario, a potential recovery strategy could be to relocate to a previously agreed-upon or contracted alternate work location, such as a SunGard work area recovery center.
Recovery Tasks: This section of the plan will usually provide a list of the specific recovery activities and sub-activities that will be required to support each of the strategies outlined in the previous section. For example, if the strategy is to relocate to an alternate work location, the tasks necessary to support that relocation effort could include identifying any equipment needs, providing replacement equipment, re-issuing VPN tokens, declaration of disaster, and so on.
Recovery Personnel: Typically, a BC/DR plan will also identify the specific people involved in the business continuity efforts, for example, naming a team lead and an alternate team lead, as well as the team members associated with any recovery efforts. This section of the plan will also include their contact information, including work phone, cellphone, and email addresses. Obviously, because of any potential changes in personnel, the plan will need to be a “living” document that is updated as personnel/workforce changes are made.
Plan Timeline: Many plans also include a section in the main body that lays out the steps for activating a plan (usually in the form of a flow chart). For example, a typical plan timeline might start from the incident detection, then flow into the activation of the response team, the establishment of an incident command center, notification of the recovery team, followed by a decision point around whether or not to declare a disaster. A plan timeline may also assign the recovery durations or recovery time objectives required by the business for each activity in the timeline.
Critical Vendors and their RTOs: In this section, a plan may also list the vendors critical to day-to-day operations and recovery strategies, as well as any required recovery time objectives that the vendors must meet in order for the plan to be successful.
Critical Equipment/Resource Requirements: A plan may also detail the quantity requirements for resources that must be in place within specified timeframes after plan activation. Examples of resources listed might include workstations, laptops (both with and without VPN access), phones, conference rooms, etc.

Citation for this book:
Bacik, Sandy. ( © 2008). Building an effective information security policy architecture. [Books24x7 version] Available from http://common.books24x7.com.ezproxy.umuc.edu/toc.aspx?bookid=26398.

Chapter 7: Putting It Together
Overview
The manual of style has been created, the list of initial topics has been put together, and the initial documents have been drafted. Now comes the hard part: the approval process and the actual implementation of the initial information security policy architecture.
We know from previous chapters that the cornerstone of an effective information security policy architecture is the well-written policy statement. This is the source from which all other policy architecture documents are written. That initial information security policy is the executive team’s directives to create an information security program, establish its goals and measures, and target and assign responsibilities. The current task is to take these documents, decisions, common practices, or folklore and fashion them into an approved published information security policy architecture that is used as the basis for protecting information resources and guiding employee behavior.
7.1 Topics to Start With
Many times, the hardest thing is to figure out the first set of topics or priorities for the security policy architecture and the second hardest thing is to get through the reviews and approvals. Before an enterprise can determine the top security policy architecture priority, the enterprise needs to have a statement from the top endorsing the need for security or assurance of enterprise assets. If a risk assessment has been performed, then you can start with the high risk areas. That choice will depend on the organizational structure and the amount of staffing you have. The higher-level topics were talked about in a previous chapter, so if the security policy architecture is being started from the beginning, then the highest level security policy topic needs to be completed.
Another way to start the security policy architecture is the enterprise can start with lower level process documents after the top management endorsement. These documents are the device and software security configuration standards and the security work instructions, procedures, processes, or standard operating procedures. These types of documents normally do not need to have approvals all the way up the management structure. Therefore, these documents can be written and implemented more easily than a policy statement or guideline. These lower level documents give the security policy architecture a strong hold for being implemented within the organization. This option does contradict the statements in Chapter 3 and Figure 10 for building a security policy architecture from the ground up. By contrast, an enterprise knows that there need to be configuration standards and standard operating procedures. Therefore it does fit together in the end.
The last option for priorities is addressing problem areas that have been happening within the enterprise environment. If social engineering is an issue, then maybe user awareness takes priority. If virus and worm infections are an issue, then enhancing and developing preventative documents and training take priority. If Internet surfing and downloading are an issue, then the user awareness and additional monitoring and reporting take priority. The priorities depend upon the enterprise and the direction that management wants to take.
No matter which way the security policy architecture is going to be initiated or reviewed, the information security team needs to gather the following information to ensure an understanding of the enterprise:
•    Organization charts
•    Network diagrams
•    Existing policies
•    Application list enterprise and departmental to include function
•    Management tools
•    Network device list to include function, vendor, and version
•    Production server list to include function, operating system, and version
•    Enterprise strategic plans
•    Compliance and privacy requirements
•    Threat, concern, risk matrix for the most precious enterprise assets or a definition of enterprise assets
7.2 Reviews
Before getting any approvals for the documents, the documents need to be reviewed. Because electronic forums are the best way to initially review documents, start the document review process with a task to the review team. A review team consists of an author who controls the review cycle, reviewers who will make comments on the document, and an observer, a staff member outside the policy team, who will review the document, but will not have a vote to move forward with the document.
The initial review team should be no more than five subject matter experts. These subject matter experts should understand risk, the operating environment, and the business requirements. With smaller organizations, the team should be about three people. As the author, you need to ensure that the document will fit into the enterprise culture.
If the review team includes staff from other countries or areas in different time zones, the review process will need to accommodate different time zones. The size of the document also determines the estimated review time for the document. Listed below are some guidelines for estimated document review times, but this does not include estimated times if the document needs to be translated before someone can review the document:
•    Initial Document Review
o    201 pages or more in length: 80 business hours of review time
o    101–200 pages in length: 60 business hours of review time
o    51–100 pages in length: 40 business hours of review time
o    0–50 pages in length: 24 business hours of review time
•    Subsequent Document Review
o    201 changed pages or more: 40 business hours of review time
o    101–200 changed pages: 32 business hours of review time
o    51–100 changed pages: 16 business hours of review time
o    0–50 changed pages: 8 business hours of review time
These estimated time frames take into account that staff are working on other projects and are not full time to the review team. If the members are 100 percent dedicated to the review team, then the times can be cut by at least one third.
What is the actual document review cycle? It is simple. It is just like a project requirements review:
1.    Create a central point to store the information security policy documents for review. Ensure that the review team has access to the document storage. Documents should not be emailed because the team may not remember who has the most current version.
2.    Publish information security policy document(s) for review. The author places the information security policy document in the central location.
3.    The author sends out a notice to the reviewers. A sample email is documented below.
Subject: Review Requested: Information Security document XXX
You have been selected to be on the review team for the XXX information security policy architecture document. The purpose of this document is XXX and is to apply to the whole enterprise. The document is located XXX. Please review the document for accuracy, content, grammar, completeness, and how it would fit into the enterprise. You have full editorial liberties when reviewing the document. If there are any questions, please do not hesitate to contact me. The review comments are due by close of business on XX/XX/XX. Thank you.
4.    The reviewers will edit the appropriate documents making revisions and comments and asking questions.
5.    The author sends out a reminder to complete the information security policy document(s) reviews.
6.    When the reviewers have completed the document review, the author will review all of the input and comments.
7.    The author will merge all of the revision.
8.    Repeat the review cycle with the review team if the author decides not enough changes have been made to the information security policy document(s). If there are only grammatical changes or items to better clarify statements, then the document may not need to be re-reviewed.
As the reviewer reviews the information security policy document, he or she needs to ask the following questions while reading the documents:
•    Is there applicability and completeness for business requirements, compliance, and regulatory requirements?
•    Can the requirements within the document be tested and have documented results?
•    Does the document have correctness/accuracy?
•    Does the document employ correct grammar?
•    Dos the document have technical adequacy, where applicable?
•    Business requirements
o    Have integrity and evidential value of information been maintained?
o    Is information available to properly authorized personnel?
•    Is the information security policy document long enough or too long?
•    Does the roles and responsibilities section cover the enterprise?
•    Is the information security policy document customized enough to meet business requirements? Has the enterprise done its due diligence?
•    If we give the policy to a high school student, could the student understand it and state the meaning of the document?
•    Does the information security policy document state how the enterprise feels about risk and how risk will be handled?
•    Would a staff member state that the information security policy document is reasonable and realistic? Will it impact their day-to-day activities?
After the review team completes and accepts the document, and then the document needs to be forwarded onto the management team for the formal approval sign-offs.
7.3 Project Approval
In preparation for getting signature approvals, electronic communication, namely e-mail, is one of the better methods to communicate with the executive team.
Many executive teams will give staff members no more than 15 minutes to make a presentation to get a point across, catch their attention, and get their agreement or approval to move forward. When you are dealing with an information security policy architecture, the issue is not whether security is necessary, but whether it is recognized as an urgent need. The executive team understands that the enterprise environment is characterized by more complex computer environments, multiple computer platforms, multiple levels of information users, and vast conglomerates of integrated computer networks. Some executive team members may not understand information security in detail, but they will understand information risk to the enterprise.
When an executive presentation is performed, the presenter needs to keep in mind the limited time that is available and remember to answer these four questions:
1.    From a strategic point of view, is the enterprise doing the right thing by writing an information security policy architecture?
2.    From an enterprise architecture point of view, is the enterprise approaching limiting asset risk in the right way?
3.    From a value point of view, will the enterprise achieve benefits from the implementation of an information security policy architecture?
4.    From a delivery point of view, is the implementation plan being done well for the benefit of the enterprise?
With these four questions, two slides with four balloons each can be the high-level presentation for getting approval to move forward with a project to develop or review an information security policy architecture. The first set of four balloons would be for project goal, project objectives, the core project team, and using the project approach, which present the business case for the information security policy architecture. Sample balloons can be found in Figures 14, 15, 16, and 17.
________________________________________
Goal
Establish an information security policy architecture that provides accountability and reliable protection to limit enterprise asset risk.
________________________________________

Figure 14: Sample project goal.
________________________________________
Objectives
•    Ensure the confidentiality, integrity, accountability, and availability of enterprise assets
•    Protect against anticipated enterprise asset risk
•    Protect against unauthorized access or use of enterprise assets
________________________________________

Figure 15: Sample project objectives.
________________________________________
Core Project Team
•    Executive Sponsor—CEO
•    Project Sponsor—CSO
•    Project Manager—Sandy
•    Business Lead—Michael
•    Reviewers—Mary, Bill, Stan, Mark, Kevin
________________________________________

Figure 16: Sample core project team.
________________________________________
Policy Architecture Approach
•    Planning
o    Perform risk assessment
o    Identify gaps with existing policy architecture
o    Document key business requirements for asset protection
•    Phase I
o    Identify a matrix of required topics
o    Present findings to executive team
•    Phase II
o    Develop top level information security policy architecture
o    Develop second tier information security policy architecture
________________________________________

Figure 17: Sample project approach.
The second set of four balloons would be to discuss keys to project success, project assumptions, project and policy architecture metrics, and a recommendation to move forward, which present the executive summary for moving forward with developing and implementing an information security policy architecture. Sample balloons can be found in Figures 18, 19, 20, and 21.
________________________________________
Keys to Success
•    Implementation of an enterprise information security policy architecture to limit enterprise asset risk
•    Standardization of device configuration, monitoring, and implementation
•    Guides for acceptable use when evaluating business requirements
________________________________________

Figure 18: Sample keys to success.
________________________________________
Assumptions
•    Risk assessment and gap analysis started within the next month
•    Information Assurance policy approved and published by year end
•    Information Security Program approved and published by year end
•    Consultant budget approved by EQ02
________________________________________

Figure 19: Sample project assumptions.
________________________________________
Key Financial Metrics
•    Availability—$250k annual cost avoidance relating to lost intellectual property through access control
•    Productivity—$150k annual productivity increase across company (IT & Business) through better secured access control
•    Control—$300k annual cost avoidance for asset loss
________________________________________

Figure 20: Sample project and policy metrics.
________________________________________
Recommendation
•    Develop information security topics for policy architecture
•    Use internal resources where possible
•    Limit the use of external consultants to save costs
•    Develop an awareness program
________________________________________

Figure 21: Sample recommendations.
These balloons provide the executive summary and business case to move forward with building an information security policy architecture.
7.4 Document Approval
To be ready for the approvals, you need to have that 60-second elevator speech ready and be ready to respond to any type of question that may be asked. Consider the following when a 60-second elevator speech is being developed.
•    Believe in yourself and the mission. Go in thinking success. This is a given and this is a gentle reminder to yourself.
•    Never give up. You do not know what you can achieve. Many times, the first answer is “no” or a conditional yes with caveats.
•    Have a strategy before; meeting with anyone. You know the direction you want the enterprise to take, ensure you also understand the business.
•    Know the sound bites—important, high-risk, business-related. Read the trade rags to know the risk, threat, compliance, privacy, and security headlines, especially if there are ones for your industry.
•    Know who, what, where, when, why, how. Being able to answer these six questions will lessen the questions and potential resistance to implementation.
•    Be flexible and adaptable. There is no such thing as totally secure and zero risk. Ensure that there are options to present to the enterprise. What is the level of risk acceptance?
What approvals do you need for what levels of documents within the enterprise? First, you need to determine the information security policy architecture document levels before you can determine who needs to approve them. The levels within an enterprise for the information security policy architecture document could be as follows:
•    Enterprise
•    Country
o    Location
o    Site
•    Business unit
•    Technology
The level of the document will be determined by the document scope and the roles and responsibilities. As mentioned previously, the information security policy architecture document levels are policy, guideline, standard, work instruction, memos, and forms. Then the information security team needs to determine the highest position in authority for the area for approval and enforcement. With this determination, the information security policy architecture approval matrix can be developed. See Table 10 for a simple approval matrix sample for an information security policy architecture.
Table 10: Approval Matrix
Open table as spreadsheetDocument Type[a]
Dept.Mgr.[b]
Dept.VP[b]
Highest Site Position    CIO[c]
CSO[d]
CFO[e]
COO[f]
CEO[g]
Counsel/HR    Board of Directors
Enterprise Policy                   X    X    X    X    X    X    Awareness
Enterprise Guideline                   X    X    X    X    X    X    Awareness
Enterprise Standard                   X    X    X    X    X    X    Awareness
Enterprise Work Instruction    X              X    X         X         Awareness    Awareness
Enterprise Memo                             X         X    X    Awareness
Enterprise Form    X              X    X         X
Location Policy              X    X              X
Location Guideline              X    X              X
Location Standard              X    X              X
Location Work Instruction    X
Location Memo              X
Location Form    X
Business Unit Policy         X    X    X    X         X
Business Unit Guideline         X
Business Unit Standard         X
Business Unit Work Instruction    X
Business Unit Memo         X
Business Unit Form    X
Technology Policy    X    X         X
Technology Guideline    X    X         X
Technology Standard    X    X         X
Technology Work Instruction    X
Technology Memo         X         X
Technology Form    X
[a]The document type approval is dependent on the topic of the document for the additional approvals.
[b]This could be the information security person, if the document is related to information security.
[c]Chief Information Officer or the highest position level that leads information technology or the technology of the enterprise.
[d]Chief Security Officer or the highest position level that leads the enterprise security.
[e]Chief Financial Officer.
[f]Chief Operating Officer or the highest position level that leads the operations portion of the business.
[g]Chief Executive Officer or highest level in the enterprise.Match the titles within the sample approval matrix to the highest level possible within the enterprise that can promote and endorse the information security policy architecture. For example, if the highest security level position is a Director reporting to the Chief Information Officer, then the Chief Information Officer should be the initial level to sign off on the policy architecture document and then move higher up the enterprise organization chart.
After the approval matrix has been developed, the information security team can start a marketing campaign to get the signature approvals. If you have been in an enterprise for a while, you should be able to determine the best communication method for the executive team. With all the electronic communication methods available, many executive teams prefer the electronic communication method for review over a face to face meeting. You will need to ensure that the executive approval team understands that protecting enterprise assets and meeting business requirements is the fundamental reason for the information security policy architecture. As the author for the information security policy architecture information, you need to meet face to face with each of the executives for signatures and final approval. This meeting with the executives will allow the executives to ask any last minute questions or voice any concerns. A video conference will also work when a true face-to-face meeting cannot be set or the executives are in various locations.

7.5 Support
Let us dispel some myths about getting information security support from the enterprise.
1.    Executives only care about their company. Executives and management have goals and objectives to support and expand the enterprises market share or to produce new products. With either goal, the executives need to keep in mind protecting the enterprise assets in order to make that bottom line.
2.    Stories and anecdotes waste time. When someone lectures and reads the slides, do you remember? Or do you remember better when someone tells an incident or story that relates to the topics on the slides, especially if the incident had severe consequences or wonderful outcomes?
3.    Executives only want the numbers. The almighty dollar, the dashboards, and the scorecards play an important role in the progress of meeting a goal and objective. Within information security there is also an attitude and awareness toward asset protection, which cannot have a number put on it.
4.    Executives hate auditors. Auditors are our friends. Auditors can bring good and bad news. It is when auditors bring news of issues and noncompliance that executives have issues with the enterprise and business unit methods and not the auditors themselves.
5.    Executives want a return on investment (ROI). Within information security, this is return on security investment (ROSI). If asset protection is integrated into every process and into everyone’s daily job, the concern over ROSI goes away and the ROI across the enterprise goes up. If information security is only considered an insurance policy for the enterprise, then the message of integrating confidentiality, integrity, and availability is not being promoted to the benefit of the enterprise.
Paul Revere was the messenger of the revolution and the famous saying “the British are coming out!” That message is really not too far off from today’s compliance with the copious regulations. Why was Paul Revere such a good communicator? He had a specific message that needed to be spread about the risk that was entering the environment. Community lives were in jeopardy because an external force was going to invade. He ran into British road blocks and through various communication skills either talked his way through the road blocks or ran them. At the one road block where he was interrogated by British Officers, Paul Revere stated what his mission was by telling the British Officers more than they knew about their mission. Risky? Yes. In the end, the British talked among themselves, released the prisoners and began a slow retreat. What limited that threat? Telling the British they were going to run into resistance in their take-over. And the British decided the invasion was not worth the risk. Paul Revere’s warning to the communities allowed them to prepare (and add controls) to limit the risk of the invasion. As information security professionals, we need to take the lead from Paul Revere in spreading the message about business risk and ways to mitigate that risk. We need to know our own strengths and weaknesses and increase our influence within the enterprise. We can increase our influence understanding by the following:
•    Being a central role in the enterprise. This does not mean the center of the enterprise’s attention. This does mean active participation in projects and activities within the enterprise.
•    Skill substitutability. Yes, you are an informa