Mission (not-so-impossible) and strategy

Corny heading, yes, but there’s a good chance you’re humming the Mission Impossible theme song now — mission accomplished!

An organization’s mission statement expresses its reason for existence. A good mission statement is an easily understood, general-purpose statement that says what the organization is, what it does, and why it exists, doing what it does in the way that it has chosen.

An organization’s strategy, describes how it accomplishes its mission and is frequently adapted to address new challenges and business realities.

Goals and objectives

A goal is something (or many somethings) that an organization hopes to accomplish. A goal should be consistent with the organization’s mission statement or philosophy, and it should help define a vision for the organization. It should also whip people into a wild frenzy, running around their offices, waving their arms in the air, and yelling “GOOOAAALLL!” (Well, maybe only if they’re World Cup fans.)

An objective is a milestone or a specific result that is expected and, as such, helps an organization attain its goals and achieve its mission.

Security personnel should be acutely aware of their organizations’ goals and objectives. Only then can security professionals ensure that security capabilities will work with and protect all the organization’s current, changing, and new products, services, and endeavors.

Organizations often use the terms goals and objectives interchangeably without distinction. Worse yet, some organizations refer to goals as long-term objectives, and objectives as short-term goals! For the CISSP exam, an objective (short-term) supports a goal (intermediate-term), which supports a mission (long-term), which is accomplished with a well-defined strategy. All of these fall under the umbrella of the organization’s mission statement.

Governance committees and executive oversight

Security management starts (or should start!) at the top with executive management and board-level oversight. This generally takes the form of security governance, which simply means that the organization’s governing body has set the direction and the organization has policies and processes in place to ensure that executive management is following that direction, is fully informed, and is in control of information security strategy, policy, and operations.

A governance committee is a group of executives and/or managers who regularly meet to review security incidents, projects, operational metrics, and other aspects of concern to them. The governance committee will occasionally issue mandates to security management about new business activities and shifts in priorities and strategic direction.

In practice, this is not much different from governance in IT or other departments. Governance is how executive management stays involved in the goings-on in IT, security, and other parts of the business.

Acquisitions and divestitures

Organizations, particularly in private industry, continually are reinventing themselves. More than ever before, it is important to be agile and competitive. This results in organizations acquiring other organizations, organizations splitting themselves into two (or more) separate companies, as well as internal reorganizations to change the alignment of teams, departments, divisions, and business units.

There are several security-related considerations that should be taken into account when an organization acquires another organization, or when two (or more) organizations merge:

• Security governance and management. How is security managed in each organization, and what important differences are there?
• Security policy. How do policies between the two organizations differ, and what issues will be encountered when merging the policies into one?
• Security posture. Which security controls are present in each organization, and how different are they from one another?
• Security operations. What security operations are in place today and how do they operate? This includes vulnerability management, event monitoring, identity and access management, third-party risk management, and incident management.

If the security of one organization is vastly different from another, the organization should not be too hasty to connect the two organizations’ networks together.

Interestingly, when an organization divides itself into two (or more) separate organizations or sells off a division, it can be trickier. Each new company probably will need to duplicate the security governance, management, controls, operations, and tools that the single organization had before the split. This doesn’t always mean that the two separate security functions need to be the same as the old; it is important to fully understand the business mission in each new organization, and what security regulations and standards apply to each new organization. Only then can information security align to each new organization.

Management

Senior-level management is often responsible for information security at several levels, including the role as an information owner, which we discuss in the following section. However, in this context, management has a responsibility to demonstrate a strong commitment to an organization’s information security program through the following actions:

• Creating, mandating, and approving a corporate information security policy: This policy should include a statement of support from management and should also be signed by the CEO, COO, CIO, or the Chairman of the Board.
• Leading by example: A CEO who carries a mandatory identification badge and utilizes system access controls sets a good example.
• Rewarding compliance: Management should expect proper security behavior and acknowledge, recognize, and/or reward employees accordingly.

Management is always ultimately responsible for an organization’s overall information security and for any information security decisions that are made (or not made). Our role as information security professionals is to report security issues and to make appropriate information security recommendations to management.

Users

An end-user (or user) includes just about everyone within an organization. Users aren’t specifically designated. They can be broadly defined as anyone who has authorized access to an organization’s internal information or information systems. Users include employees, contractors and other temporary help, consultants, vendors, customer, and anyone else with access. Some organizations call them employees, partners, associates, or what-have-you. Typical user responsibilities include

• Complying with all applicable security requirements defined in organizational policies, standards, and procedures; applicable legislative or regulatory requirements; and contractual requirements (such as non-disclosure agreements and Service Level Agreements).
• Exercising due care in safeguarding organizational information and information assets.
• Participating in information security training and awareness efforts as required.
• Reporting any suspicious activity, security violations, security problems, or security concerns to appropriate personnel.

Common law

Common law (also known as case law) originated in medieval England, and is derived from the decisions (or precedents) of judges. Common law is based on the doctrine of stare decisis (“let the decision stand”) and is often codified by statutes. Under the common law system of the United States, three major categories of laws are defined at the federal and state levels: criminal, civil (or tort), and administrative (or regulatory) laws.

Criminal law

Criminal law defines those crimes committed against society, even when the actual victim is a business or individual(s). Criminal laws are enacted to protect the general public. As such, in the eyes of the court, the victim is incidental to the greater cause.

Civil law

Civil (tort) law addresses wrongful acts committed against an individual or business, either willfully or negligently, resulting in damage, loss, injury, or death.

Administrative law

Administrative (regulatory) laws define standards of performance and conduct for major industries (including banking, energy, and healthcare), organizations, and government agencies. These laws are typically enforced by various government agencies, and violations may result in financial penalties and/or imprisonment.

International law

Given the global nature of the Internet, it’s often necessary for countries to cooperate in order to bring a computer criminal to justice. But because practically every country in the world has its own unique legal system, such cooperation is always difficult and often impossible. As a starting point, countries sometimes disagree on exactly what justice is. Other problems include

• Lack of universal cooperation: We can’t answer the question, “Why can’t we all just get along?” but we can tell you that it’s highly unlikely that a 14-year-old hacker in some remote corner of the world will commit some dastardly crime that unites us all in our efforts to take him down, bringing about a lasting world peace.
• Differing interpretations of laws: What’s illegal in one country (or even in one state in the U.S.) isn’t necessarily illegal in another.
• Differing rules of evidence: This problem can encompass different rules for obtaining and collecting evidence, as well as different rules for admissibility of evidence.
• Low priority: Different nations have different views regarding the seriousness of computer crimes; and in the realm of international relations, computer crimes are usually of minimal concern.
• Outdated laws and technology: Related to the low-priority problem. Technology varies greatly throughout the world, and many countries (not only the Third World countries) lag far behind others. For this reason and many others, computer crime laws are often a low priority and aren’t kept current. This problem is further exacerbated by the different technical capabilities of the various law enforcement agencies that may be involved in an international case.
• Extradition: Many countries don’t have extradition treaties and won’t extradite suspects to a country that has different or controversial practices, such as capital punishment. Although capital punishment for a computer crime may sound extreme, recent events and the threat of cyberterrorism make this a very real possibility.

Besides common law systems (which we talk about in the section “Common law,” earlier in this chapter), other countries throughout the world use legal systems including:

• Civil law systems: Not to be confused with U.S. civil law, which is based on common law. Civil law systems use constitutions and statutes exclusively and aren’t based on precedent. The role of a judge in a civil law system is to interpret the law. Civil law is the most widespread type of law system used throughout the world.
• Napoleonic code: Originating in France after the French Revolution, the Napoleonic code has spread to many other countries in Europe and elsewhere. In this system, laws are developed by legislative bodies and interpreted by the courts. However, there is often no formal concept of legal precedent.
• Religious (or customary) law systems: Derived from religious beliefs and values. Common religious law systems include Sharia in Islam, Halakha in Judaism, and Canon law in Christianity.
• Pluralistic (or mixed) law systems: Combinations of various systems, such as civil and common law, civil and religious law, and common and religious law.

U.S. Computer Fraud and Abuse Act of 1986, 18 U.S.C. § 1030 (as amended)

In 1986, the first U.S. federal computer crime law, the U.S. Computer Fraud and Abuse Act, was passed. This intermediate act was narrowly defined and somewhat ambiguous. The law covered:

• Classified national defense or foreign relations information
• Records of financial institutions or credit reporting agencies
• Government computers

The U.S. Computer Fraud and Abuse Act of 1986 enhanced and strengthened the 1984 law, clarifying definitions of criminal fraud and abuse for federal computer crimes and removing obstacles to prosecution.

The Act established two new felony offenses for the unauthorized access of federal interest computers and a misdemeanor for unauthorized trafficking in computer passwords:

• Felony 1: Unauthorized access, or access that exceeds authorization, of a federal interest computer to further an intended fraud, shall be punishable as a felony [Subsection (a)(4)].

• Felony 2: Altering, damaging, or destroying information in a federal interest computer or preventing authorized use of the computer or information, that causes an aggregate loss of $1,000 or more during a one-year period or potentially impairs medical treatment, shall be punishable as a felony [Subsection (a)(5)].

  This provision was stricken in its entirety and replaced with a more general provision, which we discuss later in this section.

• Misdemeanor: Trafficking in computer passwords or similar information if it affects interstate or foreign commerce or permits unauthorized access to computers used by or for the U.S. government [Subsection (a)(6)].

The Act defines a federal interest computer (actually, the term was changed to protected computer in the 1996 amendments to the Act) as either a computer

• “[E]xclusively for the use of a financial institution or the United States government, or, in the case of a computer not exclusively for such use, used by or for a financial institution or the United States government and the conduct constituting the offense affect that use by or for the financial institution or the government”
• “[W]hich is used in interstate or foreign commerce or communication”

Several minor amendments to the U.S. Computer Fraud and Abuse Act were made in 1988, 1989, and 1990, and more significant amendments were made in 1994, 1996 (by the Economic Espionage Act of 1996), and 2001 (by the USA PATRIOT Act of 2001). The Act, in its present form, establishes eight specific computer crimes. In addition to the three that we discuss in the preceding list, these crimes include the following five provisions (we discuss subsection [a][5] in its current form in the following list):

• Unauthorized access, or access that exceeds authorization, to a computer that results in disclosure of U.S. national defense or foreign relations information [Subsection (a)(1)].
• Unauthorized access, or access that exceeds authorization, to a protected computer to obtain any information on that computer [Subsection (a)(2)].
• Unauthorized access to a protected computer, or access that exceeds authorization, to a protected computer that affects the use of that computer by or for the U.S. government [Subsection (a)(3)].
• Unauthorized access to a protected computer causing damage or reckless damage, or intentionally transmitting malicious code which causes damage to a protected computer [Subsection (a)(5), as amended].
• Transmission of interstate or foreign commerce communication threatening to cause damage to a protected computer for the purpose of extortion [Subsection (a)(7)].

In the section “USA PATRIOT Act of 2001,” later in this chapter, we discuss major amendments to the U.S. Computer Fraud and Abuse Act of 1986 (as amended) that Congress introduced in 2001.

The U.S. Computer Fraud and Abuse Act of 1986 is the major computer crime law currently in effect. The CISSP exam likely tests your knowledge of the Act in its original 1986 form, but you should also be prepared for revisions to the exam that may cover the more recent amendments to the Act.

U.S. Electronic Communications Privacy Act (ECPA) of 1986

The ECPA complements the U.S. Computer Fraud and Abuse Act of 1986 and prohibits eavesdropping, interception, or unauthorized monitoring of wire, oral, and electronic communications. However, the ECPA does provide specific statutory exceptions, allowing network providers to monitor their networks for legitimate business purposes if they notify the network users of the monitoring process.

The ECPA was amended extensively by the USA PATRIOT Act of 2001. These changes are discussed in the upcoming “USA PATRIOT Act of 2001” section.

The U.S. Electronic Communications Privacy Act (ECPA) provides the legal basis for network monitoring.

U.S. Computer Security Act of 1987

The U.S. Computer Security Act of 1987 requires federal agencies to take extra security measures to prevent unauthorized access to computers that hold sensitive information. In addition to identifying and developing security plans for sensitive systems, the Act requires those agencies to provide security-related awareness training for their employees. The Act also assigns formal government responsibility for computer security to the National Institute of Standards and Technology (NIST) for information security standards, in general, and to the National Security Agency (NSA) for cryptography in classified government/military systems and applications.

U.S. Federal Sentencing Guidelines of 1991

In November 1991, the United States Sentencing Commission published Chapter 8, “Federal Sentencing Guidelines for Organizations,” of the U.S. Federal Sentencing Guidelines. These guidelines establish written standards of conduct for organizations, provide relief in sentencing for organizations that have demonstrated due diligence, and place responsibility for due care on senior management officials with penalties for negligence, including fines of up to $290 million.

U.S. Economic Espionage Act of 1996

The U.S. Economic Espionage Act (EEA) of 1996 was enacted to curtail industrial espionage, particularly when such activity benefits a foreign entity. The EEA makes it a criminal offense to take, download, receive, or possess trade secret information that’s been obtained without the owner’s authorization. Penalties include fines of up to $10 million, up to 15 years in prison, and forfeiture of any property used to commit the crime. The EEA also enacted the 1996 amendments to the U.S. Computer Fraud and Abuse Act, which we talk about in the section “U.S. Computer Fraud and Abuse Act of 1986, 18 U.S.C. § 1030 (as amended),” earlier in this chapter.

U.S. Child Pornography Prevention Act of 1996

The U.S. Child Pornography Prevention Act (CPPA) of 1996 was enacted to combat the use of computer technology to produce and distribute pornography involving children, including adults portraying children.

USA PATRIOT Act of 2001

Following the terrorist attacks against the United States on September 11, 2001, the USA PATRIOT Act of 2001 (Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act) was enacted in October 2001 and renewed in March 2006. (Many provisions originally set to expire have since been made permanent under the renewed Act.) This Act takes great strides to strengthen and amend existing computer crime laws, including the U.S. Computer Fraud and Abuse Act and the U.S. Electronic Communications Privacy Act (ECPA), as well as to empower U.S. law enforcement agencies, if only temporarily. U.S. federal courts have subsequently declared some of the Act’s provisions unconstitutional. The sections of the Act that are relevant to the CISSP exam include

• Section 202 — Authority to Intercept Wire, Oral, and Electronic Communications Relating to Computer Fraud and Abuse Offenses: Under previous law, investigators couldn’t obtain a wiretap order for violations of the Computer Fraud and Abuse Act. This amendment authorizes such action for felony violations of that Act.
• Section 209 — Seizure of Voice-Mail Messages Pursuant to Warrants: Under previous law, investigators could obtain access to e-mail under the ECPA but not voice-mail, which was covered by the more restrictive wiretap statute. This amendment authorizes access to voice-mail with a search warrant rather than a wiretap order.
• Section 210 — Scope of Subpoenas for Records of Electronic Communications: Under previous law, subpoenas of electronic records were restricted to very limited information. This amendment expands the list of records that can be obtained and updates technology-specific terminology.
• Section 211 — Clarification of Scope: This amendment governs privacy protection and disclosure to law enforcement of cable, telephone, and Internet service provider records.
• Section 212 — Emergency Disclosure of Electronic Communications to Protect Life and Limb: Prior to this amendment, no special provisions existed that allowed a communications provider to disclose customer information to law enforcement officials in emergency situations, such as an imminent crime or terrorist attack, without exposing the provider to civil liability suits from the customer.

• Section 214 — Pen Register and Trap and Trace Authority under FISA (Foreign Intelligence Surveillance Act): Clarifies law enforcement authority to trace communications on the Internet and other computer networks, and it authorizes the use of a pen/trap device nationwide, instead of limiting it to the jurisdiction of the court.

  A pen/trap device refers to a pen register that shows outgoing numbers called from a phone and a trap and trace device that shows incoming numbers that called a phone. Pen registers and trap and trace devices are collectively referred to as pen/trap devices because most technologies allow the same device to perform both types of traces (incoming and outgoing numbers).

