Business, IT, and Security Alignment

The security of any organization or enterprise rests totally on the strategic planning and tactical implementation of security policies and risk mitigation controls. The security plan of the organization should completely coincide with the mission, objectives, culture, and nature of the business. Various security frameworks exist to guide the organization as well as the security professionals responsible for implementing programs through the planning, organization, and documentation that respond to the requirements of the organization. The most popular frameworks include the National Institute of Standards and Technology (NIST) 800 series of Special Publications. These NIST publications offer a broad coverage of IT security best practices. Another of the most popular frameworks is the ISO/IEC 27000 series of information security standards.

An information security management system (ISMS) consists of the set of policies designed to reduce or mitigate risks to the organization. It promotes the principle that an organization should create, implement, and maintain a complete set of security policies, processes, and systems to manage risks to both hardware and information assets.

The framework initially was published in the United Kingdom as BS 7799 in the mid '90s. By 2000 it was adopted by the International Organization for Standardization (ISO) and retitled ISO/IEC 17799. In 2005, the standard was incorporated into the ISO 27000 standards series as ISO/IEC 27002. It is common to place the date of revision after the standard number. The most recent revision is ISO/IEC 27002:2013. The standard is explicitly concerned with information security, meaning the security of all forms of information. There are several information security standards published in the ISO/IEC 27000 series. The two most popular are as follows:

1. ISO 27001:2013 ISO 27001:2013 is a specification for the evaluation of the performance of an information security management system (ISMS). Organizations that meet the standard may gain an official certification issued by an independent and accredited certification body on successful completion of a formal audit process.
2. ISO 27002:2013 Provides organizational information security standards and information security management practices which takes into consideration the organization's information risk appetite. These guidelines include the selection, implementation, and management of risk mitigation controls. ISO/IEC 27002:2013 is a popular, internationally recognized standard of good practice for information security.

Both ISO 27001:2013 and ISO 27002:2013 have been completely rewritten since the 2005 edition. While ISO 27001:2005 specified Deming's Plan-Do-Check-Act cycle, in ISO 27001:2013 other continuous improvement processes such as Six Sigma's DMAIC (Define, Measure, Analyze, Improve, and Control) may be implemented.

Best Practices

A best practice is an accepted methodology of performing an action that leads to a beneficial result. In many situations, the best practice has developed, over a period of time, through trial and error. Businesses utilize best practices in the form of frameworks, templates, or guidelines. Various methodology frameworks such as Information Technology Infrastructure Library ITIL, Six Sigma, agile project management, and the Scrum agile software development framework are readily adopted by businesses. Practice distribution has been made possible generally through the commercialization of the topic and the proliferation of books, courses, and certifications.

Organizations such as the National Institute of Standards and Technology (NIST), the International Organization for Standardization (ISO), and the International Electrotechnical Commission (IEC) work with industry groups as well as governments to develop and publish frameworks of best practices. Once a framework becomes generally well accepted, it will be adopted as an industry standard. A typical best practice recommendation for information security management is the ISO/IEC 27002:2013. Quite often best practices and industry-recognized frameworks become the foundation for corporate policies.

Corporate Policies

A corporate policy is a written document that states high-level goals and directives as established by corporate top management. Corporate policies take the form of a brief statement by corporate top management and provide authorization, intent, and direction. They generally include all of the major areas of the enterprise, such as accounting, legal, human resources, ethics, and regulatory compliance to name a few.

Corporate policies are generally created as a response to various requirements.

1. Legislative and Regulatory Compliance Most corporations are required to comply with a variety of legislative or regulatory mandates. Legislative restrictions are in the form of laws passed by a government body. A regulation is generally issued by government department or a recognized regulatory body such as a trade association. Failure to comply with legislative or regulatory mandates may result in fines, sanctions, or even criminal prosecution.
2. Contractual Requirement Every enterprise enters into a wide variety of contracts with suppliers, customers, service providers, and partnering organizations. These policies state the intent and direction of top management in relation to the management of a contract or relationship.

Security Policies

The corporate security policy is a statement authorized by top management that defines the overall security for the organization and protection of corporate assets. Chief among ­corporate assets is information. Therefore, many security policies are referred to as IT security policies because information is contained on computers, servers, and storage devices.

The IT security policy may be viewed as an umbrella policy that encompasses a number of subpolicies or supporting policies that address various activities or risk categories. These subpolicies generally cover areas such as information access, use and disclosure, destruction, and classification as well as physical security, ethics, and various activities associated with the IT infrastructure. Figure 4.1 illustrates the relationship between general corporate policies, the IT security policy, and various subpolicies.

For instance, the enterprise security policy may broadly state that all information system users are required to use a password as an authentication mechanism. The password policy would then specify such details as the structure of a password, password expiration and renewal, re-issuance of a forgotten password, and any other details specific to passwords.

Types of Security Policies

There are different categories of security policies depending upon the structure and requirements of the organization. There are three general types of security policies that together meet the requirements of the overall enterprise security program:

1. Organizational Policies An organizational policy is established by a person or group with a high level of authority, such as a senior manager or corporate office, and it's usually very broad in nature, impacting the entire organization, corporate division, geographic area, or a country-specific working group. For example, an organizational policy may be created for the XYZ Corporation, the XYZ Corporation Omaha Engine Manufacturing Division, or the XYZ Corporation Asia – Pacific Region.

   The same organizational policy may exist for all three entities, with the difference being the scope of the policy in relation to the requirements of the entity. For instance, an organizational policy reflecting the requirement for personal privacy for European operations will have different standards, regulations, and legislation to comply with than one for the Omaha division within the United States. Organizational policy should be clear regarding the specific entity or geography of the intended audience. It should include specific statements about the geography, facilities, hardware, software, data storage, and personnel within the scope of the policy. This is very important in the case of a cloud data storage policy, for example.

   The organizational policy may generally state that customer data may be placed in cloud storage. Unfortunately, the organization may find that the cloud storage facilities are based in a country that does not allow search and seizure of the data during a forensics investigation. Therefore, the organization must carefully consider and clearly define the requirements when creating a general organizational policy.

2. Functional Policies Functional policies address specific issues or concerns of the organization. They may be used to define requirements related to particular areas of security, such as access control, acceptable use, change management requirements, hardware and software updates, and other operational concerns. An example of a functional policy is a Bring Your Own Device (BYOD) policy. It may state that corporate employees may use their own wireless device to access the organization's network and data based upon certain criteria. The functional policy will list the criteria that must be met prior to an individual being allowed access. The criteria may include the requirement of current updates on the system, the use of anti-malware and virus protection, the restriction of different types of data that may be uploaded or downloaded, the requirement for device security, the ability to remote wipe the device in case of theft or loss, and many other requirements that are relevant to the use of personal wireless devices.

   Similar to organizational policies, functional policies may include the entire organization, corporate division, geographic area, or country-specific working group within the scope of the policy. An example of the corporate division functional policy might be that personal access to all manufacturing facility workspaces at the XYZ Corporation Omaha Engine Manufacturing Division will require two-factor authentication.

3. Operational Policies Operational policies, sometimes referred to as system-specific ­policies, are used to clarify and provide a clear direction on operational topics such as access to specific database information, application software, or networking facilities. An operational policy may state the requirement that a specific action, such as access to an accounts payable application function, requires separation of duties. Another operational policy may state that all accounting personnel workstations will be assigned to a specific virtual network.

The more detailed or granular a policy, the more frequently the policy may be required to be updated or changed. Organizational policies are usually very broad in scope, while an operational policy defines a specific operational requirement or action. For instance, an organizational policy may require that all individuals utilize two-factor authentication for facility access. This is a general statement that applies to all the individuals in the organization. The specific supporting operational policy may state that the XYZ2314 retinal scanner be used as the second factor for authentication at the New Mexico Laboratory Annex. While the organizational policy is long term, spanning many years, the XYZ2314 retinal scanner may be replaced within a year or two, requiring an operational policy and procedural policy change.

Security Policy Endorsement

Although corporate policies may be authored by knowledgeable individuals within the organization or may be adopted from a variety of best practices, policy templates, or frameworks, it is of paramount importance that the top management of the organization support, approve, and endorse the security policy. The security policy should reflect and support the mission and goals of the enterprise. The endorsement by top management provides an authoritative document that authorizes the adoption and implementation of various controls by which to mitigate risk to the organization's assets. The security policy clearly states the direction and goals of top management and reflects the culture, goals, and mission of the organization.

Support and Execution of Security Policies

As you have seen, the corporate security policy is generally broad in nature and makes a single statement. It does not go into detail concerning the “how” and, specifically, the “who” of any aspect of the policy. In the example of the corporate password security policy, the mandate statement was very general. On the specific password policy, more detail was added as to the length of time, identity verification, and other password requirements. This password policy detail is supported by a policy statement, standards, baselines, procedures, and guidelines.

The components of a policy and supporting documents are as follows:

1. Policy Statement A policy statement is a high-level directive setting forth a mandate in support of the mission goals and objectives of the organization. For example, XYZ Corporation will comply with the Payment Card Industry Data Security Standard (PCI DSS).
2. Standards Standards represent the criteria that must be met by the policy. Standards may be imposed by legislation, regulation, or industry requirements, or they may be imposed by the organization. For instance, the Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle branded credit cards. The PCI DSS standard is mandated by the card brands and specifies various compliance requirements. The corporate PCI DSS security policy would list the six requirements as established by the Payment Card Industry Security Standards Council.
3. Baselines A baseline may be established as the normal or minimal criteria that must be met by the policy. Baselines may list a specific configuration setting for a piece of hardware, such as a firewall, an IDS, or a router. Such a baseline configuration may require that various rules be included in every router. Baselines are used to ensure that the standard minimal or optimal foundation configuration exists for the consistent implementation of the availability, integrity, and confidentiality of information throughout the organization.

   Each piece of hardware or software has optimal settings that allow for the most secure implementation. A baseline states a specific configuration criteria required for the hardware or software to meet the functional or organizational policy statement. For example, an organizational policy may state that every user workstation be protected by antivirus software. The functional policy may state that ABC antivirus software be implemented on all user workstations. And a baseline may state that the ABC antivirus software be configured to automatically update on a daily basis using the ABC Professional Signature database. It is also important that configurations be regularly evaluated or audited to ensure that they meet the baseline minimum requirement.