• Section 217 — Interception of Computer Trespasser Communications: Under previous law, it was permissible for organizations to monitor activity on their own networks but not necessarily for law enforcement to assist these organizations in monitoring, even when such help was specifically requested. This amendment allows organizations to authorize persons “acting under color (pretense or appearance) of law” to monitor trespassers on their computer systems.
• Section 220 — Nationwide Service of Search Warrants for Electronic Evidence: Removes jurisdictional issues in obtaining search warrants for e-mail. For an excellent example of this problem, read The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage, by Clifford Stoll (Doubleday).
• Section 814 — Deterrence and Prevention of Cyberterrorism: Greatly strengthens the U.S. Computer Fraud and Abuse Act, including raising the maximum prison sentence from 10 years to 20 years.
• Section 815 — Additional Defense to Civil Actions Relating to Preserving Records in Response to Government Requests: Clarifies the “statutory authorization” (government authority) defense for violations of the ECPA.
• Section 816 — Development and Support of Cybersecurity Forensic Capabilities: Requires the Attorney General to establish regional computer forensic laboratories, maintain existing laboratories, and provide forensic and training capabilities to Federal, State, and local law enforcement personnel and prosecutors.

The USA PATRIOT Act of 2001 changes many of the provisions in the computer crime laws, particularly the U.S. Computer Fraud and Abuse Act, which we discuss in the section “U.S. Computer Fraud and Abuse Act of 1986, 18 U.S.C. § 1030 (as amended),” earlier in this chapter; and the Electronic Communications Privacy Act of 1986, which we detail in the section “U.S. Electronic Communications Privacy Act (ECPA) of 1986,” earlier in this chapter. As a security professional, you must keep abreast of current laws and affairs to perform your job effectively.

U.S. Sarbanes-Oxley Act of 2002 (SOX)

In the wake of several major corporate and accounting scandals, SOX was passed in 2002 to restore public trust in publicly held corporations and public accounting firms by establishing new standards and strengthening existing standards for these entities including auditing, governance, and financial disclosures.

SOX established the Public Company Accounting Oversight Board (PCAOB), which is a private-sector, nonprofit corporation responsible for overseeing auditors in the implementation of SOX. PCAOB’s “Accounting Standard 2” recognizes the role of information technology as it relates to a company’s internal controls and financial reporting. The Standard identifies the responsibility of Chief Information Officers (CIOs) for the security of information systems that process and store financial data, and it has many implications for information technology security and governance.

U.S. Homeland Security Act of 2002

This law consolidated 22 U.S. government agencies to form the Department of Homeland Security (DHS). The law also provided for the creation of a privacy official to enforce the Privacy Act of 1974.

U.S. Federal Information Systems Management Act (FISMA) of 2002

FISMA extended the Computer Security Act of 1987 by requiring regular audits of both U.S. government information systems, and organizations providing information services to the U.S. federal government.

U.S. CAN-SPAM Act of 2003

The U.S. CAN-SPAM Act (Controlling the Assault of Non-Solicited Pornography and Marketing Act) establishes standards for sending commercial e-mail messages, charges the U.S. Federal Trade Commission (FTC) with enforcement of the provision, and provides penalties that include fines and imprisonment for violations of the Act.

U.S. Identity Theft and Assumption Deterrence Act of 2003

This law updated earlier U.S. laws on identity theft.

Directive 95/46/EC on the protection of personal data (1995, EU)

In 1995, the European Parliament ratified this essential legislation that protects personal information for all European citizens. The directive states that personal data should not be processed at all, except when certain conditions are met.

A legitimate concern about the disposition of European citizens’ personal data when it leaves computer systems in Europe and enters computer systems in the U.S. led to the creation of the Safe Harbor program (discussed in the following section).

Safe Harbor (1998)

In an agreement between the European Union and the U.S. Department of Commerce in 1998, the U.S. Department of Commerce developed a certification program called Safe Harbor. This permits U.S.-based organizations to certify themselves as properly handling private data belonging to European citizens.

U.S. Intelligence Reform and Terrorism Prevention Act of 2004

This law facilitates the sharing of intelligence information between various U.S. government agencies, as well as protections of privacy and civil liberties.

The Council of Europe’s Convention on Cybercrime (2001)

The Convention on Cybercrime is an international treaty, currently signed by more than 40 countries (the U.S. ratified the treaty in 2006), requiring criminal laws to be established in signatory nations for computer hacking activities, child pornography, and intellectual property violations. The treaty also attempts to improve international cooperation with respect to monitoring, investigations, and prosecution.

The Computer Misuse Act 1990 (U.K.)

The Computer Misuse Act 1990 (U.K.) defines three criminal offenses related to computer crime: unauthorized access (whether successful or unsuccessful), unauthorized modification, and hindering authorized access (Denial of Service).

Privacy and Electronic Communications Regulations of 2003 (U.K.)

Similar to U.S. “do not call” laws, this law makes it illegal to use equipment to make automated telephone calls that play recorded messages.

Information Technology Act 2000 (India)

This law modernized computer crimes and defined activities such as data theft, creation and spreading of malware, identity theft, pornography, child pornography, and cyber terrorism. This law also validated electronic contracts and electronic signatures.

Cybercrime Act 2001 (Australia)

The Cybercrime Act 2001 (Australia) establishes criminal penalties, including fines and imprisonment, for people who commit computer crimes (including unauthorized access, unauthorized modification, or Denial of Service) with intent to commit a serious offense.

Payment Card Industry Data Security Standard (PCI DSS)

Although not (yet) a legal mandate, the Payment Card Industry Data Security Standard (PCI DSS) is one example of an industry initiative for mandating and enforcing security standards. PCI DSS applies to any business worldwide that transmits, processes, or stores payment card (meaning credit card) transactions to conduct business with customers — whether that business handles thousands of credit card transactions a day or a single transaction a year. Compliance is mandated and enforced by the payment card brands (American Express, MasterCard, Visa, and so on) and each payment card brand manages its own compliance program.

Although PCI DSS is an industry standard rather than a legal mandate, many states are beginning to introduce legislation that would make PCI compliance (or at least compliance with certain provisions) mandatory for organizations that do business in that state.

PCI DSS requires organizations to submit an annual assessment and network scan, or to complete onsite PCI data security assessments and quarterly network scans. The actual requirements depend on the number of payment card transactions handled by an organization and other factors, such as previous data loss incidents.

PCI DSS version 3.2 consists of six core principles, supported by 12 accompanying requirements, and more than 200 specific procedures for compliance. These include

• Principle 1: Build and maintain a secure network:
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
  • Requirement 2: Don’t use vendor-supplied defaults for system passwords and other security parameters.
• Principle 2: Protect cardholder data:
  • Requirement 3: Protect stored cardholder data.
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks.
• Principle 3: Maintain a vulnerability management program:
  • Requirement 5: Use and regularly update antivirus software.
  • Requirement 6: Develop and maintain secure systems and applications.
• Principle 4: Implement strong access control measures:
  • Requirement 7: Restrict access to cardholder data by business need-to-know.
  • Requirement 8: Assign a unique ID to each person who has computer access.
  • Requirement 9: Restrict physical access to cardholder data.
• Principle 5: Regularly monitor and test networks:
  • Requirement 10: Track and monitor all access to network resources and cardholder data.
  • Requirement 11: Regularly test security systems and processes.
• Principle 6: Maintain an information security policy:
  • Requirement 12: Maintain a policy that addresses information security.

Penalties for non-compliance are levied by the payment card brands and include not being allowed to process credit card transactions, fines up to $25,000 per month for minor violations, and fines up to $500,000 for violations that result in actual lost or stolen financial data.

Patents

A patent, as defined by the U.S. Patent and Trademark Office (PTO) is “the grant of a property right to the inventor.” A patent grant confers upon the owner (either an individual or a company) “the right to exclude others from making, using, offering for sale, selling, or importing the invention.” In order to qualify for a patent, an invention must be novel, useful, and not obvious. An invention must also be tangible — an idea cannot be patented. Examples of computer-related objects that may be protected by patents are computer hardware and physical devices in firmware.

A patent is granted by the U.S. PTO for an invention that has been sufficiently documented by the applicant and that has been verified as original by the PTO. A U.S. patent is generally valid for 20 years from the date of application and is effective only within the U.S., including territories and possessions. Patent applications must be filed with the appropriate patent office in various countries throughout the world to receive patent protection in that country. The owner of the patent may grant a license to others for use of the invention or its design, often for a fee.

U.S. patent (and trademark) laws and rules are covered in 35 U.S.C. and 37 C.F.R., respectively. The Patent Cooperation Treaty (PCT) provides some international protection for patents. More than 130 countries worldwide have adopted the PCT. Patent infringements are not prosecuted by the U.S. PTO. Instead, the holder of a patent must enforce their patent rights through the appropriate legal system.

Patent grants were previously valid for only 17 years, but have recently been changed, for newly granted patents, to 20 years.

Trademarks

A trademark, as defined by the U.S. PTO, is “any word, name, symbol, or device, or any combination, used, or intended to be used, in commerce to identify and distinguish the goods of one manufacturer or seller from goods manufactured or sold by others.” Computer-related objects that may be protected by trademarks include corporate brands and operating system logos. U.S. Public Law 105–330, the Trademark Law Treaty Implementation Act, provides some international protection for U.S. registered trademarks.

Copyrights

A copyright is a form of protection granted to the authors of “original works of authorship,” both published and unpublished. A copyright protects a tangible form of expression rather than the idea or subject matter itself. Under the original Copyright Act of 1909, publication was generally the key to obtaining a federal copyright. However, the Copyright Act of 1976 changed this requirement, and copyright protection now applies to any original work of authorship immediately, from the time that it’s created in a tangible form. Object code or documentation are examples of computer-related objects that may be protected by copyrights.

Copyrights can be registered through the Copyright Office of the Library of Congress, but a work doesn’t need to be registered to be protected by copyright. Copyright protection generally lasts for the lifetime of the author plus 70 years.

Trade secrets

A trade secret is proprietary or business-related information that a company or individual uses and has exclusive rights to. To be considered a trade secret, the information must meet the following requirements:

• Must be genuine and not obvious: Any unique method of accomplishing a task would constitute a trade secret, especially if it is backed up by copyrighted, patented, or proprietary software or methods that give that organization a competitive advantage.
• Must provide the owner a competitive or economic advantage and, therefore, have value to the owner: For example, Google’s search algorithms — the “secret sauce” that makes it popular with users (and therefore advertisers) — aren’t universally known. Some secrets are protected.
• Must be reasonably protected from disclosure: This doesn’t mean that it must be kept absolutely and exclusively secret, but the owner must exercise due care in its protection.

Software source code or firmware code are examples of computer-related objects that an organization may protect as trade secrets.

U.S. Federal Privacy Act of 1974, 5 U.S.C. § 552A

The Federal Privacy Act of 1974 protects records and information maintained by U.S. government agencies about U.S. citizens and lawful permanent residents. Except under certain specific conditions, no agency may disclose any record about an individual “except pursuant to a written request by, or with the prior written consent of, the individual to whom the record pertains.” The Privacy Act also has provisions for access and amendment of an individual’s records by that individual, except in cases of “information compiled in reasonable anticipation of a civil action or proceeding.” The Privacy Act provides individual penalties for violations, including a misdemeanor charge and fines up to $5,000.

Although the Federal Privacy Act of 1974 pre-dates the Internet as we know it today, don’t dismiss its relevance. The provisions of the Privacy Act are as important as ever and remain in full force and effect today.

U.S. Health Insurance Portability and Accountability Act (HIPAA) of 1996, PL 104–191

HIPAA was signed into law effective August 1996. The HIPAA legislation provided Congress three years from that date to pass comprehensive health privacy legislation. When Congress failed to pass legislation by the deadline, the Department of Health and Human Services (HHS) received the authority to develop the privacy and security regulations for HIPAA. In October 1999, HHS released proposed HIPAA privacy regulations entitled “Privacy Standards for Individually Identifiable Health Information,” which took effect in April 2003. HIPAA security standards were subsequently published in February 2003 and took effect in April 2003. Organizations that must comply with HIPAA regulations are referred to as covered entities and include

• Payers (or health plan): An individual or group health plan that provides — or pays the cost of — medical care; for example, insurers.
• Healthcare clearinghouses: A public or private entity that processes or facilitates the processing of nonstandard data elements of health information into standard data elements, such as data warehouses.
• Healthcare providers: A provider of medical or other health services, such as hospitals, HMOs, doctors, specialists, dentists, and counselors.

Civil penalties for HIPAA violations include fines of $100 per incident, up to $25,000 per provision, per calendar year. Criminal penalties include fines up to $250,000 and potential imprisonment of corporate officers for up to ten years. Additional state penalties may also apply.

In 2009, Congress passed additional HIPAA provisions as part of the American Recovery and Reinvestment Act of 2009, requiring covered entities to publicly disclose security breaches involving personal information. (See the section “Disclosure laws” later in this chapter for a discussion of disclosure laws.)

Children’s Online Privacy Protection Act (COPPA) of 1998

This law provides for protection of online information about children under the age of 13. The law defines rules for the collection of information from children and means for obtaining consent from parents. Organizations are also restricted from marketing to children under the age of 13.

U.S. Gramm-Leach-Bliley Financial Services Modernization Act (GLBA) of 1999, PL 106-102

Gramm-Leach-Bliley (known as GLBA) opened up competition among banks, insurance companies, and securities companies. GLBA also requires financial institutions to better protect their customers’ personally identifiable information (PII) with three rules:

• Financial Privacy Rule: Requires each financial institution to provide information to each customer regarding the protection of customers’ private information.
• Safeguards Rule: Requires each financial institution to develop a formal written security plan that describes how the institution will protect its customers’ PII.
• Pretexting Protection: Requires each financial institution to take precautions to prevent attempts by social engineers to acquire private information about institutions’ customers.

Civil penalties for GLBA violations are up to $100,000 for each violation. Furthermore, officers and directors of financial institutions are personally liable for civil penalties of not more than $10,000 for each violation.

U.S. Health Information Technology for Economic and Clinical Health Act (HITECH) of 2009

The HITECH Act, passed as part of the American Recovery and Reinvestment Act of 2009, broadens the scope of HIPAA compliance to include the business associates of HIPAA covered entities. These include third-party administrators, pharmacy benefit managers for health plans, claims processing/billing/transcription companies, and persons performing legal, accounting and administrative work.

Another highly important provision of the HITECH Act promotes and, in many cases, funds the adoption of electronic health records (EHRs), in order to increase the effectiveness of individual medical treatment, improve efficiency in the U.S. healthcare system, and reduce the overall cost of healthcare. Anticipating that the widespread adoption of EHRs will increase privacy and security risks, the HITECH Act introduces new security and privacy-related requirements.

In the event of a breach of “unsecured protected health information,” the HITECH Act requires covered entities to notify the affected individuals and the Secretary of the U.S. Department of Health and Human Services (HHS). The regulation defines unsecured protected health information (PHI) as PHI that is not secured through the use of a technology or methodology to render it unusable, unreadable, or indecipherable to unauthorized individuals.

The notification requirements vary according to the amount of data breached

• A data breach affecting more than 500 people must be reported immediately to the HHS, major media outlets and individuals affected by the breach, and must be posted on the official HHS website.
• A data breach affecting fewer than 500 people must be reported to the individuals affected by the breach, and to the HHS secretary.

Finally, the HITECH Act also requires the issuance of technical guidance on the technologies and methodologies “that render protected health information unusable, unreadable, or indecipherable to unauthorized individuals”. The guidance specifies data destruction and encryption as actions that render PHI unusable if it is lost or stolen. PHI that is encrypted and whose encryption keys are properly secured provides a “safe harbor” to covered entities and does not require them to issue data-breach notifications.

U.K. Data Protection Act

Passed by Parliament in 1998, the U.K. Data Protection Act (DPA) applies to any organization that handles sensitive personal data about living persons. Such data includes

• Names
• Birth and anniversary dates
• Addresses, phone numbers, and e-mail addresses
• Racial or ethnic origins
• Political opinions and religious (or similar) beliefs
• Trade or labor union membership
• Physical or mental condition
• Sexual orientation or lifestyle
• Criminal or civil records or allegations

The DPA applies to electronically stored information, but certain paper records used for commercial purposes may also be covered. The DPA consists of eight privacy and disclosure principles as follows:

• “Personal data shall be processed fairly and lawfully and [shall not be processed unless certain other conditions (set forth in the Act) are met].”
• “Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.”
• “Personal data shall be adequate, relevant, and not excessive in relation to the purpose or purposes for which they are processed.”
• “Personal data shall be accurate and, where necessary, kept up-to-date.”
• “Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.”
• “Personal data shall be processed in accordance with the rights of data subjects under this Act.”
• “Appropriate technical and organizational measures shall be taken against unauthorized or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.”
• “Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data.”