4. Procedures Procedures are detailed steps that provide a set of instructions for performing a specific task. Some companies, and specifically government/military organizations, might have what is called a standard operating procedure (SOP). Procedures define not only the steps to take but other specific information.
   1. Instructions The chronological steps that the individual must do to complete or finish a task.
   2. What The device or tools that should be used and a source of materials specific to the task. This may also describe what reports or logs must be completed when a procedure is finished.
   3. When How often or what time of day should the procedure be undertaken.
   4. Where Where to find the device, the tools, or the information required by the procedure.
   5. Who The person responsible for carrying out the procedure. This may also specify who is responsible to inspect or double-check the quality of the work.
5. Guidelines Guidelines differ from procedures in that they are generally considered optional and may take the form of a suggested practice. Guidelines generally allow the individual to make a discretionary judgment on how to proceed when executing procedural steps. Many guidelines originate from recommendations and best practices and are usually created through trial and error. For instance, a guideline may state, “To avoid skin contact, wear rubber gloves when applying solvent.”

   It is not uncommon that over time guidelines become accepted practice throughout an organization or industry and are integrated into a procedure as a requirement. Many of today's policies and procedures originated as guidelines.

Figure 4.2 illustrates the hierarchy from general corporate policies to guidelines, including standards, baselines, and procedures.

Security Development Life Cycle

A security practitioner may be involved in the development of software or applications. It is important that security personnel be involved at the beginning and as a stakeholder in every development project.

The Security Development Lifecycle (SDL) is a software development process proposed by Microsoft to reduce software maintenance costs and increase the reliability and security of software. The Security Development Lifecycle incorporates all of the activities to ensure compliance with both operational and security requirements as specified by organizational policy. Security requirements and the inclusion of security controls should be present at the beginning of the development project.

Automated Configuration Management

The security practitioner may be required to manage the configuration files on a variety of network equipment. Configuration management is critical to the success of the IT organization. Various IT devices, including servers, switches, routers, and IDSs as well as other networking items, require configuration and system updates on a regular basis. The larger the organization, the more difficult this task becomes.

While it is always possible to update and configure items manually, many organizations have adopted automated configuration management. Automated configuration management provides a centralized method to make changes to a system in an organized manner.

Configuration management is the application of tools that allow for the centralized management of settings, firewall rules, and configuration files that allow networking items to perform their assigned tasks.

The task of configuration management may be broken down into a number of activities. The security practitioner may be responsible for any or all of these configuration management tasks.

1. Identification Configuration identification is the process of setting and maintaining operational baselines that define the system status at any point in time. Identification is similar to snapshots, in which the specific parameters of the system are available. An example includes restore points on Microsoft Windows operating systems. A restore point represents a specific configuration at a point in time.
2. Control Control represents any action concerning change requests and change proposals and their subsequent approval or disapproval. Control may be thought of as a function of the change control process. Various devices may be automatically patched or updated on a regular basis without submitting a change request, while other devices must proceed through a change proposal.
3. Accounting Accounting is the process of logging and reporting any change to configuration.
4. Auditing Auditing is verification that a process has been completed according to policy or plan. It may also verify that the product is in compliance with established performance requirements.

Patch Management

Applying relevant patches, updates, and fixes may be the responsibility of the security practitioner. Patching devices may be automated or manual in nature and are always procedural based. This means that a procedure exists such as taking an item offline, placing it in administrator mode, connecting a console, and completing many other required steps to update the software contained on the device. Although the word patch is frequently used to describe an update or change in a software device, there are many other terms associated with this activity.

1. Patch A patch is a piece of software intended to update an application, operating system, or control program to improve its usability and performance. A patch may be broad in nature and fix or repair various problems identified within the software. Patch Tuesday is an industry term referring to when Microsoft regularly releases patches for its software products. Usually on the second and fourth Tuesday of each month at a specific time of the day, patches are made available for manual or automatic download. Other major manufacturers, such as SAP and Adobe Systems, have announced their Security Patch Day to coincide and occur on Patch Tuesday.
2. Security Patch A security patch is a specific update to an application, operating system, or control program in response to the identification of a vulnerability. Many manufacturers attempt to distribute security patches as soon as they are tested and available. In some cases, a manufacturer is unaware of a vulnerability and therefore does not have a patch available. An exploit of a vulnerability for which the manufacturer is unaware is referred to as a zero-day attack. The term zero day indicates that this is the first time the vulnerability has been identified. Microsoft generally releases security patches once a month, and other manufacturers release security patches as soon after a vulnerability identification as possible.
3. Unofficial Patch Unofficial patches are patches provided by third-party individuals or organizations for commercial software. These patches are usually sold by subscription and either fix problems earlier than the manufacturer can release a patch or patch products that are no longer supported by a manufacturer.
4. Hot Patch A hot patch is a patch that can be applied to piece of hardware or software without the requirement to power down or reboot the product, thus making it unavailable to users. This type of patch addresses the availability component of the CIA triad.
5. Service Pack A service pack is made up of a number of updates, enhancements, fixes, or patches that are delivered by the manufacturer in the form of a single executable file. The executable file will cause the service pack to be installed on the target machine. Service packs are usually numbered and are released on a random basis when a sufficient number of patches and updates have accumulated. Most service packs are cumulative in nature, meaning patches and updates from a previous service pack are incorporated in the current service pack to ensure that all changes are made adequately. Service packs for application software generally replace the existing files with updated software. During this process, the application software may receive a new version number.
6. Update, Upgrade Update and upgrade are industry slang used to describe the installation of any software that either fixes a vulnerability or increases the usability or functionality of the product.
7. Fix, Quick Fix A fix has become known in the software industry as a rapid repair to an identified problem. In many cases, the fix is related to a very specific problem or possibly a specific user of the software. A hastily released fix that has not been properly tested may raise the risk of possible regressions. A regression is when a fix for a current problem creates problems in prior versions of the product. Testing a fix to address this problem is called regression testing.
8. Hotfix Similar to a hot patch, a hotfix may be applied to a piece of hardware or software that is currently online and in use. Hotfixes have become known in the software industry as providing the ability to fix a bug very rapidly and possibly without going through formal development channels.