DPA compliance is enforced by the Information Commissioner’s Office (ICO), an independent official body. Penalties generally include fines which may also be imposed against the officers of a company.

European Union General Data Protection Regulation (GDPR)

The European Union General Data Protection Regulation, known as GDPR, represents a significant revision of the 1995 privacy directive. Highlights of GDPR include the following:

• Requires the enactment of a formal, documented data privacy program, which must direct all relevant business activities be designed with privacy by default and privacy by design.
• Requires that organizations that collect personally identifiable information from any European resident obtain explicit consent for the collection and use of such information. Organizations’ collection of personally identifiable information must be opt-in as opposed to opt-out. In other words, users must choose to opt in to data collection and usage.
• Data subjects must have the ability to review information about themselves, be able to request that corrections be made, and be able to request that their data be expunged upon request.
• Definition of a data controller, an organization that stores and processes personally identifiable information.
• Definition of a data processor, an organization that stores and processes personally identifiable information as directed by a data controller.
• Requires the appointment of a data protection officer (DPO), an individual that oversees the creation and operation of an organization’s data privacy program.
• Requires that all affected data subjects be notified within 72 hours of a data breach.
• Permits European authorities to levy fines on organizations that violate terms of GDPR, with those fines being as high as €20 million or 4 percent of the organization’s annual turnover (revenue).

California Security Breach Information Act (SB-1386)

Passed in 2003, the California Security Breach Information Act (SB-1386) was the first U.S. state law to require organizations to notify all affected individuals “in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement,” if their confidential or personal data is lost, stolen, or compromised, unless that data is encrypted.

The law is applicable to any organization that does business in the state of California — even a single customer or employee in California. An organization is subject to the law even if it doesn’t directly do business in California (for example, if it stores personal information about California residents for another company).

Other U.S. states have quickly followed suit, and 46 states, the District of Columbia, Puerto Rico, and the U.S. Virgin Islands now have public disclosure laws. However, these laws aren’t necessarily consistent from one state to another, nor are they without flaws and critics.

For example, until early 2008, Indiana’s Security Breach Disclosure and Identity Deception law (HEA 1101) did not require an organization to disclose a security breach “if access to the [lost or stolen] device is protected by a password [emphasis added] that has not been disclosed.” Indiana’s law has since been amended and is now one of the toughest state disclosure laws in effect, requiring public disclosure unless “all personal information … is protected by encryption.”

Finally, a provision in California’s and Indiana’s disclosure laws, as well as in most other states’ laws, allows an organization to avoid much of the cost of disclosure if the cost of providing such notice would exceed $250,000 or if more than 500,000 individuals would need to be notified. Instead, a substitute notice, consisting of e-mail notifications, conspicuous posting on the organization’s website, and notification of major statewide media, is permitted.

Internet Architecture Board (IAB) — Ethics and the Internet (RFC 1087)

Published by the Internet Architecture Board (IAB) (www.iab.org) in January 1989, RFC 1087 characterizes as unethical and unacceptable any activity that purposely

• “Seeks to gain unauthorized access to the resources of the Internet.”
• “Disrupts the intended use of the Internet.”
• “Wastes resources (people, capacity, computer) through such actions.”
• “Destroys the integrity of computer-based information.”
• “Compromises the privacy of users.”

Other important tenets of RFC 1087 include

• “Access to and use of the Internet is a privilege and should be treated as such by all users of [the] system.”
• “Many of the Internet resources are provided by the U.S. Government. Abuse of the system thus becomes a Federal matter above and beyond simple professional ethics.”
• “Negligence in the conduct of Internet-wide experiments is both irresponsible and unacceptable.”
• “In the final analysis, the health and well-being of the Internet is the responsibility of its users who must, uniformly, guard against abuses which disrupt the system and threaten its long-term viability.”

Computer Ethics Institute (CEI)

The Computer Ethics Institute (CEI; http://computerethicsinstitute.org) is a nonprofit research, education, and public policy organization originally founded in 1985 by the Brookings Institution, IBM, the Washington Consulting Group, and the Washington Theological Consortium. CEI members include computer science and information technology professionals, corporate representatives, professional industry associations, public policy groups, and academia.

CEI’s mission is “to provide a moral compass for cyberspace.” It accomplishes this mission through computer-ethics educational activities that include publications, national conferences, membership and certificate programs, a case study repository, the Ask an Ethicist online forum, consultation, and (most famously) its “Ten Commandments of Computer Ethics,” which has been published in 23 languages (presented here in English):

1. Thou shalt not use a computer to harm other people.
2. Thou shalt not interfere with other people’s computer work.
3. Thou shalt not snoop around in other people’s computer files.
4. Thou shalt not use a computer to steal.
5. Thou shalt not use a computer to bear false witness.
6. Thou shalt not copy or use proprietary software for which you have not paid.
7. Thou shalt not use other people’s computer resources without authorization or proper compensation.
8. Thou shalt not appropriate other people’s intellectual output.
9. Thou shalt think about the social consequences of the program you are writing or the system you are designing.
10. Thou shalt always use a computer in ways that ensure consideration and respect for your fellow humans.

Emergency response

Emergency response teams must be identified for every possible type of disaster. These response teams need playbooks (detailed written procedures and checklists) to keep critical business functions operating.

Written procedures are vital for two reasons. First, the people who perform critical functions after a disaster may not be familiar with them: They may not usually perform those functions. (During a disaster, the people who ordinarily perform the function may be unavailable.) Second, the team probably needs to use different procedures and processes for performing the critical functions during a disaster than they would under normal conditions. Also, the circumstances surrounding a disaster might have people feeling out-of-sorts; having a written procedure guides them into action (kind of like the “break glass” instructions on some fire alarms, in case you forget what to do).

Damage assessment

When a disaster strikes, experts need to be called in to inspect the premises and determine the extent of the damage. Typically, you need experts who can assess building damage, as well as damage to any special equipment and machinery.

Depending on the nature of the disaster, you may have to perform damage assessment in stages. A first assessment may involve a quick walkthrough to look for obvious damage, followed by a more time-consuming and detailed assessment to look for problems that you don’t see right away.

Damage assessments determine whether an organization can still use buildings and equipment, whether they can use those items after some repairs, or whether they must abandon those items altogether.

Personnel safety

In any kind of disaster, the safety of personnel is the highest priority, ahead of buildings, equipment, computers, backup tapes, and so on. Personnel safety is critical not only because of the intrinsic value of human life, but also because people — not physical assets — make the business run.

Personnel notification

The BCP must have some provisions for notifying all affected personnel that a disaster has occurred. An organization needs to establish multiple methods for notifying key business-continuity personnel in case public communications infrastructures are interrupted.

Not all disasters are obvious: A fire or broken water main is a local event, not a regional one. And in an event such as a tornado or flood, employees who live even a few miles away may not know the condition of the business. Consequently, the organization needs a plan for communicating with employees, no matter what the situation.

Throughout a disaster and its recovery, management must be given regular status reports as well as updates on crucial tactical issues so that management can align resources to support critical business operations that function on a contingency basis. For instance, a manager of a corporate facilities department can loan equipment that critical departments need so that they can keep functioning.

Backups and media storage

Things go wrong with hardware and software, resulting in wrecked or unreachable data. When it’s gone, it’s gone! Thus IT departments everywhere make copies of their critical data on tapes, removable discs, or external storage systems, or in the cloud.

These backups must be performed regularly, usually once per day. For organizations with on-premises systems, backup media must also be stored off-site in the event that the facility housing the original systems is damaged. Having backup tapes in the data center may be convenient for doing a quick data restore but of little value if backup tapes are destroyed along with their respective systems. For organizations with cloud-based systems, the problem here is the same, but the technology differs a bit: It is imperative that data be backed up (or replicated) to a different geographic location, so that data can be recovered, no matter what happens.

For systems with large amounts of data, that data must be well understood in order to determine what kinds of backups need to be performed (real-time replication, full, differential, and incremental) and how frequently. Consider these factors:

• The time that it takes to perform backups.
• The effort required to restore data.
• The procedures for restoring data from backups, compared with other methods for recovering the data.

For example, consider whether you can restore application software from backup tapes more quickly than by installing them from their release media (the original CD-ROMs or downloaded install files). Just make sure you can recover your configuration settings if you re-install software from release media. Also, if a large part of the database is static, do you really need to back it all up every day?

You must choose off-site storage of backup media and other materials (documentation, and so on) carefully. Factors to consider include survivability of the off-site storage facility, as well as the distance from the off-site facility to the data center, media transportation, and alternate processing sites. The facility needs to be close enough so that media retrieval doesn’t take too long (how long depends on the organization’s recovery needs), but not so close that the facility becomes involved in the same natural disaster as the business.

Cloud-based data replication and backup services are a viable alternative to off-site backup media storage. Today’s Internet speeds make it possible to back up critical data to a cloud-based storage provider — often faster than magnetic tapes can be returned from an off-site facility and data recovered from them.

Some organizations have one or more databases so large that the organizations literally can’t (or, at any rate, don’t) back them up to tape. Instead, they keep one or more replicated copies of their databases on other computers in other cities. Business continuity planners need to consider this possibility when developing continuity plans.

The purpose of off-site media storage is to ensure that up-to-date data is available in the event that systems in the primary data center are damaged.

Software escrow agreements

Your organization should consider software escrow agreements (wherein the software vendor sends a copy of its software code to a third-party escrow organization for safekeeping) with the software vendors whose applications support critical business functions. In the event that an insurmountable disaster (which could include bankruptcy) strikes the software vendor, your organization must consider all options for the continued maintenance of those critical applications, including in-house support.

External communications

The Corporate Communications, External Affairs, and (if applicable) Investor Relations departments should all have plans in place for communicating the facts about a disaster to the press, customers, and public. You need contingency plans for these functions if you want the organization to continue communicating to the outside world. Open communication during a disaster is vital so that customers, suppliers, and investors don’t panic (which they might do if they don’t know the true extent of the disaster).

The emergency communications plan needs to take into account the possibility that some corporate facilities or personnel may be unavailable. Thus you need to keep even the data and procedures related to the communications plan safe so that they’re available in any situation.

Utilities

Data-processing facilities that support time-critical business functions must keep running in the event of a power failure. Although every situation is different, the principle remains the same: The business continuity planning team must determine for what period of time the data-processing facility must be able to continue operating without utility power. A power engineer can find out the length of typical (we don’t want to say routine) power outages in your area and crunch the numbers to arrive at the mean time of outages. By using that information, as well as an inventory of the data center’s equipment and environmental equipment, you can determine whether the organization needs an uninterruptible power supply (UPS) alone, or a UPS and an electric generator.

A business can use uninterruptible power supplies (UPSs) and emergency electric generators to provide electric power during prolonged power outages. A UPS is also good for a controlled shutdown, if the organization is better off having their systems powered off during a disaster. A business can also use a stand-alone power system (SPS), another term for an off-the-grid system that generates power with solar, wind, hydro, or employees madly pedaling stationary bicycles (we’re kidding about that last one).

In a really long power outage (more than a day or two), it is also essential to have a plan for the replenishment of generator fuel.

Logistics and supplies

The business continuity planning team needs to study every aspect of critical functions that must be made to continue in a disaster. Every resource that’s needed to sustain the critical operation must be identified and then considered against every possible disaster scenario to determine what special plans must be made. For instance, if a business operation relies upon a just-in-time shipment of materials for its operation and an earthquake has closed the region’s only highway (or airport or sea/lake port), then alternative means for acquiring those materials must be determined in advance. Or, perhaps an emergency ration of those materials needs to be stockpiled so that the business function can continue uninterrupted.

Fire and water protection

Many natural disasters disrupt public utilities, including water supplies or delivery. In the event that a disaster has interrupted water delivery, new problems arise. Your facility may not be allowed to operate without the means for fighting a fire, should one occur.

In many places, businesses could be ordered to close if they can’t prove that they can effectively fight a fire using other means, such as FM-200 inert gas. Then again, if water supplies have been interrupted, you have other issues to contend with, such as drinking water and water for restrooms. Without water, you’re hosed!

We discuss fire protection in more detail in Chapter 5.

Documentation

Any critical business function must be able to continue operating after a disaster strikes. And to make sure you can sustain operations, you need to make available all relevant documentation for every critical piece of equipment, as well as every critical process and procedure that the organization performs in a given location.

Don’t be lulled into taking for granted the emerging trend of hardware and software products that don’t come with any documentation. Many vendors deliver their documentation only over the Internet, or they charge extra for a hard copy. But many types of disasters may disrupt Internet communications, thereby leaving an operation high and dry with no instructions for how to use and manage tools or applications.

At least one set of hard copy (or CD-ROM soft copy) documentation — including your BCP and Disaster Recovery Plan (DRP) — should be stored at the same off-site storage facility that stores the organization’s backup tapes. It would also be smart to issue electronic copies of BCP and DRP documentation to all relevant personnel on USB storage devices (with encryption).

If the preceding sounds like the ancient past to you, then your organization may be fully in the cloud today. In such a case, you may be more inclined to maintain multiple soft copies of all required documentation so that personnel can use it when needed.

Continuity and recovery documentation must exist in hard copy in the event that it’s unavailable via electronic means.

Data processing continuity planning

Data processing facilities are so vital to businesses today that a lot of emphasis is placed on them. Generally, this comes down to these variables: where and how the business will continue to sustain its data processing functions.

Because data centers are so expensive and time-consuming to build, better business sense dictates having an alternate processing site available. The types of sites are

• Cold site: A cold site is basically an empty computer room with environmental facilities (UPS; heating, ventilation, and air conditioning [HVAC]; and so on) but no computing equipment. This is the least-costly option, but more time is required to assume a workload because computers need to be brought in from somewhere and set up, and data and applications need to be loaded. Connectivity to other locations also needs to be installed.
• Warm site: A warm site is basically a cold site, but with computers and communications links already in place. In order to take over production operations, you must load the computers with application software and business data.
• Hot site: Indisputably the most expensive option, you equip a hot site with the same computers as the production system, with application changes, operating system changes, and even patches kept in sync with their live production-system counterparts. You even keep business data up-to-date at the hot site by using some sort of mirroring or transaction replication. Because the organization trains its staff in how to operate the organization’s business applications (and staff members have documentation), the operations staff knows what to do to take over data processing operations at a moment’s notice. Hot sites may be cloud-based or in a co-location center.
• Reciprocal site: Your organization and another organization sign a reciprocal agreement in which you both pledge the availability of your organization’s data center in the event of a disaster. Back in the day, when data centers were rare, many organizations made this sort of arrangement, but it’s fallen out of favor in recent years.
• Multiple data centers: Larger organizations can consider the option of running daily operations out of two or more regional data centers that are hundreds (or more) of miles apart. The advantage of this arrangement is that the organization doesn’t have to make arrangements with outside vendors for hot/warm/cold sites, and the organization’s staff is already onsite and familiar with business and computer operations.
• Cloud site: Organizations with primary information processing in the cloud are likely to employ cloud assets in multiple regions, and possibly with more than one cloud provider. Many organizations with primary processing on-premises employ hybrid cloud infrastructure for disaster recovery purposes — this is a common way for companies to ease their way into the cloud. Depending on the degree of readiness required, a cloud site can be as ready as a hot site, a warm site, or a cold site, as determined by the resources devoted to keeping the cloud site ready for production operations.

A hot site provides the most rapid recovery capability, but it also costs the most because of the effort required to maintain its readiness.

Table 3-1 compares these options side by side.

Vulnerability Assessment

Often, a BIA includes a Vulnerability Assessment that helps get a handle on obvious and not-so-obvious weaknesses in business critical systems. A Vulnerability Assessment has quantitative (financial) and qualitative (operational) sections, similar to a Risk Assessment, which is covered later in this chapter.

The purpose of a Vulnerability Assessment is to determine the impact — both quantitative and qualitative — of the loss of a critical business function.

Quantitative losses include

• Loss of revenue
• Loss of operating capital
• Market share
• Loss because of personal liabilities
• Increase in expenses
• Penalties because of violations of business contracts
• Violations of laws and regulations (which can result in legal costs such as fines and civil penalties)

Qualitative losses include loss of

• Service quality
• Competitive advantages
• Customer satisfaction
• Prestige and reputation

The Vulnerability Assessment identifies critical support areas, which are business functions that, if lost, would cause significant harm to the business by jeopardizing critical business processes or the lives and safety of personnel. The Vulnerability Assessment should carefully study critical support areas to identify the resources that those areas require to continue functioning.

Quantitative losses include an increase in operating expenses because of any higher costs associated with executing the contingency plan. In other words, planners need to remember to consider operating costs that may be higher during a disaster situation.

Criticality Assessment

The business continuity planning team should inventory all high-level business functions (for example, customer support, order processing, returns, cash management, accounts receivable, payroll, and so on) and rank them in order of criticality. The team should also describe the impact of a disruption to each function on overall business operations.

The team members need to estimate the duration of a disaster event to effectively prepare the Criticality Assessment. Project team members need to consider the impact of a disruption based on the length of time that a disaster impairs specific critical business functions. You can see the vast difference in business impact of a disruption that lasts one minute, compared to one hour, one day, one week, or longer. Generally, the criticality of a business function depends on the degree of impact that its impairment has on the business.

Planners need to consider disasters that occur at different times in the business cycle, whatever that might be for an organization. Response to a disaster at the busiest time of the month (or year) may vary quite a bit from response at other times.

Identifying key players

Although you can consider a variety of angles when evaluating vulnerability and criticality, commonly you start with a high-level organization chart. (Hip people call this chart the org chart). In most companies, the major functions pretty much follow the structure of the organization.

Following an org chart helps the business continuity planning project team consider all the steps in a critical process. Walk through the org chart, stopping at each manager’s or director’s position and asking, “What does he do?”, “What does she do?”, and “Who files the TPS reports?” This mental stroll can help jog your memory, and help you better see all the parts of the organization’s big picture.

When you’re cruising an org chart to make sure that it covers all areas of the organization, you may easily overlook outsourced functions that might not show up in the org chart. For instance, if your organization outsources accounts payable (A/P) functions, you might miss this detail if you don’t see it on an org chart. Okay, you’d probably notice the absence of all A/P. But if your organization outsources only part of A/P — say, a group that detects and investigates A/P fraud (looking for payment patterns that suggest the presence of phony payment requests) — your org chart probably doesn’t include that vital function.

Establishing Maximum Tolerable Downtime (MTD)

An extension of the Criticality Assessment (which we talk about in the section “Criticality Assessment,” earlier in this chapter) is a statement of Maximum Tolerable Downtime (MTD — also known as Maximum Tolerable Period of Disruption or MTPD) for each critical business function. Maximum Tolerable Downtime is the maximum period of time that a critical business function can be inoperative before the company incurs significant and long-lasting damage.

For example, imagine that your favorite online merchant — a bookseller, an auction house, or an online trading company — goes down for an hour, a day, or a week. At some point, you have to figure that a prolonged disruption sinks the ship, meaning the business can’t survive. Determining MTD involves figuring out at what point the organization suffers permanent, measurable loss as a result of a disaster. Online retailers know that even short outages may mean that some customers will switch brands and take their business elsewhere.

Make the MTD assessment a major factor in determining the criticality — and priority — of business functions. A function that can withstand only two hours of downtime obviously has a higher priority than another function that can withstand several days of downtime.

MTD is a measure of the longest period of time that a critical business function can be disrupted without suffering unacceptable consequences, perhaps threatening the actual survivability of the organization.

Determining Maximum Tolerable Outage (MTO)

During the Criticality Assessment, you establish a statement of Maximum Tolerable Outage (MTO) for each critical business function. Maximum Tolerable Outage is the maximum period of time that a critical business function can be operating in emergency or alternate processing mode. This matters because, in many cases, emergency or alternate processing mode performs at a lower level of throughput or quality, or at a higher cost. Although an organization’s survival can be assured through an interim period in alternate processing mode, the long-term business model may not be able to sustain the differences in throughput, quality, cost, or whatever aspects of alternate processing mode are different from normal processing.

Establish recovery targets

When you establish the Criticality Assessment, MTD, and MTO for each business process (which we talk about in the preceding sections), the planning team can establish recovery targets. These targets represent the period of time from the onset of a disaster until critical processes have resumed functioning.

Two primary recovery targets are usually established for each business process: a Recovery Time Objective (RTO) and Recovery Point Objective (RPO). We discuss these targets in the following sections.

Defining Resource Requirements

The Resource Requirements portion of the BIA is a listing of the resources that an organization needs in order to continue operating each critical business function. In an organization that has finite resources (which is pretty much every organization), the most critical functions get first pick, and the lower-priority functions get the leftovers.

Understanding what resources are required to support a business process helps the project team to figure out what the contingency plan for that process needs to contain, and how the process can be operated in Emergency mode and then recovered.

Examples of required resources include

• Systems and applications: In order for a business process to continue operating, it may require one or more IT systems or applications — not only the primary supporting application, but also other systems and applications that the primary application requires in order to continue functioning. Depending on the nature of the organization’s primary and alternate processing resources, these systems may be physical, virtual, or cloud-based.
• Suppliers and partners: Many business processes require a supply of materials or services from outside organizations, without which the business process can’t continue operating.
• Key personnel: Most business processes require a number of specifically trained or equipped staff members — or contingent workers such as contractors or personnel from another company — to run business processes and operate systems.
• Business equipment: Anything from PBXs to copiers, postage machines, POS (point-of-sale) machines, red staplers, and any other machinery required to support critical business processes.

When you identify required resources for complex business processes, you may want to identify additional information about each resource, including resource owners, criticality, and dependencies.

Making your business continuity planning project a success

For the important and time-consuming Continuity Strategy phase of the project, you need to follow these guidelines:

• Call things like you see them. No biases. No angles. No politics. No favorites. No favors. You’re trying to ensure survival of the business before the disaster strikes.
• Build smaller teams of experts. Each critical business function should have teams dedicated to just that function. That team’s job is to analyze just one critical business function and figure out how you can keep it functioning despite a disaster of some sort. Pick the right people for each team — people who really understand the details of the business process that they’re examining.
• Brainstorm. Proper brainstorming considers all ideas, even silly ones (up to a point). Even a silly-sounding idea can lead to a good idea.
• Have teams share results with each other. Teams working on individual continuity strategies can get ideas from each other. Each team can share highlights of its work over the past week or two. Some of the things that they say may spark ideas in other teams. You can improve the entire effort by holding these sharing sessions.
• Don’t encourage competition or politics in or between teams. Don’t pit teams against each other. Identifying success factors isn’t a zero-sum game: Everyone needs to do an excellent job.
• Retain a business continuity planning mentor/expert. If your organization doesn’t have experienced business continuity planners on staff, you need to bring in a consultant — someone who has helped develop plans for other organizations. Even more important than that, make sure the consultant you hire has been on the scene when disaster struck a business he or she was consulting for and has seen a BCP in action.

Simplifying large or complex critical functions

Some critical business functions may be too large and complex to examine in one big chunk. You can break down those complex functions into smaller components, perhaps like this:

• People: Has the team identified the critical people — or more appropriately, the critical sub-functions — required to keep the function running?
• Facilities: In the event that the function’s primary facilities are unavailable, where can the business perform the function?
• Technology: What hardware, software, and other computing/network components support the critical function? If parts or all of these components are unavailable, what other equipment can support the critical business functions? Do you need to perform the functions any differently?
• Miscellaneous: What supplies, other equipment, and services do you need to support the critical business function?

Analyzing processes is like disassembling toy building block houses — you have to break them down to the level of their individual components. You really do need to understand each step in even the largest processes in order to be able to develop good continuity plans for them.

If a team that analyzes a large complex business function breaks it into groups, such as the groups in the preceding list, the team members need to get together frequently to ensure that their respective strategies for each group eventually become a cohesive whole. Eventually these groups need to come back together and integrate their separate materials into one complete, cohesive plan.

Documenting the strategy

Now for the part that everyone loves: documentation. The details of the continuity plans for each critical function must be described in minute detail, step by step by step.

Why? The people who develop the strategy may very well not be the people who execute it. The people who develop the strategy may change roles in the company or change jobs altogether. Or the scope of an actual disaster may be wide enough that the critical personnel just aren’t available. Any skeptics should consider September 11 and the impact that this disaster had on a number of companies that lost practically everyone and everything.

Best practices for documenting BCPs exist. For this reason, you may want to have an expert around. For $300 an hour, a consultant can spend a couple of weeks developing templates. But watch out — your consultant might just download templates from a business continuity planning website, tweak them a little bit, and spend the rest of his or her time playing Candy Crush. To be sure you get a solid consultant, do the old-fashioned things: check his references, ask for work samples, see if he has a decent LinkedIn page. (We’re kidding about that last one!)

Securing senior management approval

After the entire plan has been documented and reviewed by all stakeholders, it’s time for senior management to examine it and approve it. Not only must senior management approve the plan, but senior management must also publicly approve it. By “public” we don’t mean the general public; instead, we mean that senior management should make it well known inside the business that they support the business continuity planning process.

Senior management’s approval is needed so that all affected and involved employees in the organization understand the importance of emergency planning.

Promoting organizational awareness

Everyone in the organization needs to know about the plan and his or her role in it. You may need to establish training for potentially large numbers of people who need to be there when a disaster strikes.

All employees in the organization must know about the BCP.

Testing the plan

Regularly testing the BCP ensures that all essential personnel required to implement the plan understand their roles and responsibilities, and helps to ensure that the plan is kept up to date as the organization changes. BCP testing methods are similar to DRP testing methods (discussed in Chapter 9), and include

• Read-through
• Walkthrough
• Simulation
• Parallel
• Full interruption

See Chapter 9 for a full explanation of these testing methods.

Maintaining the plan

No, the plan isn’t finished. It has just begun! Now the business continuity planning person (the project team members by this time have collected their commemorative denim shirts, mugs, and mouse pads, and have moved on to other projects) needs to periodically chase The Powers That Be to make sure that they know about all significant changes to the environment.

In fact, if the business continuity planning person has any leadership left at this point in the process, he or she needs to start attending the Change Control Board and IT Steering Committee (or whatever that company calls them) meetings and to jot down notes that may mean that some detail in a BCP document may need some changes.

The BCP is easier to modify than it is to create out of thin air. Once or twice each year, someone knowledgeable needs to examine the detailed strategy and procedure documents in the BCP to make sure that they’ll still work — and update them if necessary.

You can read more about business continuity and disaster recovery planning in IT Disaster Recovery Planning For Dummies, by Peter H. Gregory.

Risk assessment

A risk assessment begins with risk identification — detecting and defining specific elements of the three components of risk: assets, threats, and vulnerabilities.

The process of risk identification occurs during a risk assessment.

Risk analysis

The next element in risk management is risk analysis — a methodical examination that brings together all the elements of risk management (identification, analysis, and control) and is critical to an organization for developing an effective risk management strategy.

Risk analysis involves the following four steps:

1. Identify the assets to be protected, including their relative value, sensitivity, or importance to the organization.

   This component of risk identification is asset valuation.

2. Define specific threats, including threat frequency and impact data.

   This component of risk identification is threat analysis.

3. Calculate Annualized Loss Expectancy (ALE).

   The ALE calculation is a fundamental concept in risk analysis; we discuss this calculation later in this section.

4. Select appropriate safeguards.

   This process is a component of both risk identification (vulnerability assessment) and risk control (which we discuss in the section “Risk control,” later in this chapter).

The Annualized Loss Expectancy (ALE) provides a standard, quantifiable measure of the impact that a realized threat has on an organization’s assets. Because it’s the estimated annual loss for a threat or event, expressed in dollars, ALE is particularly useful for determining the cost-benefit ratio of a safeguard or control. You determine ALE by using this formula:

SLE × ARO = ALE

Here’s an explanation of the elements in this formula:

• Single Loss Expectancy (SLE): A measure of the loss incurred from a single realized threat or event, expressed in dollars. You calculate the SLE by using the formula Asset value × Exposure Factor (EF).

  Exposure Factor (EF) is a measure of the negative effect or impact that a realized threat or event would have on a specific asset, expressed as a percentage.

• Annualized Rate of Occurrence (ARO): The estimated annual frequency of occurrence for a threat or event.

The two major types of risk analysis are qualitative and quantitative, which we discuss in the following sections.

Control assessment approach

There are various approaches to security control assessments (SCA), including:

• Control self assessment. Here, an organization examines its own controls to determine whether they are being followed and whether they are effective.
• External assessment. An organization employs an external agency (which could be a different part of the organization, or an external entity such as an audit firm or a consulting firm) to assess its controls.
• Variations in assessment frequency. Various circumstances will compel an organization to set schedules for control assessment. For example, highly critical controls may be assessed monthly or quarterly, other controls assessed annually, and low-risk controls assessed every other year.

Organizations often take a blended approach to control assessment: some controls may be assessed internally, others externally. There may be a mix of the two; some controls are assessed both internally and externally.

Laws, regulations, and standards often have requirements dictating the frequency of control assessment, as well as whether controls must be assessed internally or externally.

Control assessment methodology

It would take an entire book (a long chapter, anyway) to detail the methods used to assess controls. Most of this subject matter lies outside the realm of most CISSPs, so we’ll just summarize here. If you are “fortunate” enough to work in a highly regulated environment, you may get exposure to these concepts, and more.

Risk assessment frameworks

Risk assessment frameworks are methodologies used to identify and assess risk in an organization. These methodologies are, for the most part, mature and well established.

Some common risk assessment methods include

• Factor Analysis of Information Risk (FAIR). A proprietary framework for understanding, analyzing, and measuring information risk.
• OpenFAIR. An open-source version of FAIR.
• Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE). Developed by the CERT Coordination Center.
• Threat Agent Risk Assessment (TARA). Developed by Intel, this is a newer kid on the block.