Version Numbering

Software version numbering is a method of assigning alphanumeric or numbers to designate the generation or “build” of a software or firmware product. The numbers or alphanumeric designations are generally assigned in increasing order to correspond to changes and developments and new releases of the software product.

Most versioning schemes feature three- to four-digit identifiers and are used to convey the importance or significance between changes. Different manufacturers and producers of software make use of the designations differently. For instance, the designation 2.1.3.4 may indicate that this is the fourth revision (4) of the documentation and the third revision (3) of minor changes. It may also indicate this is the first revision (1) indicating a major change since the last general release. Some manufacturers jump sequence numbers to indicate the importance of an upgrade or software revision change. For instance, Internet Explorer 6 went from 6.1 to 6.5.

The primary version number (2) indicates a new software release with a major functionality change. When manufacturers change the primary version number, it may indicate a substantial change in functionality, usability, or feature set. It may also denote an incompatibility with prior versions. When changing the primary version number, many manufacturers use this opportunity to resell the subscription to the software.

Sandbox Testing

It is an industry best practice to thoroughly test any patch, fix, update, or service pack in a nonproduction environment. Sandbox refers to a machine or virtual network that is totally isolated from the production environment. Problems experienced during testing within a sandbox cannot escape to the production network. It is never a good idea to distribute patches, fixes, or even service packs without first testing them in an offline environment.

Implementation and Release Management

Release management is part of the software development process, which can be a constantly evolving process or an ongoing cycle of development, testing, and release. Software applications are created, modified, or updated on a regular basis. As part of the process, they are tested and evaluated by both IT quality testing teams and end-user testing teams. Each team is challenged with testing the software to specific design parameters, usually as outlined in the business requirements document (BRD). The IT quality team is charged with testing the automation of the software and how it interacts with databases, storage devices, and other pieces of software, sometimes referred to as quality acceptance testing (QAT), while the user team is testing the software against specific scenarios or business cases, usually referred to as user acceptance testing (UAT).

Once the software is completed and passes the testing environment, it is made ready for deployment. Software deployment is a series of steps in which the new software is loaded on a server and distributed to the appropriate user workstations. In some deployment situations, the software remains on the server and is available for end-user logon.

1. Software Release Activities The security practitioner may be responsible for one or more activities during the software release process.
   1. Facilitate Communication Serves as a liaison between the business units and the IT department to ensure proper communication during the release process.
   2. Release Coordinator Communicates issues, problems, and concerns and coordinates the services of the help desk group to facilitate software deployment.
2. Software Release Challenges A software release is not without its own unique challenges. The security practitioner may be involved in communicating or assisting in solving some of the challenges and problems facing the release, including these:
   • End-user issues
   • Reporting of software defects
   • Change requests
   • End-user orientation and training
   • Defect reporting
   • Incident handling
   • Identification of risks

Software release can be an ongoing, multifaceted project involving dozens of individuals. In the past, new software releases and updates were made available only upon the completion of particular project. This project methodology is referred to as the waterfall development process, where one step leads to the next until the project is eventually completed and distributed to the end users. Software development organizations today utilize an agile development process in which items are developed very quickly, tested, and made available. The agile development process has greatly increased the number of possible software releases due to the rapid ability to create or modify software, correct mistakes, and reissue the software.

Change Management

Change management is specifically an IT process in which the objective is to ensure that the methods and procedures for change are standardized and are used for efficient and prompt response to all change requests. Change management is a system that records a request, processes requests, elicits a denial or authorization, and records the outcome of the change to a configuration item.

Changes requiring specific approval may be forwarded to a change control board (CCB) or change advisory board (CAB) consisting of various authoritative and qualified individuals within the organization who review and approve or deny changes.

Change management is responsible for managing change processes involving the following:

• Network infrastructure
• Specific networking components
• Application software
• Database structure
• Communications processes
• Change and release processes
• Network component modification or upgrades

Asset Management

Asset management broadly defines the identification, maintenance, and risk protection of hardware or information assets. The very first step of risk management is identifying the assets that require protection. The security practitioner may be involved in cataloging, maintaining, or decommissioning various organizational assets.

Assets are generally grouped into two specific classes: physical assets, which are also called tangible assets, and nonphysical assets, which are also called intangible assets. It may be obvious that tangible assets are IT infrastructure hardware components, while intangible assets are data, information, and intellectual property.

Asset Life Cycle

As a security practitioner, you may be involved in providing some service at any point along the asset life cycle. The asset life cycle includes the following steps:

• Design
• Construction
• Commissioning
• Operating
• Maintaining
• Repairing, modifying, replacing
• Decommissioning
• Disposal

Validate Security Controls

The IT environment is constantly changing along with the threats to the organization. IT departments should regularly test security and compliance controls to ensure that they remain both effective and within the scope of the required operational guidelines. The reason security controls require validation is to maintain compliance established by various regulations, such as, for example, FISMA/NIST, PCI DSS, and HIPAA.

It may be the responsibility of the security practitioner to assess, verify, and document the correct operational state of a security control based upon established baselines. During this process, the practitioner accomplishes a number of procedures that may include validation of current updates and patches, validation of correct configuration, and review of logs and documentation.

Data Classification Process

Data classification strategies differ greatly from one organization to the next because each generates different types and volumes of data. The balance may vary greatly from one user to the next between office documents, email correspondence, images, video files, customer and product information, and financial or intellectual property data. Many companies begin to classify data in line with their confidentiality requirements, adding more security for increasingly confidential data. The classification system itself must include an element of centralized control so that data is classified in the context of overall strategic business objectives, such as compliance.

Various tools, software, and methodology exist to assist an organization in the data classification process. Generally, organizations opt to classify the most sensitive information first and work down to publicly available information.

Marking, Labeling, and Storage

An organization establishing a data classification policy must also include information concerning the marking, labeling, and storage of classified information. Sensitive information must be adequately identified both physically (by the marking on containers and storage devices) and digitally so that it can be recognized by trusted computer systems. The data classification policy should also include the access control provisions for both current information and information in long-term storage. Some information must be maintained in storage off-site for many years. Some regulations require that sensitive information be retained 7 years and some as much as 10 years. In the case of criminal evidence data, the information must be kept indefinitely. Consideration should also be given to the encryption methodology for long-term storage of data at rest. Currently, the AES encryption algorithm is used for long-term data storage.

Data Declassification

Records management is an expensive undertaking for any organization. The continued maintenance of classified information, including storage and access, should be considered in any data retention or data classification program. Many government agencies and other organizations have responded by developing an open data program. An open data program is an attempt to review information and declassify it according to various criteria. Some information that has been gathered may not be declassified. For instance, the Privacy Act of 1974, 5 U.S.C. § 552a, Public Law No. 93-579, established a Code of Fair Information Practice that governs the collection, maintenance, use, and dissemination of personally identifiable information about individuals that is maintained in systems of records by federal agencies. Other regulations, including HIPAA, restrict declassification or dissemination of private client or patient information.

It is suggested that a declassification scheme and methodology be included in any classification policy.

Training Users

Training corporate employees on the subject of security is extremely important. It may be required under the corporate security policy, and in some cases it may be a compliance item under a governmental or industry regulation. It is important for the SSCP to understand various aspects of training because you may very well be involved in either the development or the delivery of security training topics.

1. Focus End users can potentially cause a greater loss of information and system assets than all other types of threats. It is imperative that users of the organizations systems be well educated about security threats such as social engineering. Users should be given information to help them make good decisions regarding their use of the systems in their daily activities. User training must also include proper use of personal devices such as cell phones, tablets, and laptops.
2. Level of Information User training should consist of basics facts about information systems security as it applies to the environment in which they work. It should include all of the best practices, including how they should exercise the use of proper passwords, how to avoid giving information over the phone, and how to report suspicious activity. User training programs should also concentrate on how to protect corporate data and workstations. They should be aware of threats and vulnerabilities and the risks to their information in their systems.

   Specialized training should be provided to any end users handling sensitive or confidential information. This may include individuals with access to customer databases, accounting records, or client information. Individuals should also receive specialized security training in compliance-based areas such as HIPAA medical information regulations and patient information privacy.

3. Delivery Method Instructor-based training is usually preferred by many organizations. Classroom training promotes direct contact and the ability to perform various interactions such as role-playing or scenario-based activities between individuals. Care must be taken in the selection and training of the instructor so that adequate emphasis is placed upon the correct content. Computer-based training (CBT) may be used to complement instructor-based training because it may be available as training on demand, with incremental modules.
4. Training Frequency User training should be delivered at a minimum upon new hire and at least on an annual basis thereafter. It is important to support the training on a daily or weekly basis with pop-up banners, email reminders, webinars, and posters.

Training Management

Corporate security training may be tailored to other employees at different ranks within the organization. It's important to recognize the information requirements and perspectives of these individuals in order to make the best use of time and provide for the greatest impact and absorption of the information.

1. Focus The focus of management training is protecting the assets of the company while creating efficiencies and productivity throughout the organization. Those in management individuals are interested in cost and time. Management training should concentrate on the consequences involved in not maintaining an adequate security posture. Promoting end-user security should be a job-related task placed on every manager.
2. Level of Informatio Managers, by nature, tend to be concise and bottom-line oriented. They want to know the security requirements of the organization, the funding required, and the results expected. In essence, they require a business case to be made for organizational security. Managers need to understand their responsibilities and how to make security work within their organization including the impact if security fails.
3. Delivery Method Manager training is quite different than end-user training. Management training programs should communicate corporate policies with regard to the security of the organization. This type of training session may also provide managers with a train-the-trainer program as well as handouts and materials for their departmental meetings. The managers of the company are primarily concerned with the functions of their business unit. In most organizations, they are conduits of information from higher management down to their staff. Therefore, you may use the following briefing method of communicating security programs to managers.
   1. Briefing Paper A short summary of the security programs is outlined. A briefing paper specifically states the purpose and actions required in implementing security programs for their unit of responsibility.
   2. Formal Briefing The formal briefing is where the overall program is discussed, including the current status of the system security manager's responsibilities, actions, and activities.
   3. Reminder Memo This is a follow-up, a written memo or email that highlights the first and second steps and reminds them of their responsibility.
4. Training Frequency Once a year is often enough for manager training, but managers are also users, and it is recommended that they attend user training as well.

Training Executives

Making a presentation on security topics to the senior executives within an organization is a skill that requires understanding both the time available and the amount of information to present. This level of corporate employee requires a high-level presentation that is quite different from end-user corporate security training.

1. Focus The success of the company and the protection of business assets is the role of the senior executives of the organization. They are responsible to shareholders and investors for the success of the company. The training focus for executives should be to provide them with enough information to allow them to make quality decisions based upon factual data that will benefit the organization.
2. Level of Information At a general level, corporate executives should be made aware of security policies. They should also be informed of general risks to the organization and how they are being mitigated through various programs. Executives realize their responsibilities under legislation, rules, and regulations and the impact that compliance has on the organization. It is also important to include a briefing on the protection of high-level confidential information because many high-level corporate executives are the focus of whaling attacks, spoofing, social networking, and other attacks due to their position and inside knowledge of the organization.
3. Delivery Method Short written briefs of one or two pages are the optimal communication method with high-level executives. If the presentation is longer, it will generally not be read.
4. Training Frequency Deliver training as requested or required. Top executives have skill levels that allow them to assimilate information very quickly. It is important to summarize information and be prepared to follow the summary with in-depth supporting information.

Business Impact Analysis

A business impact analysis (BIA) is the first step in creating a business continuity plan. Similar to risk analysis, where all assets are identified and possible threats categorized, the business impact analysis seeks to determine and rank activities and functions that are absolutely required by the operation and without which the operation would cease to exist. The business impact analysis evaluates the financial impact on the organization from a quantitative and qualitative viewpoint.

For example, a warehouse and shipping facility suffered $500,000 in damage during a hurricane. Prior to the damage, the facility was shipping $70,000 worth of products per day. It is estimated that the facility will be down for five days. The quantitative financial impact might be calculated at $350,000 in lost shipping revenue plus $500,000 to restore the warehouse to full operation. The qualitative financial impact is a less precise figure based upon business that had been turned away, customers that will leave and never come back, and bad publicity or reputation in the marketplace and other considerations.

During a business analysis, all of the major activities of the organization are listed and categorized as to their importance or how critical they are to the continued existence of the organization. Every business organization has basic revenue-driving operations and support functions. The BIA seeks to differentiate critical operations from support operations and specify a time frame during which the business can survive without the critical operations. Differing from a risk analysis where potential threats are examined, a business impact analysis considers the impact to the business if the business function ceased operation for whatever reason.

Various steps must be undertaken during the creation of a business impact analysis:

1. Locate and determine all business processes It may seem easy to identify simple business processes. A list of departments such as sales, marketing, manufacturing, accounting, IT, customer service, and a few other major groups may be enough. But this process becomes much more complex than a larger organization. Although major departments and workgroups have been identified, what would happen if a localized fire took out the valuable customer database of a small four-person work group?

   The list of all the business processes is usually created by contacting senior personnel, department heads, managers, and knowledgeable individuals within the organization. This listing of processes will form the basis of creating an entire picture of the organization.

2. Determine how critical a process is to the business The next task is to determine how critical a process is to the business. This may be accomplished through interviews, polls, questionnaires, and other devices used to solicit opinions and information from across the organization. Reconciling of this information is never an easy chore. It may be found that according to the perspective of the individuals polled, their department or business process may be indispensable. Therefore, a ranking system should be devised along with the decision process to determine the critical nature of each business process.
3. Determine how long the business can survive without a particular process Once business processes are ranked in order of importance, now comes the task of determining how the business can survive without a particular process. This computation may be undertaken with the assistance of knowledgeable individuals within the organization, such as stakeholders, department heads, and managers.
4. Downtime impact timelines Various terminology may be employed to describe the timeline when a critical operation is down or offline (Figure 4.4). The times can be measured in minutes, days, or weeks and can be determined by both qualitative (numerically based) and quantitative (subjectively based) methods. Usually the correct answer is a combination of both techniques.

   

5. Maximum Tolerable Downtime (MTD) The maximum tolerable downtime is an estimate of the maximum time the business process may be down or offline before the organization becomes unable to recover. For instance, if a business warehouse sustains a catastrophic fire and cannot adequately function for a period of 90 days, it may be assumed or a fact that all of the current customers have migrated to other suppliers and that the business can no longer operate.
6. Recovery Time Objective (RTO) The recovery time objective may be stated as the estimated time by which the affected process will be restored. For instance, a fire in a warehouse has destroyed the communications closet containing five servers. All data processing functions to that warehouse are no longer available. The recovery time objective is stated as 14 days to replace equipment, rewire the building, and bring the servers to full operation. The important point to remember is that the RTO must always be less than the MTD. If it is ever longer, the business will fail.
7. Recovery Point Objective (RPO) The recovery point objective acknowledges that during any disaster, records and data may be lost. It is necessary to determine at what point known good records could be restored, after which reliable data and information will not be available. A recovery point objective is directly related to data retention, data storage, and backup methodology employed by the organization. For instance, if daily data is backed up at midnight each night, the recovery point objective will be the prior midnight. Many businesses utilize immediate offsite storage such as cloud storage or another related facility. When this is the case, data can be recovered almost up to the point of disruption, so the recovery point objective is virtually at the point of service interruption.