Risk management frameworks

A risk framework is a set of linked processes and records that work together to identify and manage risk in an organization. The activities in a typical risk management framework are

• Create strategies and policies.
• Establish risk tolerance.
• Categorize systems and information.
• Select a baseline set of security controls.
• Implement security controls.
• Assess security controls for effectiveness.
• Authorize system operation.
• Monitor security controls.

There is no need to build a risk management framework from scratch. Instead, there are several excellent frameworks available that can be adapted for any size and type of organization. These frameworks include

• NIST SP800-37, Guide for Applying the Risk Management Framework to Federal Information Systems.
• ISO/IEC 27005 (Information Security Risk Management).
• Risk Management Framework (RMF) from the National Institute of Standards and Technology (NIST).
• COBIT 5 from ISACA.
• Enterprise Risk Management — Integrated Framework from COSO (Committee of Sponsoring Organizations of the Treadway Commission).

Awareness

A general security awareness program provides basic security information and ensures that everyone understands the importance of security. Awareness programs may include the following elements:

• Indoctrination and orientation: New employees and contractors should receive basic indoctrination and orientation. During the indoctrination, they may receive a copy of the corporate information security policy, be required to acknowledge and sign acceptable-use statements and non-disclosure agreements, and meet immediate supervisors and pertinent members of the security and IT staff.
• Presentations: Lectures, video presentations, and interactive computer-based training (CBTs) are excellent tools for disseminating security training and useful information. Employee bonuses and performance reviews are sometimes tied to participation in these types of security awareness programs.
• Printed materials: Security posters, corporate newsletters, and periodic bulletins are useful for disseminating basic information such as security tips and promoting awareness of security.

Training

Formal training programs provide more in-depth information than an awareness program and may focus on specific security-related skills or tasks. Such training programs may include

• Classroom training: Instructor-led or other formally facilitated training, possibly at corporate headquarters or a company training facility.
• Self-paced training: Usually web-based training where students can proceed at their own pace.
• On-the-job training: May include one-on-one mentoring with a peer or immediate supervisor.
• Technical or vendor training: Training on a specific product or technology provided by a third party.
• Apprenticeship or qualification programs: Formal probationary status or qualification standards that must be satisfactorily completed within a specified time period.

Education

An education program provides the deepest level of security training, focusing on underlying principles, methodologies, and concepts. In all but the largest organizations, this training is delivered by external agencies, as well as colleges, universities, and vocational schools.

An education program may include

• Continuing education requirements: Continuing Education Units (CEUs) are becoming popular for maintaining high-level technical or professional certifications such as the CISSP or Certified Information Systems Auditor (CISA).
• Certificate programs: Many colleges and universities offer adult education programs that have classes about current and relevant subjects for working professionals.
• Formal education or degree requirements: Many companies offer tuition assistance or scholarships for employees enrolled in classes that are relevant to their profession.