Figure 4.5 illustrates the relationship between the recovery point objective and the recovery time objective. The recovery point objective indicates the last known good data safely backed up and not affected by the disaster. The recovery time objective is the amount of time required to restore the data from the backup archives.

The concepts of maximum tolerable downtime, recovery point objective, and recovery time objective may be applied to every critical activity identified as a priority to the organization. Although the recovery point objective in the previous example refers to the restoration of data using backup files, it may also apply to physical or operational assets. For instance, a recovery point in a customer service office may be established as the point at which customer service agents are able to resume operations by answering telephones and resolving client issues. When planning a physical or operational recovery point objective, it is important to consider alternate or temporary recovery programs. For instance, the customer service department may be brought back to minimal operational status in an alternate location with telephone service using temporary tables, paper records, and written forms while the normal facility, communications equipment, and computer service is being restored.

Disaster Recovery Strategy

Various items and components of the IT infrastructure require different strategies. For instance, should a disaster event occur, there is a significant difference between restoring a server with previously backed-up information and totally replacing server racks and damaged cables and restoring communication equipment. The recovery strategy should include plans and procedures for the restoration or replacement of various components of the IT infrastructure. These plans should include the following sections:

• Assessing the damage and determining what needs to be replaced
• Placing orders for replacement goods or services
• Receiving, installing, and configuring replacement goods
• Loading and testing applications and data
• Certification and accreditation of IT systems and infrastructure

Each section should indicate the job title of the individuals responsible for the management and completion of the activity. It may also detail suppliers, service providers, contractors, partners, and other individuals and entities that may be utilized or contracted to perform a role in the recovery efforts.

A recovery plan may be organized by operational section. For example, different individuals may have responsibilities, and each section may feature different priorities, timelines, suppliers, and requirements. The following operational sections might be included in a recovery plan for an IT department:

• Physical Facility
• Facility Wiring
• Network Hardware
• Data, Applications, and Operating System Restoration
• Communications Hardware

Figure 4.6 illustrates a graphical technique of prioritizing disaster response by analyzing the impact to the business if a catastrophic event should occur. Obviously, plans to restore high-impact, high-probability processes take precedence over low-impact, low-probability processes. This type of planning chart will easily illustrate restoration priorities. Business processes that are very important to the business would be placed in the upper-right quadrant, indicating that the continuity of these processes has high significance to the continued operation of the business.

Plan Testing

Continuity plans and disaster plans required testing. Testing is the method of identifying weaknesses, reviewing assignments and updating plan information. It also verifies that the plan meets the organization's needs and requirements and that all individuals responsible for action items are knowledgeable and competent regarding their responsibilities. The primary goal of testing includes the following activities:

• Fulfill testing, exercise, and maintenance requirements
• Conduct training for the business continuity team supervisory individuals
• Conduct orientation for all staff positions
• Conduct actual changeover or simulated scenarios
• Update plans to incorporate “lessons learned from” exercises

Various methods may be used to test the plans with varying degrees of risk to the organization and commitment of time and resources:

1. Checklist Test The checklist test enables individuals to review the continuity plan or disaster recovery plan to ensure that all procedures and critical areas within their responsibility are addressed. During this test, they meet update information including contact and duty assignment information. This type of test is conducted at the individuals work space, office or cube and requires the least amount of effort and resources. Some organizations may also referred to as a desktop test.
2. Tabletop Test In a tabletop test, individuals assigned to the test being conducted will assemble in a conference room. Here they will review the continuity plan or disaster recovery plan and proceed through the plan step-by-step, outlining their personal responsibilities. Sometimes referred to as a structured walk-through test, this test enables the group to discuss the plans and update them where required. During the tabletop test or structured walk-through test, a specific scenario may be discussed and individuals may role-play their assigned activities. In one such test it was discovered that a key person from the finance staff was required to be part of the continuity team because they were the only staff members who had purchasing authority.
3. Simulation Test A typical emergency situation may be practiced during a simulation test. In this type of test, individuals role-play their assignments to bring the simulation to a successful conclusion. They are instructed to go through all the exact steps they would in the event of a real emergency situation, the steps being coordinated by the continuity plan leader. The leader might designate a specific time for the start of the test.

   At that time, the continuity plan leader announces the type of emergency, such as a fire and evacuation of part of the building with an outage of all network operations and communication within that area. The leader may then declare the potential impact of the event. For instance, nationwide customer service is completely interrupted for the next 20 hours. Since the current work location is no longer available, the team leader designates the location that will be used as an alternate site for the coordination of all activities. All responsible participants will relocate all of their available resources to the newly assigned location. If they are responsible for other individuals, they have to locate these people and deliver them to a predefined location.

   The simulation tests is a very accurate training tool because, invariably, people will forget things, not have transportation, not have backups available, or find that communication is inadequate. The simulation test is typically conducted once a year in many organizations due to the fact that it may interrupt or disrupt business activities during the testing period.

4. Parallel Test A parallel test is similar to those tests where software applications are run in parallel with the actual business environment to test how well they will perform. In a parallel test, duplicate systems or alternate processing sites may be brought online and run in parallel with the existing data processing system. This type of test can tend to be complex and expensive. The benefit is that in the event anything goes wrong with the parallel test, the primary processing environment is not affected.
5. Full Interruption Test A full interruption test entails a complete power up of an alternate site, switch over and power down of the primary site. This test is very risky and expensive. Typically, only the business activities requiring the highest level of continuity are switched to the alternate site. The challenge on many full interruption tests is to bring the primary site back online.

Succession Planning

With proper succession planning, backup personnel are available in the event that key personnel are lost or unavailable. Backup personnel may be required to fill key business leadership positions in the company or IT department. Succession planning increases the availability of experienced and capable employees who are prepared to assume these roles if they are required.

Succession planning is key within an IT department. It begins with the process of hiring competent well-rounded personnel. They should then be cross-trained in many different disciplines. Specifically for disaster planning, the disaster plan should clearly list, by job title, the succession to the top decision-making role during a disaster. This is simply accomplished in some organizations by a “call list” that includes the individuals who should be notified of an event or situation. The point is, in a disaster scenario, a clear leader and decision-maker must be denoted. In the event a primary person is not available, the authority should immediately be instilled with a backup person.

In planning for succession, individuals should be cross-trained in disaster preparedness and information should be shared among both the primary and backup persons who are responsible to take action. Plans including procedures, documentation, policies, and other documents should be identified and shared.

Disaster Planning Alternate Sites

Business continuity plans require the listing of alternate plans for the continuation of IT operations should a disaster occur. Of course, in some level I disasters, as previously described, IT operations may continue in the same location. A level III disaster may mean that a location is no longer suitable or available for continued IT operations and therefore a decision must be made to relocate, on a temporary basis, to an alternate site or facility. It is important during the creation of business continuity plans to carefully consider and preplan alternate sites. These alternate sites should be arranged for and contracted in anticipation of any need arising.

A variety of site selections and alternative methods are available for the continuity of business operations:

1. Hot Site A hot site is a physical location available for immediate switchover of processing operations. A hot site typically contains power, heating, ventilation and air-conditioning, security, connectivity, servers, workstations, and networking devices that may be substituted for the existing production environment. Data may also be mirrored to the hot site, requiring little or no installation or update. A hot site is set aside exclusively for the use of the organization. The hot site installation and contract is very expensive.
2. Warm Site A warm site is a computer facility that is contractually available and has some power, heating, ventilation and air-conditioning, connectivity, and basic networking equipment. Organizations may be required to install servers, workstations, and other networking devices in order to make a warm site fully operational. Obviously, a warm site will take longer to bring online than a hot site. Some suppliers of warm sites offer mobile capability. The mobile site features IT equipment mounted in semitrailer vans that may be brought to an organization's location. A major consideration is that in the event of a major catastrophic event affecting a number of organizations, a warm site may not be available due to the number of organizations under contract to use it.
3. Cold Site A cold site is a facility that has power, heating, ventilation and air-conditioning, and little else. It does not have communications or computer equipment. If an organization has to set up an alternate site for processing, they would have to bring in and set up every device. Although it's the least expensive of the site alternatives, bringing a cold site online would involve a substantial undertaking and expense.
4. Virtual Site With the proliferation of cloud services, various cloud providers are providing Infrastructure as a Service (IaaS) disaster recovery sites. Under these programs, the organization's existing IT infrastructure may be established under virtual conditions in the cloud. Data and applications may be made available almost immediately under the circumstances.
5. Partnership/Cooperative Site A partnership/cooperative site also known as a reciprocal site involves an agreement between two companies to share resources in the event of a disaster. In such a situation, excess capacity by the way of servers, storage, computer workstations, and other resources may be made available should one or either company experience a disaster situation.

Several scenarios should be envisioned when planning for alternate sites or the relocation of operations. The assumption might be that if a disaster affects a geographic region, various scenarios may occur.

1. Alternate Site Proximity A general rule of thumb is that an alternate site should be no closer to the original site than 20 miles. This takes into consideration general geographic disasters such as earthquakes, floods, hurricanes, tornadoes, forest fires, or other events that might affect not only the organization but every business within a radius of several miles. This was evident during 9/11 when a company's backup location was the second World Trade Center tower. Consideration should also be given to the transportation of individuals, data, and hardware to the alternate site as well as room and board of individuals while at the alternate site.
2. Competition for Resources When disaster affects a geographic region, it affects all the companies and businesses as well as potential suppliers and providers within the area. The business continuity plan and disaster recovery plan should take into account that the resources required for recovery may not be available because they are being utilized by other organizations within the same vicinity. This includes contracts for alternate sites. Another organization may have contracted for a priority position in using an alternate site. As part of a contingency plan, many companies maintain a quantity of small-denomination currency and even have gold on hand to use to barter for services, equipment, and supplies in an emergency.