This chapter covers Certified Information Security Manager (CISM) Domain 3, “Information Security Program,” part A, “Information Security Program Development.” The entire Information Security Program domain represents 33 percent of the CISM examination.

Supporting Tasks in the CISM job practice that align with the Information Security Program / Information Security Program Development domain include:

5.   Establish and maintain information security policies to guide the development of standards, procedures, and guidelines.

10.   Evaluate and report information security metrics to key stakeholders.

11.   Establish and/or maintain the information security program in alignment with the information security strategy.

12.   Align the information security program with the operational objectives of other business functions.

13.   Establish and maintain information security processes and resources to execute the information security program.

14.   Establish, communicate, and maintain organizational information security policies, standards, guidelines, procedures, and other documentation.

20.   Establish and/or maintain a process for information asset identification and classification.

Establishing and modernizing an organization’s cybersecurity program is one of the most impactful activities with long-term benefits (and consequences) a security leader will undertake. Cybersecurity program improvements are implemented as a result of a strategic plan, discussed in Chapter 2. Cybersecurity program development consists of creating policies, controls, standards, requirements, guidelines, and a formal structure for security functions described in separate charters. Security leaders can choose from one of several frameworks that describe the structure of a security program. Security leaders use metrics to measure events and activities, enabling senior management to see the results of their directives.

Information Security Program Resources

Information security programs comprise a collection of activities used to identify, communicate, and address risks. The security program consists of controls, processes, and practices intended to increase the resilience of the computing environment and ensure that risks are known and handled effectively. These activities may be handled by a single individual in a smaller organization, while larger organizations will have a security leader that leads an internal team. Organizations of all sizes may have additional support from external partners as needed.

Security program models have been developed that include the primary activities needed in any organization’s security program. However, because every organization is different, each security manager needs to understand their particular organization’s internal workings so that their security programs can effectively align with the organization’s operations, practices, and culture.

The activities in an information security program serve to operationalize the security manager’s vision for effective security and risk management in the organization. Generally, a security manager’s vision focuses on how the security program aligns with and supports the business.

Trends

Fueled by the sharp increase in the number and impact of ransomware attacks on private organizations and government agencies, cybersecurity is getting more attention in the media and boardrooms than in the past. The United States and other countries have been issuing advisories, directives, and edicts and enacting new laws and regulations requiring greater transparency of security incidents, and many are requiring that one or more board members have cybersecurity experience.

Further, the Cyber Incident Reporting for Critical Infrastructure Act of 2022 expands on Executive Order 14208 by requiring all critical infrastructure owners and operators (whether they contract with the federal government or not) to submit reports of cybersecurity incidents and ransomware payments to CISA. Also, many U.S. states have passed privacy laws, and there is a possibility of a federal law on privacy being enacted.

While more organizations recognize cybersecurity’s strategic nature and enabling characteristics, more security leaders are considered “real” C-level executives. However, numerous organizations still consider cybersecurity as nonstrategic and tactical. Security and privacy are often not a part of the initial design of new products and services, because security is still seen not as a business enabler but as an impediment. But cybersecurity is regarded as unimportant, until it is. Often, only a serious security breach will change this mindset among executives.

Outcomes

The primary outcome of a security program is the realization of its strategy, goals, and objectives, as discussed in Chapter 2. When a strategy is aligned with the business and its risk tolerance and operations, the organization’s security program will act as a business enabler, allowing it to consider new business ventures while being fully aware of associated risks that can be mitigated or accepted. Like the brakes on a race car that enable it to maneuver more quickly, an effective security program helps the organization embark on new ventures, knowing that the security program acts as the organization’s brakes that allow it to adjust effectively to keep it on the road.

The outcomes that should be part of any information security program include the following:

•   Strategic alignment   The program needs to align with and work in harmony with the rest of the organization. This includes being aware of—and supporting—all new business initiatives, developing risk tolerance criteria that business leaders agree with, and working daily with business leaders to establish mutual trust. Better security programs utilize a security council or governance committee consisting of stakeholders from across the business; this helps ensure that information security activities work with the business instead of against it.

•   Risk management   An effective security program includes an effective risk management program that identifies risks and facilitates desired outcomes through appropriate risk treatment.

•   Value delivery   An effective information security program delivers value to the organization. This is most often achieved by aligning security activities directed toward risk reduction in the organization’s most critical activities. Effectively and efficiently reducing risk to an acceptable level is another key part of value delivery.

•   Resource management   An information security program’s primary objective is risk management and risk reduction. This requires resources in the form of permanent and temporary staff, external service providers, and tools. These resources must be managed so that they are used effectively to reduce risks in alignment with the risk management program. Additionally, efficiently using resources will assist security managers in “rightsizing” the information security budget and spending. This will lead to greater confidence in the business regarding “resource requests” from the security manager.

•   Performance management   As a security program is developed and implemented, key activities need to be measured to ensure that they are operating as planned. Security metrics are used to measure and report key activities to management.

•   Assurance process integration   An effective information security program is aligned with other assurance processes and programs in an organization, including human resources, finance, legal, audit, enterprise risk management, information technology, and operations. Further, a security program should influence these activities to protect them adequately from harm.

Charter

A charter is a formal, written definition of the objectives of a program, its main timelines, the sources of funding, the names of its principal leaders and managers, and the business executives sponsoring the program. In many organizations, a program charter document is approved by the CEO or other executive leader that gives authority to the person or group that runs the program. The charter also demonstrates the support from the executive leadership team.

An information security program charter gives authority to the security leader to develop and/or perform several functions, including the following:

•   Develop and enforce security policy.

•   Develop and implement the risk management process.

•   Develop and manage security governance.

•   Develop and direct the implementation and operation of controls across department or business unit boundaries.

•   Develop and direct the implementation of key security processes, including vulnerability management, incident management, third-party risk, security architecture, business continuity planning, and security awareness training.

Information security in an organization of any size is a team sport. The security manager (with or without staff) does not perform security functions alone; rather, these activities involve nearly every other department, business unit, and affiliate in the organization. For this reason, the security charter must be ratified by executive management.

A security charter that designates the security manager as the person responsible for implementing the program does not give the security manager the right to dictate the program to others. As is stated numerous times in this book, a security management program may be led and guided by the security manager, but it will be effective and successful only through collaboration and consensus by stakeholders across the business. For this reason, it may be appropriate to say that a charter empowers the security manager to be a facilitator of security in the organization. Another key element that should be understood is that although the security manager is the facilitator of the program, the ultimate responsibility or ownership for protecting information is at the executive leadership and board of directors levels. The security charter gives the security leader authority to design and operate the program, but accountability is shared between the security leader and the executive leadership team and board of directors.

Scope

An early step in the creation of an information security program is the definition of its scope. Management needs to define the departments, business units, affiliates, and locations to be included in the organization’s information security program. The scope of a program is essential, because it defines the boundaries and what parts of the organization are to be included and subject to information security governance and policy.

The discussion of scope is generally more relevant in larger organizations with autonomous business units or affiliates. In larger organizations, business units or affiliates may have programs of their own, which may be defined as part of a larger security program or may be entirely autonomous. If the scope of a security program is defined as “headquarters only” in an organization with autonomous business units, this does not mean there is no interaction between the headquarters security program and business unit security programs. For instance, there may be a single set of policies for all entities, but separate processes, personnel, and standards in each business unit.

There is no right or wrong way to define the relationship between two or more security programs in an organization. Rather, management needs to be aware of factors that represent similarities and differences between parts of larger organizations that will help them define the scope to result in effective security management throughout the organization. This is sometimes easier said than done, particularly in cases where the scope of security programs and IT departments differ.

Information Security Processes

Information security programs include numerous business processes that fulfill the overall mission of information and information systems protection. These processes fall into three major categories: risk and compliance, architecture, and operations.

Risk and compliance processes often include the following:

•   Risk assessments and risk management

•   Security policy management

•   Security controls management

•   Requirements development

•   Compliance monitoring

•   Data classification and handling

•   Third-party risk management

•   Contingency planning

•   Access governance

•   Security awareness training

•   Privacy (which can also be entirely separate from information security as a standalone program)

Architecture processes often include these:

•   Reference architecture development (both on-premises and cloud)

•   Architecture reviews

•   Technical standards

Security operations processes often include the following:

•   Security event logging and monitoring

•   Security incident response

•   Forensics

•   Vulnerability management

•   Penetration testing (often outsourced as individual projects)

•   Threat intelligence

•   Identity and access management

Information Security Technologies

Modern information security includes essential business processes such as risk and policy management, but overall, it is also heavily involved in information technology. After all, information security’s mission is the protection of all things IT. To scale with the power and speed of IT, information security has its own portfolio of protective and detective technologies that include the following:

•   Foundation technologies

•   TCP/IP internals

•   Operating systems internals

•   Middleware

•   Applications and tools

•   Endpoint protection

•   Antimalware

•   Firewalls

•   Patch and configuration management

•   Host-based intrusion detection systems (HIDSs)

•   Mobile device management (MDM)

•   Mobile application management (MAM)

•   Secure access service edge (SASE)

•   Network protection

•   Antimalware

•   Firewalls

•   Patch and configuration management

•   Intrusion detection systems (IDSs/NIDSs)

•   Intrusion prevention systems (IPSs)

•   Web content filtering

•   Cloud access security brokers (CASBs)

•   Spam and phishing filtering

•   Remote access and virtual private networks (VPNs)

•   Data protection

•   Data loss prevention (DLP)

•   Backup, replication, snapshots, and vaulting

•   Removable storage monitoring and management

•   Encryption and digital signatures

•   Fingerprinting, tagging, and watermarking

•   Identity and access management

•   Password vaults

•   Privileged access gateways

•   Multifactor authentication (MFA)

•   Federated identity (OAuth, FIDO Alliance, and so on)

•   Event management

•   Centralized logging

•   Security information and event management (SIEM) systems

•   Threat intelligence platforms (TIPs)

•   Security orchestration, automation, and response (SOAR)

•   Vulnerability management

•   Security scanning

•   Penetration testing

•   Social engineering testing

•   Systems and software development

•   Dynamic application security testing (DAST)

•   Static application security testing (SAST)

•   Penetration testing

•   Code review

•   Governance, risk, and compliance

•   Governance, risk, and compliance (GRC) platform

•   Integrated risk management (IRM) platform

The information security leader does not need to have expertise in all of these technologies. Further, some of these technologies are managed outside of information security, such as IT or product development. That said, information security needs to employ risk management to identify whether controls and technologies in these and other areas adequately reduce risk and to ensure that there are staff members in the organization who understand their architecture, implementation, and operation.

Information Asset Identification and Classification

Assets are the things of value that an organization protects in an information security program. They consist of tangible things, including the following:

•   Information systems hardware   Servers, laptops, tablets, mobile devices, and network devices of various sorts

•   Software   Operating systems, subsystems, applications, and tools—regardless of location

•   Virtual assets   Operating system guests, containers, and so on

•   Information   Structured databases and unstructured data

•   Facilities   Data centers, development centers, operations centers, business offices, sales offices, retail locations, and so on

•   Personnel   Staff, contractors, temporary workers

Asset Identification and Valuation

After security leadership has determined the scope of the security program, an initial step of program development is the identification of assets and a determination of each asset’s value. In a typical organization, assets consist of information and the information systems that support and protect those information assets.

Hardware Assets

Hardware assets may include server and network hardware, user workstations, office equipment such as printers and scanners, and Wi-Fi access points. Depending on the scope of the risk assessment, assets in storage and replacement components may also be included.

Accurately identifying hardware assets can be challenging, and many organizations do a subpar job of building and maintaining inventory information. Accounting may have asset inventory in its accounting system, but this would not account for assets not in use or retired assets reverted to storage. Further, asset inventory in accounting often does not cite the business applications they support. Tools used by IT for security scans or patch management are another source of inventory information, although these are often incomplete for many reasons. Even purpose-made asset inventory systems are plagued with inaccuracies, because maintaining the data is not always a high priority.

An organization responsible for managing information and information systems must know what its assets are. More than that, IT needs to acquire and track several characteristics of every asset, including the following:

•   Identification   This includes the make, model, serial number, asset tag number, logical name, and other means for identifying the asset.

•   Value   Initially, this may signify the purchased value, but it may also include its depreciated value if an IT asset management program is associated with the organization’s financial asset management program.

•   Location   The asset’s location needs to be specified so that its existence may be verified in a periodic inventory.

•   Security classification   Security management programs almost always include a plan for classifying the sensitivity of information and/or information systems. Example classifications include secret, restricted, confidential, and public.

•   Asset group   IT assets may be classified into a hierarchy of asset groups. For example, servers in a data center that support a large application may be assigned to an asset group known as “Application X Servers.”

•   Owner   This is usually the person or group responsible for the operation of the asset.

•   Custodian   Occasionally, the ownership and operations of assets will be divided into two bodies, where the owner owns them but a custodian operates or maintains them.

Because hardware assets are installed, moved, and eventually retired, it is important to verify the information in the asset inventory periodically by physically verifying the existence of the physical assets. Depending upon the value and sensitivity of systems and data, this inventory “true-up” may be performed as often as monthly or as seldom as once per year. Discrepancies in actual inventory must be investigated to verify that assets have not been moved without authorization or stolen.

Subsystem and Software Assets

Software applications such as software development tools, drawing tools, security scanning tools, and subsystems such as application servers and database management systems are all considered assets. Like physical assets, software assets have tangible value and should be periodically inventoried. Some of the purposes for inventorying software include license agreement compliance, business continuity planning, and disaster recovery planning. If an organization tracks the return on investment of information systems, then, certainly, the value of software assets makes up the whole of the assets that support or enable key business processes and activities.

Information Assets

Information assets are less tangible than hardware assets, because they are not easily observed. Information assets take many forms:

•   Customer information   Most organizations store information about people, whether employees, customers, constituents, beneficiaries, or citizens. The information may include sensitive information such as contact information and personal details, transactions, order history, and other details.

•   Intellectual property   This type of information can take the form of trade secrets, source code, product designs, policies and standards, and marketing collateral.

•   Business operations   This generally includes merger and acquisition information and other types of business processes and records not mentioned earlier.

•   Virtual assets   Most organizations are moving their business applications to the cloud, eliminating the need to purchase hardware. Organizations that use infrastructure as a service (IaaS) have virtual operating systems that are another form of information. Even though IaaS operating systems are not purchased, but rented or leased, there is nonetheless an asset perspective: they take time to build and configure and therefore have a replacement cost. The value of assets is discussed more fully later in this section.

Cloud-Based Information Assets

One significant challenge related to information assets lies in the nature of cloud services. A significant portion of an organization’s information assets may be stored by other organizations in their cloud-based services. Some of these assets will be overlooked unless an organization has exceedingly good business records. The main reason for this is because of how cloud services work: It’s easy to sign up for a zero-cost or low-cost service and immediately begin uploading business information to the service. Unless the organization has advanced tools such as a CASB, it will be next to impossible for an organization to know all of the cloud-based services in use.

Virtual Assets

Virtualization technology, which enables an organization to employ multiple, separate operating systems to run on one server, is a popular practice for organizations, whether it’s used on hardware servers located in their data centers or in hosting facilities. Organizations that use IaaS are also employing virtualization technology.

IaaS and virtualization make it far easier to create and manage server assets, but maintaining an accurate inventory of virtual server assets is even more challenging than it is for physical assets, and more discipline is required to track and manage virtual server assets properly. Unlike physical servers, which require that different stakeholders initiate and approve a purchase, virtual servers can be created at the click of a button, with or without additional cost to the organization and often without approval. The term virtual sprawl, or virtualization sprawl, reflects this tendency.

The creation/use of virtual servers and other virtual machines is not limited to manual techniques. Virtual machines can also be created through automatic means. A typical example of this is through a cloud services feature known as elasticity. Additional virtual machines can be automatically created and started during heavy workloads when more servers are needed.

Containerization is another form of virtualization where multiple software instantiations execute on a running operating system. The existence of these running instances may be a part of virtual asset inventory.

Software-defined networking (SDN), the class of technologies that facilitate the creation and management of virtual network devices, poses the same challenge to organizations. Additional devices can be created at will or by automatic means. Managing them requires more discipline and potentially greater effort.

Asset Classification

In asset classification, an organization assigns an asset to a category representing usage or risk. In an information security program, the purpose of asset classification is to determine, for each asset, its level of criticality to the organization.

Criticality can be related to information sensitivity. For instance, a customer information database that includes contact and payment information would be considered highly sensitive and could significantly impact present and future business operations in the event of compromise.

Criticality can also be related to operational dependency. For example, a database of virtual server images may be considered highly critical. If an organization’s server images were to be compromised or lost, this could adversely affect its ability to continue its operations.

These and other criticality measures form the basis for information protection, system redundancy and resilience, business continuity planning, disaster recovery planning, and access management. Scarce resources in the form of information protection and resilience need to be allocated to the assets that require it the most, because it doesn’t usually make sense to protect all assets to the same degree; instead, more valuable and critical assets should be more fully protected than those deemed less valuable and critical. To illustrate this point, the late McGeorge Bundy, former U.S. National Security Advisor, is known to have said, “If we guard our toothbrushes and diamonds with equal zeal, we will lose fewer toothbrushes and more diamonds.”

The best approach to asset classification in most organizations is to identify and classify information assets first, followed by system classification. One area often overlooked or not addressed to a satisfactory level is dealing with unstructured data and data that resides outside of the organization’s approved systems.

Information Classification

Information classification is a process whereby different sets and collections of data in an organization are analyzed for various types of value, criticality, integrity, and sensitivity. There are different ways to understand these characteristics. These are some examples:

•   Monetary value   Some information may be easily monetized by intruders who steal it, such as credit card numbers, bank account numbers, gift certificates or cards, and discount or promotion codes. Loss of this type of information may cause direct financial losses.

•   Operational criticality   This information must be available at all times, or perhaps the information is related to some factors of business resilience. Examples include virtual server images, incident response procedures, and business continuity procedures. Corruption or loss of this type of information may significantly impact ongoing business operations.

•   Accuracy or integrity   Information in this category is required to be highly accurate. If altered, the organization could suffer significant financial or reputational harm. Examples include exchange rate tables, product or service inventory data, machine calibration data, and price lists. Corruption or loss of this type of information impacts business operations by causing incomplete or erroneous transactions.

•   Sensitivity   Information of a sensitive nature is commonly associated with individual citizens, including personal contact information, personal financial data such as credit card and bank account numbers, and medical records.

•   Reputational value   Another dimension of classification, denoting the potential loss of reputation should certain sensitive or critical information be lost or compromised. Information such as customers’ personal information fits here.

Most organizations store information that falls into all of these categories, with degrees of importance within them. Though this may result in a complex matrix of information types and degrees of importance or value, the most successful organizations will build a fairly simple information classification scheme. For instance, an organization may develop four levels of information classification, such as the following:

•   Secret

•   Restricted

•   Confidential

•   Public

These levels of information, examples of the types of levels that fall into each category, and instructions on handling information at each level form the heart of a typical information classification program.

Most organizations depend on their personnel to understand the information classification program, including correctly classifying information and handling it properly. This is why better information classification programs have only three or four classification levels. It may be more desirable to have more classification levels, but this often results in confusion and misclassification or mishandling of sensitive and critical data.

Drilling into further detail, following are some examples of information at each of these levels of classification:

•   Secret   Merger and acquisition plans, user and system account passwords, and encryption keys

•   Restricted   Credit card numbers, bank account numbers, Social Security numbers, detailed financial records, detailed system configuration, and vulnerability scan reports

•   Confidential   System documentation, end-user documentation, internal memos, and network diagrams

•   Public   Marketing collateral, published financial reports, and press releases

The next step in information classification is the development of handling procedures that instruct users in the proper acquisition, storage, transmission, and destruction of information at every classification level. Table 5-1 shows a sample information-handling procedure matrix.

The classification and handling guidelines shown here illustrate the differences in various forms of information handling for different classification levels. The contents of Table 5-1 can serve as a starting point for a data classification and handling procedure.

Table 5-1  Example Information-Handling Requirements

Organizations that develop and implement information classification programs find that personnel will often misclassify information, either because they do not understand the nature of the sensitivity of a particular set of data or because they may believe that at a higher classification level they cannot store or transmit the information in a way they think is needed. This is a classic case of people taking shortcuts in the name of expediency, mainly when they are not aware of the possible harm that may befall the organization as a result.

System Classification

Once an organization is satisfied that its information classification is in order, it can embark on system classification. Like various information assets, information systems can also be classified according to various security and operational criteria. The purpose for system classification is similar to the purpose for information criteria: to identify and categorize system assets according to the classification of information stored, processed, or transmitted by them, so that an appropriate level of protection can be determined and implemented.

Once a system is classified according to the highest classification level of information stored, processed, or transmitted through it, the measures used to protect the information system may well play a role in protecting the information—or, in some cases, it will protect only the system. Both means are utilized, and both are essential.

A typical approach to system classification and protection is this: for each level of classification and each type of system, a system-hardening standard is developed that specifies the features and configuration settings to be applied to the system. These settings help make the system resistant to attack, and in some cases, the settings will help protect the information being stored, processed, or transmitted by the systems.

Some examples will help illustrate these points:

•   Database management server   A database management server is used to store information, perhaps credit card data, at the Restricted level of classification. The system itself will be classified as Restricted, and the organization will develop system-hardening standards for the operating system and database management systems.

•   Demilitarized zone (DMZ) firewall   A firewall protects servers located in a DMZ from threats on the Internet and protects the organization’s internal assets from the DMZ if an attacker compromises an asset in the DMZ. Though the firewall does not store information, it protects information by restricting the types of traffic permitted to flow from the Internet to systems upon which the information resides. The organization will develop and implement hardening standards for the firewall.

•   Internet time server   A server provides precise time clock data to other servers, network devices, and end-user workstations. Although the time server itself does not store, process, or transmit sensitive information, it is classified as Restricted because this server has direct access (via time protocols and possibly other protocols) to assets that are classified as Restricted. This server will be hardened according to hardening standards developed by the organization.

This final example helps to introduce the concept of zones of protection. In the architecture of typical information-processing environments, information systems directly store, process, and transmit information at various classification levels, and the systems themselves are classified accordingly. The other servers and assets in the same environment that access these servers or are accessed by them typically need to be classified at the same level. If one of these support servers were compromised by an attacker, the attacker would have direct, and perhaps unrestricted, access to one of the assets that stores, processes, or transmits sensitive or valuable data.

In a large, flat network, this logic could result in an organization classifying many or all of its systems at the same level as the highest classified system. This could require an organization to implement costly and complex protective and administrative measures for large numbers of systems. For this and other reasons, organizations often employ network segmentation, which divides a large, flat network into multiple zones, with firewalls and other protective measures implemented at the boundaries between these zones.

Figure 5-1 depicts a typical network segmentation scheme.

Figure 5-1  Example network segmentation scheme

Facilities Classification

Data, asset, and systems classification can often be extended to facilities classification in larger organizations. Facilities classification is a method for assigning classification or risk levels to work centers and processing centers, based on their operational criticality or other risk factors. Facilities classification aims to develop more consistent security controls for facilities with similar risk levels. For instance, a processing center may have extensive video surveillance and layers of multifactor physical access controls, whereas a sales office may have minimal (if any) video surveillance and simpler access controls.

Personnel Classification

In some organizations, additional requirements are imposed on persons who have access to particularly sensitive information. Whether this information consists of trade secrets, government secrets, or other information, organizations may be required to meet specific requirements such as more thorough or frequent background investigations.

Because of the higher cost of these investigations (to continue this example), it makes more sense to establish a classification scheme for personnel in the organization. For instance, the usual classification for personnel requires a standard background investigation at the time of hire. A higher classification, required for access to specific information, may require a more rigorous background investigation at the time of hire. The highest classification may require this rigorous background investigation to be performed annually. Organizations in a situation like this may want to classify their employees to keep track of the requirements for initial and ongoing background investigations to ensure compliance with whatever applicable laws, regulations, or contracts require them.

Organizations with no legally imposed requirements for personnel classification may still have good reasons to do so. Such circumstances may include the following:

•   Specific policy and standards with additional sign-off/acknowledgment as well as more robust awareness and security training

•   Personnel with access to the most sensitive information (trade secrets and other intellectual property)

•   Personnel with access to sensitive functions (domain administrators and personnel with other privileged system access)

•   Personnel being promoted to an executive level such as vice president

Thus far, only background investigations have been mentioned as variables applied to personnel in various classification levels. Other differences in the treatment of personnel at higher security levels may include the following:

•   Assigned devices may have a higher level of security protection.

•   Access reviews may occur more frequently or be more rigorous.

•   Authentication requirements may be more stringent (such as multifactor authentication for every login).

•   A different color of badge may outwardly signify a higher security level.

•   Personnel may be assigned to work in a facility (or portion thereof) with more stringent physical security controls, such as biometrics and mantraps or the presence of security guards or additional video surveillance.

Asset Valuation

A key part of a risk assessment is identifying the value of an asset. In the absence of an asset’s value, it is more difficult to calculate risks associated with an asset, even when qualitative risk valuation is employed. Without a known valuation, the impact of loss can be more difficult to know.

Qualitative Asset Valuation

Because risk analysis is often qualitative, establishing asset valuation in qualitative terms is common in many organizations. Instead of assigning a dollar (or other currency) value to an asset, the organization can assign a value using a low-medium-high scale or a numeric scale such as 1 to 5 or 1 to 10. By using qualitative asset valuation, an organization can establish which assets have more or less value relative to others. This can be highly useful in an organization with many assets, because it can provide a view of its high-value assets without the “noise” of comingled lower valued assets.

Quantitative Asset Valuation

Many organizations opt to surpass qualitative asset valuation and assign a dollar (or other currency) valuation to their assets. This is common in larger or more mature organizations that want to understand all the costs associated with loss events.

In a typical quantitative valuation of an asset, its value may be one of the following:

•   Replacement cost   The valuation for a hardware asset may be determined to be the cost of purchasing (and deploying) a replacement. For a database, its replacement cost may be the operational costs required to restore it from backup or the costs to recover it from its source, such as a service provider.

•   Book value   This represents the value of an asset in the organization’s financial system, typically the purchase price less depreciation.

•   Net present value (NPV)   If the asset directly or indirectly generates revenue, this valuation method may be used.

•   Redeployment cost   The value of a virtual machine may be determined to be the cost of setting it up again. This is typically a soft cost if it is set up by internal staff, but it could be a hard cost if another company is hired to redeploy it. Remember to include any software licensing costs.

•   Creation or reacquisition cost   If the asset is a database, its cost may be determined to be the cost of creating it again. If the asset is intellectual property such as software source code, its valuation may be determined to be the effort for developers to re-create it.

•   Consequential financial cost   The valuation of a database containing sensitive data may be measured in the form of financial costs that result from its theft or compromise. Though the cost of recovering that database may be relatively low, the consequences of its compromise could cost hundreds of dollars per record. This is a typical cost when measuring the full impact of a breach.

Information security managers need to carefully determine the appropriate method for setting the value of each asset. While some instances will be fairly straightforward, others will not. In many cases, an individual asset will have more than a single valuation category. For example, a credit card database may primarily be valued on its consequential cost (because of the potential fines plus remediation costs associated with consumers who may have been harmed) and also redeployment costs—although, in this case, this may be a small fraction of the total valuation.

Information security managers should document their rationales and methods of valuation, particularly for sensitive information assets whose valuations could vary widely depending on the method used. Better yet, larger and more mature organizations will have guidelines that specify methods and formulas for information asset valuation.

Industry Standards and Frameworks for Information Security

We live in an era of the existence of numerous information security standards and frameworks—some for many years. This enables information security managers to get a head start on developing controls, policies, and standards instead of starting with a clean slate.

There are several types of frameworks in information security, and sometimes they are confused for one another:

•   Control frameworks   These include CIS CSC, ISO/IEC 27002, NIST SP 800-53, PCI DSS, NIST CSF, COBIT, ETSI Technical Report (TR) 103 305-1, HITRUST CSF, and others. These frameworks are starting points for organizations that need to implement security controls and do not want to start from scratch.

•   Risk management frameworks   These include ISO/IEC 27005, ISO/IEC 31000, NIST CSF, and NIST SP 800-37. These frameworks provide the blueprints for a risk management life-cycle program.

•   Architecture frameworks   These include TOGAF and Zachman.

•   Security program management frameworks   These include ISO/IEC 27001, NIST CSF, COBIT, and ETSI TR 103 787-1.

Note that some of these standards appear in more than one category. Some are multipurpose in nature. For instance, NIST CSF prescribes a risk management methodology and includes a mapping of controls.

Control Frameworks

Although every organization may have its unique missions, objectives, business models, risk tolerance, and so on, organizations need not invent governance frameworks from scratch to manage their particular IT objectives. In strategy development, some organizations may already have a suitable control framework in place, while others may not. It is not always necessary for an organization to select an industry-standard control framework, but it is advantageous to do so. These frameworks have been used in thousands of companies, and they are regularly updated to reflect changing business practices, emerging threats, and new technologies.

It is often considered a mistake to select or refuse a control framework because of the presence or absence of a small number of specific controls. Usually, a selection is made assuming that control frameworks are rigid and inflexible. Instead, the strategist should select a control framework based on industry alignment and then institute a process for developing additional controls based on the results of risk assessments. Indeed, this is exactly the approach described in ISO/IEC 27001 and NIST CSF: start with a well-known control framework and then create additional controls, if needed, to address risks specific to the organization.

When assessing the use of a specific framework, the strategist may find that a specific control area is not applicable. In such a case, rather than ignoring the section, the strategist should document the business and technical reasons why the organization chose not to use the control area. This will assist if a question is raised in the future as to why the decision was made not to implement the control area. The date and those involved in the decision should also be documented.

Several standard control frameworks are discussed in the remainder of this section:

•   COBIT

•   IT Infrastructure Library (ITIL) / ISO/IEC 20000

•   ISO/IEC 27002

•   HIPAA

•   NIST SP 800-53

•   NIST SP 800-171

•   NIST CSF

•   CIS CSC

•   PCI DSS

COBIT

Developed in 1996, Control Objectives for Information and Related Technologies (now known as COBIT) is an IT management framework developed by the IT Governance Institute and ISACA. COBIT has four domains: Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate. As of this writing, COBIT 2019 is the latest version.

COBIT is not primarily a security control framework but an IT process framework that includes security processes interspersed throughout the framework. COBIT contains 37 processes. The security- and risk-related processes are as follows:

•   Ensure risk optimization.

•   Manage risk.

•   Manage security.

•   Manage security resources.

•   Monitor, evaluate, and assess compliance with external requirements.

A framework of security controls can be derived from these security- and risk-related processes as a starting point.

COBIT is available from www.isaca.org/COBIT/Pages/Product-Family.aspx (registration and payment required).

ITIL / ISO/IEC 20000

ITIL is a framework of IT service delivery and management processes. The U.K. Office of Government Commerce originally developed ITIL to improve its IT management processes. The international standard, ISO/IEC 20000 (“Information technology — Service management — Part 1: Service management system requirements”), is adapted from ITIL.

ITIL is not a security framework but a process framework for IT service management. However, it is often said that an organization will have difficulty building a successful information security program with effective controls in the absence of a service management framework such as ITIL.

One of the pillars of ITIL is security management, which is fully described in the standard ISO/IEC 27001, discussed in Chapter 2.

ITIL is available from www.axelos.com/best-practice-solutions/itil (registration and payment required).

ISO/IEC 27002

ISO/IEC 27002, “Information technology — Security techniques — Code of practice for information security controls,” is an international standard controls framework. The controls in ISO/IEC 27002 are fully explained, including implementation guidance. These controls are listed in the appendix of ISO/IEC 27001 but lack any explanation or background.

ISO/IEC 27002 is available from www.iso.org/standard/54533.html (registration and payment required).

HIPAA

The U.S. Health Insurance Portability and Accountability Act established requirements for protecting electronic protected health information (ePHI). These requirements apply to virtually every corporate or government entity (known as a covered entity) that stores or processes ePHI. HIPAA requirements fall into three main categories:

•   Administrative safeguards

•   Physical safeguards

•   Technical safeguards

Several controls reside within each of these three categories. Each control is labeled as Required or Addressable. Every covered entity must implement controls that are labeled as Required. Controls labeled as Addressable are considered optional in each covered entity, meaning the organization does not have to implement an Addressable control if it does not apply or if there is negligible risk if the control is not implemented.

A copy of HIPAA is available to view from www.gpo.gov/fdsys/pkg/CRPT-104hrpt736/pdf/CRPT-104hrpt736.pdf.

NIST SP 800-53

Developed by the U.S. National Institute for Standards and Technology, NIST Special Publication (SP) 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” is one of the most well-known and adopted security control frameworks. NIST SP 800-53 is required for all U.S. government information systems and all information systems in private industry that store or process information on behalf of the federal government.

NIST SP 800-53 controls are organized into 18 categories:

•   Access control

•   Awareness and training

•   Audit and accountability

•   Security assessment and authorization

•   Configuration management

•   Contingency planning

•   Identification and authentication

•   Incident response

•   Maintenance

•   Media protection

•   Physical and environmental protection

•   Planning

•   Personnel security

•   Risk assessment

•   System and services acquisition

•   System and communications protection

•   System and information integrity

•   Program management

Even though the NIST 800-53 control framework is required for federal information systems, many organizations that are not required to employ the framework have used it, primarily because it is a high-quality control framework with in-depth implementation guidance and also because it is available without cost.

NIST SP 800-53 is available from csrc.nist.gov/publications/detail/sp/800-53/rev-5/final.

NIST SP 800-171

NIST SP 800-171, “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations,” is a framework of requirements for the protection of controlled unclassified information (CUI). This framework is required for all information systems in private industry that store or process CUI on behalf of any federal government agency.

NIST SP 800-171 is organized into 13 categories:

•   Access control

•   Awareness and training

•   Audit and accountability

•   Configuration management

•   Identification and authentication

•   Incident response

•   Maintenance

•   Media protection

•   Personnel security

•   Physical protection

•   Risk assessment

•   Security assessment

•   System and communications protection

The Cybersecurity Maturity Model Certification (CMMC) is a framework of assessments and assessor certifications used to enforce compliance to NIST SP 800-171 by contractors providing services to the U.S. defense industrial base. More information about CMMC is available from www.acq.osd.mil/cmmc/. More information about CMMC assessments and assessors is available at https://cyberab.org/.

NIST Cybersecurity Framework

The NIST CSF is a risk-based life-cycle methodology for assessing risk, enacting controls, and measuring control effectiveness that is not unlike ISO/IEC 27001. The components of the NIST CSF are as follows:

•   Framework Core   These are a set of functions—Identify, Protect, Detect, Respond, Recover—that make up the life cycle of high-level functions in an information security program. The Framework Core includes a complete set of controls (known as references) within the four activities.

•   Framework Implementation Tiers   These are maturity levels, from least mature to most mature: Partial, Risk Informed, Repeatable, Adaptive.

•   Framework Profile   This aligns elements of the Framework Core (the functions, categories, subcategories, and references) with an organization’s business requirements, risk tolerance, and available resources.

Organizations implementing the NIST CSF would first perform an assessment by measuring the maturity (Implementation Tiers) for each activity in the Framework Core. Next, the organization would determine desired maturity levels for each activity in the Framework Core. The identified differences are considered gaps that need to be filled through several means, including the following:

•   Hiring additional resources

•   Training resources

•   Adding or changing business processes or procedures

•   Changing system or device configuration

•   Acquiring new systems or devices

The NIST CSF can be used as the foundation for a controls framework. Table 2 of Version 1.1 of the CSF maps its Framework Core to CIS CSC, COBIT 2019, ISA 62443, ISO/IEC 27001, and NIST SP 800-53.

The NIST CSF is available from www.nist.gov/cyberframework.

Center for Internet Security Critical Security Controls

The Critical Security Controls framework from the Center for Internet Security (CIS CSC) is a well-known control framework that traces its lineage back to the SANS organization. Despite having 18 sections, the framework is still commonly referred to as the “SANS 20” or “SANS 20 Critical Security Controls.”

The CIS CSC control categories are as follows:

•   Inventory and Control of Enterprise Assets

•   Inventory and Control of Software Assets

•   Data Protection

•   Secure Configuration of Enterprise Assets and Software

•   Account Management

•   Access Control Management

•   Continuous Vulnerability Management

•   Audit Log Management

•   Email and Web Browser Protections

•   Malware Defenses

•   Data Recovery

•   Network Infrastructure Management

•   Network Monitoring and Defense

•   Security Awareness and Skills Training

•   Service Provider Management

•   Application Software Security

•   Incident Response Management

•   Penetration Testing

The CIS CSC controls are available from www.cisecurity.org/controls (registration required). The CIS CSC controls are also published by the European Telecommunications Standards Institute (ETSI) as ETSI TR 103 305-1 V4.1.2, available at https://ipr.etsi.org/.

PCI DSS

The Payment Card Industry Data Security Standard is a control framework specifically for protecting credit card numbers and related information when stored, processed, and transmitted on an organization’s networks. The PCI DSS was developed in 2004 by the PCI Standards Council, a consortium of the world’s dominant credit card brands—namely, Visa, MasterCard, American Express, Discover, and JCB.

The PCI DSS has 12 control objectives:

•   Install and maintain a firewall configuration to protect cardholder data.

•   Do not use vendor-supplied defaults for system passwords and other security parameters.

•   Protect stored cardholder data.

•   Encrypt transmission of cardholder data across open, public networks.

•   Protect all systems against malware and regularly update antivirus software or programs.

•   Develop and maintain secure systems and applications.

•   Restrict access to cardholder data by business need to know.

•   Identify and authenticate access to system components.

•   Restrict physical access to cardholder data.

•   Track and monitor all access to network resources and cardholder data.

•   Regularly test security systems and processes.

•   Maintain a policy that addresses information security for all personnel.

PCI DSS is mandatory for all organizations storing, processing, or transmitting credit card data. Organizations with high volumes of card data are required to undergo annual on-site audits. Many organizations use the controls and the principles in PCI DSS to protect other types of financial, medical, and personal data, such as account numbers, social insurance numbers, and dates of birth.

PCI DSS is available from www.pcisecuritystandards.org/ (registration and license agreement required).

Information Security Management Frameworks

Information security management frameworks are business process models that include essential processes and activities needed by most organizations. These frameworks are risk-centric because the identification of risk is a key driver for activities in other parts of the framework to reduce risk to acceptable levels.

Following are the four most popular security management frameworks:

•   ISO/IEC 27001:2013   The well-known international standard ISO/IEC 27001, “Information technology – Security techniques – Information security management systems – Requirements,” defines the requirements and steps taken to run an information security management system (ISMS), which is the set of processes used to assess risk, develop policy and controls, and manage all of the typical processes found in information security programs such as vulnerability management and incident management. ISO/IEC 27001 is described fully in Chapter 3.

•   COBIT 2019   Developed by ISACA, COBIT 2019 is a controls and governance framework for managing an IT organization. COBIT 2019 for Information Security is an additional standard that extends the view of COBIT 2019 and explains each component of the framework from an information security perspective.

•   NIST CSF   NIST developed the CSF in 2014 to address the rampant occurrence of security breaches and identity theft in the United States. The NIST CSF is an outcomes-based security management and control framework that guides an organization in understanding its maturity levels, assessing risk, identifying gaps, and developing action plans for strategic improvement.

•   ETSI CYBER   ETSI has developed and published “CYBER; Cybersecurity for SMEs; Part 1: Cybersecurity Standardization Essentials,” which describes a top-down approach to developing and managing cybersecurity programs, similar to and partly derived from ISO/IEC 27001 and NIST CSF.

Information Security Architecture

Enterprise architecture (EA) is a business function and a technical model. In terms of a business function, establishing an EA consists of activities that ensure IT systems meet important business needs. The EA may also involve the construction of a model that is used to map business functions into the IT environment and IT systems in increasing levels of detail so that IT professionals can more easily understand the organization’s technology architecture at any level.

Information security architecture can be thought of as a subset or special topic within EA that is concerned with the protective characteristics found in many components in an overall EA and specific components in an EA that provide preventive or detective security functions.

The EA and enterprise security architectures serve the following purposes:

•   All hardware and software components fulfill a stated specific business purpose.

•   All components work well together.

•   There is overall structure and consistency in infrastructure throughout the organization.

•   Infrastructure resources are used efficiently.

•   Infrastructure is scalable and flexible.

•   Existing elements can be upgraded as needed.

•   Additional elements can be added as needed.

Information security architecture exists in two main layers in an organization:

•   Policy   At this level, security policy defines the necessary characteristics of the overall environment and some characteristics of individual components. For example, policy will dictate the existence of centralized authentication and endpoint-based web filtering.

•   Standards   This level includes several types of standards, including vendor standards (that state the makes and models of hardware and software that will be used), protocol standards (that state the network protocols that will be used), algorithm standards (for encryption and message digests), configuration or hardening standards (that define the detailed configuration of different types of systems, devices, and programs), and reference architectures.

Modern information security architecture makes broad use of centralized functions and services that operate more efficiently and effectively than isolated, local instances. Centralized functions and services help amplify the workforce so that a relatively small staff can effectively manage hundreds or even thousands of devices. These functions and services include but are not limited to the following:

•   Authentication   Organizations make use of centralized identity and access management services such as Microsoft Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) so that users’ identities, authentication, access controls, and authorization exist on a single, central service, as opposed to existing on individual systems and devices.

•   Encryption key management   Organizations can implement centralized certificate authorities (CAs) and key stores for more effective management of encryption keys.

•   Monitoring   Organizations can implement centralized monitoring for operational and security purposes to observe at a central management console the events occurring on systems and devices at all locations.

•   Device management   Organizations can implement tools to manage large numbers of similar devices such as servers, workstations, mobile devices, and network devices. Central device management helps make the configuration of systems and devices more consistent.

•   Software development   Organizations whose mission includes developing and delivering software products often develop a formal architecture describing the end-to-end software development environment, including IDEs, source code structure, software build, security testing, regression testing, and defect management.

This book discusses two frameworks for enterprise architecture: TOGAF and the Zachman Framework. Note that these are EA models, not enterprise security architecture models. TOGAF and Zachman are described fully in Chapter 2.

Information Security Policies, Procedures, and Guidelines

Information security policies, standards, guidelines, and procedures are the written artifacts that define the business and technical rules for information and information systems protection. These artifacts enable intentionality and consistency of approach, representing a higher level of maturity than would exist if safeguards were implemented in an ad hoc fashion.

Policy Development

Security policy development is foundational of any organization’s information security program. Information security policy defines the principles and required actions for the organization to protect its assets and personnel properly.

The audience for security policy is the organization’s personnel—not only its full-time and part-time employees, but also its temporary workers, including contractors and consultants. Security policy must be easily accessible by all personnel so that they can never offer ignorance as an excuse for violating policy. To this point, many organizations require all personnel to acknowledge the existence of, and their understanding of, the organization’s security policy at the time of hire and periodically (usually annually) thereafter.

Considerations

Security policy cannot be developed in a vacuum. Instead, it needs to align with some internal and external factors. The development of policy needs to incorporate several considerations, including the following:

•   Applicable laws, regulations, standards, and other legal obligations

•   Risk tolerance

•   Controls

•   Organizational culture

Alignment with Controls

Security policy and controls need to be in alignment. This is not to say that there must be a control for every policy or a policy for every control, but policies and controls must not contradict each other. For example, suppose a control states that no personally owned mobile devices may connect to internal networks. In that case, the policy cannot state that those devices may be used, provided no corporate information is stored on them. It also makes sense for the structure of policies and controls to resemble one another. This alignment makes it easier for personnel to become familiar with the structure and content of policies and controls.

Alignment with the Audience

Security policy needs to align with the audience. In most organizations, this means that policy statements need to be understood by most workers. A common mistake in developing security policy is the inclusion of highly technical policies such as permitted encryption algorithms or statements about the hardening of servers. Such topics are irrelevant to most workers; the danger of including policies that are irrelevant to most workers is that they are likely to “tune out” and not pay attention to those policies that do apply to them. In other words, security policy should have a high signal-to-noise ratio.

In organizations with extensive uses of technology, one avenue is to create a general security policy intended for all workers (technical and nontechnical) and a separate policy for technical workers who design, build, and maintain information systems. Another alternative is to create a general security policy for all workers that states that all controls are mandatory. Either approach would be sufficient by aligning messages about policy with various audiences.

Security Policy Structure

Security policy structure comprises several different topics that may include the following:

•   Acceptable use of organization assets

•   Mobile devices

•   Protection of information and assets

•   Access control and passwords

•   Personally owned devices

•   Connected devices (such as IoT)

•   Vulnerability management

•   Security monitoring and incident response

•   E-mail and other communications

•   Social media

•   Ethics and applicable laws

•   Workplace safety

•   Visitors

•   Consequences of noncompliance

•   Cloud computing

•   Data (and system, facilities, and personnel) classification

•   Encryption

•   Third-party risk management

•   Data exchange with third parties

•   Privacy

•   Compliance with applicable laws and regulations

Security managers can choose how to package these and other security policies. For example, they may exist in separate documents or together in one document. There is no right or wrong method; instead, a security manager should determine what would work best in the organization by observing how other policies are structured, published, and consumed.

Security policy statements should be general and not cite specific devices, technologies, algorithms, or configurations. Policy statements should state what is to be done (or not done) but not how. This way, security policies will be durable and will need to be changed infrequently. On the other hand, security standards and procedures may change more frequently as practices, techniques, and technologies change.

Policy Distribution and Acknowledgment

Security policy—indeed, all organization policy—should be well known and easily accessible by all workers. For example, it may be published on a corporate intranet or other online location where workers go to obtain information about internal operations.

All workers need to be informed of the presence of the organization’s security policy. The best method in most organizations is for a high-ranking executive to write a memo or an e-mail to all workers stating the importance of information security in the organization and informing them that the information security policy describes required behavior for all workers. Another effective tactic is to have the senior executive record a message outlining the need and importance of security policy. Additionally, the message should state that the executive leadership team has reviewed and fully supports the policies.

Executives need to be mindful that they lead by example. If executives are seen to carve out exceptions for themselves (for example, if an executive insists on using a personal tablet computer for company business when policy forbids it), other workers are apt to notice and take shortcuts wherever they’re able. If executives work to comply visibly with security policy, others will too. Organizational culture includes behavior such as compliance with policy or a tendency for workers to skirt policy whenever possible.

Standards

It is said that policy states what to do, whereas standards describe how to do it or what to do it with. Like policies, standards should be written down, periodically examined and updated, approved by management, and published so all personnel can find them.

The topic of standards development is discussed in greater detail in Chapter 2.

Guidelines

Guidelines are nonbinding statements or narratives that provide additional direction to personnel regarding compliance with security policies, standards, and controls. Information security departments often develop guidelines when they receive numerous inquiries for help understanding certain policies or have trouble understanding how to implement them.

Guidelines can be written as separate documents resembling whitepapers or how-to guides, or they may be interspersed within policy or control documents. ISO/IEC 27002 is an excellent example of guidance included with each control in individual sections entitled “guidance.”

Requirements

Requirements are formal statements that describe the characteristics of a system that is to be changed, developed, or acquired. Requirements should flow from, and align with, the structure and content of policies and standards. Because of their use in systems and services development and acquisition, requirements should be published in a format that can be easily extracted for use in specific projects.

Organizations should have a standard set of general requirements that apply to all technologies and environments. Then, additional specific requirements should be developed that focus on each specific project or initiative.

Requirements must be specific and verifiable. Any ambiguities should be resolved, so that all parties involved have a clear understanding of each requirement. Further, requirements should become the basis for a test plan, a step-by-step procedure for verifying that a system, service, or process complies with all applicable requirements.

It is unlikely that all requirements will be satisfied in large, complex projects. Thus, project managers and subject matter experts should prioritize requirements to distinguish those considered “must-have” versus those that are “nice to have.” Further, each bespoke requirement that is not a part of the organization’s standard requirements should be traceable to the person or group that requested it be included. If there are questions later in the project about a specific requirement, the project team can easily know who wrote and included the requirement. Those individuals can answer any questions about the requirement to help others better understand it.

Some organizations distinguish functional requirements from nonfunctional requirements. Functional requirements describe the required actions and functions of a system. Example functional requirements include the following:

•   In the password reset function, the system must provide visual information indicating the strength of the proposed new password.

•   After five minutes of inactivity, the system must invoke an automatic lock and require the user to reauthenticate to continue work.

On the other hand, a nonfunctional requirement describes the required characteristics of a system, service, or process in terms of its components, structure, or architecture. Example nonfunctional requirements include the following:

•   The system must not contain comments, symbol tables, or other human-readable information in its machine-readable state.

•   The system must use Microsoft SQL Server as its relational database management system.

Functional and nonfunctional requirements can further be distinguished in this way: nonfunctional requirements define what a system is supposed to be, whereas functional requirements define what a system is supposed to do. Arguably, some functional versus nonfunctional requirements may be more difficult to distinguish; for instance, requiring that a system include a specific encryption algorithm could be considered a nonfunctional requirement, whereas requiring a system to encrypt data using a specific algorithm could be considered a functional requirement. It matters little whether such requirements are called functional or nonfunctional, however; rather, requirements should be consistent in language and tone to ensure that working with them is not a difficulty in itself.

Processes and Procedures

Processes and procedures are the detailed, sequenced instructions used to complete routine tasks. A process is a collection of one or more procedures that together fulfill a higher purpose, while a procedure is a written set of instructions for a single task.

Organizations often document processes and procedures to ensure consistency and compliance with individual policies and controls. Written processes and procedures are a cornerstone for audits of policies and controls. Their existence signals higher maturity and (the hope of) greater consistency in routine operations. Auditors generally regard process and procedure documents as outdated and invalid if they have not been reviewed for more than one year.

Policies, standards, and controls are generally developed and maintained by an information security program, whereas processes and procedures are developed and maintained by the business departments that perform them.

Information Security Program Metrics

A metric is a measurement of a periodic or ongoing activity intended to help management understand the activity within the context of overall business operations. In short, metrics are the means through which management can measure key processes and know whether their strategies are working. Metrics are used in many operational processes, but this section emphasizes metrics related to security governance. In other words, there is a distinction between tactical IT security metrics and those that reveal the state of the overall security program. The two are often related, however, as discussed in the sidebar “Return on Security Investment,” later in this chapter.

Security metrics are often used to observe technical IT security controls and processes and determine whether they are operating properly. This helps management better understand the impact of past decisions and can help drive future decisions. Examples of technical metrics include the following:

•   Firewall metrics   Number and types of rules triggered

•   Intrusion detection/prevention system (IDPS) metrics   Number and types of incidents detected or blocked, and targeted systems

•   Antimalware metrics   Number and types of malware blocked, and targeted systems

•   Other security system metrics   Measurements from DLP systems, web content filtering systems, CASB systems, and so on

While useful, these metrics do not address the bigger picture of the effectiveness or alignment of an organization’s overall security program. They do not answer key questions that boards of directors and executive management often ask, such as the following:

•   How much security is enough?

•   How should security resources be invested and applied?

•   What is the potential impact of a threat event?

These and other business-related questions can be addressed through the appropriate metrics, as addressed in the remainder of this section.

Security strategists sometimes think about metrics in simple categorization, such as the following:

•   Key risk indicators (KRIs)   Metrics associated with risk measurement

•   Key goal indicators (KGIs)   Metrics that portray the attainment of strategic goals

•   Key performance indicators (KPIs)   Metrics that show the efficiency or effectiveness of security-related activities

Monitoring

In the overall information security program, monitoring is the continuous or regular evaluation of a system or control to determine its operation or effectiveness. Monitoring generally includes two activities:

•   Management’s review of certain qualitative aspects of an information security program or the entire program. This may take the form of an executive briefing delivered by the security manager.

•   Management’s review of key metrics in the information security program to understand its effectiveness, efficiency, and performance.

Effective Metrics

For metrics to be effective, they need to be measurable. A common way to ensure the quality and effectiveness of a metric is to use the SMART method. A SMART metric is

•   Specific

•   Measurable

•   Attainable

•   Relevant

•   Timely

Additional considerations for good metrics, according to Risk Metrics That Influence Business Decisions by Paul Proctor (Gartner, Inc., 2016), include the following:

•   Leading indicator   Does the metric help management predict future risk?

•   Causal relationship   Does the metric have a defensible causal relationship to a business impact, where a change in the metric compels someone to act?

•   Influence   Has the metric influenced decision-making (or will it)?

You can find more information about the development of metrics in NIST SP 800-55 Revision 1, “Performance Measurement Guide for Information Security,” available from https://csrc.nist.gov/publications/detail/sp/800-55/rev-1/final.

Strategic Alignment

For a security program to be successful, it must align with the organization’s mission, strategy, goals, and objectives. A security program strategy and objectives should contain statements that can be translated into key measurements—the program’s key performance and risk metrics.

Consider an example. The fictitious organization CareerSearchCo, which is in the online career search and recruiting business, has the following as its mission statement:

Be the best marketplace for job seekers and recruiters

Here are its most recent strategic objectives:

Integrate with leading business social network LinkedIn
Develop an API to facilitate long-term transformation into a leading career and recruiting platform

To meet these objectives, CareerSearchCo has developed a security strategy that includes the following:

Ensure Internet-facing applications are secure through developer training and
application vulnerability testing

Security and metrics would then include these:

Percentage of software developers not yet trained
Number of critical vulnerabilities identified
Time to remediate critical and high vulnerabilities

Based on these criteria, these metrics are all measurable, all align with the security strategy, and are all leading indicators. If the metrics trend in an unfavorable direction, this could indicate that a breach is more likely to occur that would damage CareerSearchCo’s reputation and ability to earn new business contracts from large corporations.

Types of Metrics

Many activities and events in an information security program and its controls can be measured. These measurements can be depicted in various ways, depending upon the story being told. When building and improving an information security program, security managers need to understand that no single metrics framework will meet every identified goal.

Compliance

Compliance metrics are measures of key controls related to requirements in regulations, legal contracts, or internal objectives. Compliance metrics depict the level of conformance to these requirements. Organizations need to understand the business context of compliance metrics, including the consequences of noncompliance. Security managers need to consider the tolerance for noncompliance with each metric, including the organization’s willingness and ability to initiate corrective action when noncompliant activities occur.

Convergence

Larger organizations with multiple business units, geographic locations, or security functions (which can often result from mergers and acquisitions) may experience issues related to overlapping or underlapping coverage or activities. For instance, an organization that recently acquired another company may have some duplication of effort in the asset management and risk management functions. In another example, local security personnel in a large, distributed organization may be performing security functions that are also being performed on their behalf by other personnel at headquarters.

Metrics in the convergence category will be highly individualized, based on specific circumstances in an organization. Some of the categories of metrics include the following:

•   Gaps in asset coverage

•   Overlaps in asset coverage

•   Consolidation of licenses for security tools

•   Gaps or overlaps in skills, responsibilities, or coverage

Value Delivery

Metrics on value delivery focus on the long-term reduction in costs, in proportion to other measures. Examples of value delivery metrics include the following:

•   Controls used (seldom used controls may be candidates for removal)

•   Percentage of controls that are effective (ineffective controls consume additional resources in audit, analysis, and remediation activities)

•   Program costs per asset population or asset value

•   Program costs per employee population

•   Program costs per revenue

Organizations are cautioned against using only value delivery metrics; doing so will risk the security program spiraling down to nothing, since a program that costs nothing will produce the best possible metric in this case.

Resource Management

Resource management metrics are similar to value delivery metrics; both convey an efficient use of resources in an organization’s information security program. But because the emphasis here is program efficiency, these are areas where resource management metrics may be developed:

•   Standardization of security-related processes (because consistency drives costs down)

•   Security involvement in every procurement and acquisition project

•   Percentage of assets protected by security controls

Organizational Awareness

Organizational awareness metrics help management understand the number of workers who understand security policies and requirements. Typical metrics in organizational awareness include the following:

•   Percentage of employees who complete security training

•   Percentage of employees who acknowledge awareness of, and conformance to, security policies

•   Average scores on quizzes and tests of knowledge of security safeguards

Operational Productivity

Operational productivity metrics show how efficiently internal staff is used to perform essential functions. Productivity metrics can help build business cases for the automation of routine tasks. Example productivity metrics include the following:

•   Number of hours required to perform a segregation of duties review

•   Number of hours required to perform a vulnerability assessment

•   Number of hours required to perform a risk assessment

Organizational Support

Organizational support metrics show the degree of support for organizational objectives. Arguably, this is a subjective metric, because it can be difficult to produce meaningful measurements. Though it is possible to show the achievement of key objectives, measuring the degree of support that led to their achievement may be difficult: Was an achievement the result of a determined few or the whole organization?

Often, organizational support metrics take the form of project and program dashboards for projects and programs that support the achievement of organizational objectives. However, failure to complete a project on time is not necessarily an indication of support or the lack thereof but may reflect unanticipated obstacles or changes in project scope.

Risk Management

Effective risk management is the culmination of the highest-order activities in an information security program; these include risk analyses, a risk ledger, formal risk treatment, and adjustments to the suite of security controls.

While it is difficult to measure the success of a risk management program effectively and objectively, it is possible to take indirect measurements—much like measuring the shadow of a tree to gauge its height. Thus, the best indicators of a successful risk management program would be improving trends in metrics involved with the following:

•   Reduction in the number of security incidents

•   Reduction in the impact of security incidents

•   Reduction in the time to remediate security incidents

•   Reduction in the time to remediate vulnerabilities

•   Reduction in the number of new unmitigated risks

Regarding the previous mention of the reduction of security incidents, a security program improving its maturity from low levels should first expect to see the number of incidents increase. This would be not because of lapses in security controls but because of the development of—and improvements in—mechanisms used to detect and report security incidents. Similarly, as a security program is improved and matures over time, the number of new risks will, at first, increase and then later decrease.

Technical Security Architecture

Technical security architecture metrics are typically the numbers of events that occur in automated systems such as firewalls, IDPSs, DLP systems, spam filters, and antimalware systems. This is generally the richest set of metrics data available to a security manager and a category of metrics often presented without proper business context. For example, the number of attacks blocked by a firewall or the number of malware infections blocked by antimalware software may have operational meaning, but these will mean nothing to management. Executives would be right to ask whether an increase in blocked attacks is good, bad, or meaningless.

There are, however, some metrics available that have meaning for business executives. Examples include the following:

•   Percentage of employees who responded to (clicked links or opened attachments) e-mail attacks

•   Number of attacks that bypassed network controls such as firewalls, IDPSs, and web filters, which resulted in unscheduled downtime

•   Number of malware attacks that circumvented antimalware controls and resulted in unscheduled downtime

•   Number of brute-force password attacks that were blocked

•   Number of records compromised that required disclosure

Operational Performance

Operational performance metrics generally show how well personnel are performing critical security functions. Processes measured by these metrics need to have sufficiently detailed business records so that metrics can be objectively measured. These are some examples of operational performance metrics:

•   Elapsed time between the onset of a security incident and incident declaration

•   Elapsed time between the declaration of an incident and its containment

•   Elapsed time between publication of a critical vulnerability and its discovery in the organization’s systems

•   Percentage of critical systems not patched with critical patches within the service level agreement (SLA)

•   Number of changes made without change control board approval

•   Amount of unscheduled downtime of critical systems for security-related reasons

Security Cost Efficiency

Metrics related to security cost efficiency measure the resources required for key controls. Security managers need to be careful with cost efficiency metrics, as demands for improvement (such as reduced costs) over time can increase risk. This is compounded by the fact that it is relatively easy to measure cost, whereas risk measurement is more subjective and qualitative.

Example cost efficiency metrics include the following:

•   Cost of antimalware controls per user

•   Cost of anti-phishing and antispam controls per user

•   Cost of centralized network defenses, such as firewalls, per user

Security managers should consider including staff and tool costs to provide a more complete and accurate picture of the total costs for controls.

Audiences

As mentioned, when building or improving a metrics program, security managers need to consider the purpose of any particular metric and the audience to whom it is sent. A common mistake made by security managers is the publication of metrics to various audiences without first understanding whether any individual metric will have meaning to any particular audience. For example, a metric showing the number of packets dropped by a firewall will probably have no meaning to a member of the organization’s board of directors—nor would a trend of this metric have any meaning. Security managers need to determine what metrics are important for various audiences and purposes and then proceed to develop those metrics.

Some metrics will have only operational value, while others can be successfully transformed into a management or strategic metric when portrayed in context. For example, a metric on the number of malware attacks has no business context; however, a metric showing successful malware attacks that result in business disruptions have far more meaning to management. A metric on patch management SLAs by itself has no business context, but if that were transformed into a metric showing that critical systems not patched within SLAs resulted in higher than desired business risk, the metric would have meaning to executive audiences.

Although there may be value in automated systems that keep records that can be examined or measured later, there is often little point in developing metrics with no audience in mind. Such a pursuit would merely take time away from more valuable activities.

The Security Balanced Scorecard

The balanced scorecard (BSC) is a management tool used to measure an organization’s performance and effectiveness. The BSC is used to determine how well an organization can fulfill its mission and strategic objectives and how well it is aligned with overall organizational objectives. In the BSC, management defines key measurements in each of four perspectives:

•   Financial   Key financial items measured include the cost of strategic initiatives, support costs of key applications, and capital investment.

•   Customer   Key measurements include the satisfaction rate with various customer-facing aspects of the organization.

•   Internal processes   Measurements of key activities include the number of projects and the effectiveness of key internal workings of the organization.

•   Innovation and learning   Human-oriented measurements include turnover, illness, internal promotions, and training.

Each organization’s BSC will represent a unique set of measurements that reflects the organization’s type of business, business model, and management style.

The BSC should be used to measure overall organizational effectiveness and progress. A similar scorecard, the security-BSC, can specifically measure security organization performance and results. Like the BSC, the security-BSC has the same four perspectives, mapped to key activities, as depicted in Table 5-2.

Table 5-2  Security Balanced Scorecard Domains

The security-BSC should flow directly from the organization’s overall security-BSC and its IT-BSC. This will ensure that security will align itself with corporate objectives. While the perspectives between the overall BSC and the security-BSC vary, the approach for each is similar, and the results for the security-BSC can “roll up” to the organization’s overall BSC.

Chapter Review

An information security program is a collection of activities used to identify, communicate, and address risks. The security program consists of controls, processes, and practices to increase the resilience of the computing environment and ensure that risks are known and handled effectively.

A charter is a formal, written definition of the objectives of a program, its main timelines, the sources of funding, the names of its principal leaders and managers, and the business executives sponsoring the program.

Information security programs include numerous business processes to fulfill the overall mission of information and information systems protection. These processes fall into three major categories: risk and compliance, architecture, and operations.

Modern information security includes essential business processes such as risk and policy management, but overall it is also heavily involved in IT. After all, information security’s mission is the protection of all things IT. To scale with the power and speed of IT, information security has its own portfolio of protective and detective technologies.

Assets are the things of value that an organization protects in an information security program. In a typical organization, assets will consist of information and the information systems that support and protect those information assets.

Asset classification is an activity whereby an organization assigns an asset to a category representing usage or risk. In an information security program, the purpose of asset classification is to determine, for each asset, its level of criticality to the organization.

Information classification is a process whereby different sets and collections of data in an organization are analyzed for various types of value, criticality, integrity, and sensitivity. Most organizations store information that falls into all of these categories, with degrees of importance within them. These levels of information, together with examples of the types of levels that fall into each category and with instructions on handling information at each level, form the heart of a typical information classification program.

Once an organization is satisfied that its information classification is in order, it can embark on system classification. Like various types of information assets, information systems also can be classified according to various security and operational criteria.

In some organizations, additional requirements are imposed on persons who have access to particularly sensitive information. Whether this information consists of trade secrets, government secrets, or other information, organizations may be required to meet specific requirements such as more thorough or frequent background investigations.

A key part of a risk assessment is identifying the value of an asset. Because risk analysis is often qualitative, establishing asset valuation in qualitative terms is common. Instead of assigning a dollar (or other currency) value to an asset, the value of an asset can be assigned to a low-medium-high scale or a numeric scale such as 1 to 5 or 1 to 10.

Many organizations opt to surpass qualitative asset valuation and assign a dollar (or other currency) valuation to their assets. This is common in larger or more mature organizations that want to better understand the actual costs associated with loss events.

There are several types of frameworks in information security, and sometimes they are confused with one another. The types include control frameworks, risk management frameworks, architecture frameworks, and security program management frameworks.

Standard control frameworks include COBIT 2019, ISO/IEC 20000, ISO/IEC 27002, HIPAA, NIST SP 800-53, NIST SP 800-171, NIST CSF, CIS CSC, ETSI TR 103 305-1, and PCI DSS.

Information security management frameworks are business process models that include essential processes and activities needed by most organizations. These frameworks are risk-centric because the identification of risk is a key driver for activities in other parts of the framework to reduce risk to acceptable levels. These frameworks include ISO/IEC 27005, ISO/IEC 31000, COBIT 2019, NIST SP 800-37, and NIST CSF.

Enterprise architecture (EA) is a business function and a technical model. In terms of a business function, establishing an EA consists of activities that ensure that IT systems meet important business needs.

Information security architecture can be thought of as a subset or special topic within EA that is concerned with the protective characteristics found in many components in an overall EA and specific components in an EA that provide preventive or detective security functions.

Information security policies, standards, guidelines, and procedures are the written artifacts that define the business and technical rules for information and information systems protection.

Security policy development is foundational to any organization’s information security program. Information security policy defines the principles and required actions for the organization to protect its assets and personnel properly.

Guidelines are nonbinding statements or narratives that provide additional direction to personnel regarding compliance with security policies, standards, and controls. Information security departments often develop guidelines when they receive numerous inquiries for help understanding certain policies or have trouble understanding how to implement them.

Requirements are formal statements describing the characteristics of a system to be changed, developed, or acquired. Requirements should flow from, and align with, the structure and content of policies and standards. Because of their use in systems and services development and acquisition, requirements should be published in a format that can be easily extracted for use in specific projects.

Processes and procedures are the detailed, sequenced instructions to complete routine tasks. A process is a collection of one or more procedures that together fulfill a higher purpose, while a procedure is a written set of instructions for a single task.

A metric is a measurement of a periodic or ongoing activity that intends to help the organization understand the activity within the context of overall business operations. Metrics are the means through which management can measure key processes and know whether their strategies are working.

A formal metrics program provides qualitative and quantitative data on the effectiveness of many elements of an organization’s security program and operations. Metrics can be developed via the SMART method: specific, measurable, attainable, relevant, and timely. Metrics must align with the organization’s mission, strategy, and objectives. Some metrics can be used to report on results in the recent past, but some metrics should serve as leading indicators or drive a call to action by the leadership team.

A common shortcoming of a metrics program is its failure to provide relevant metrics for various audiences. For instance, reporting the number of packets dropped by a firewall or the number of viruses detected by antivirus to the board of directors provides little or no value for that audience. As an organization develops its metrics program, it must take care to develop metrics that matter for each audience. A security balanced scorecard can also depict the high-level effectiveness of an organization’s security program.

Notes

•   Whether or not it carries authority in an organization, a charter’s usefulness is derived from its descriptions of an organization’s vision, objectives, roles and responsibilities, and processes and procedures. A charter can help personnel come to a common understanding of security programs and other programs.

•   The three lines of defense model, used often in banking, is a good model for formally separating and defining roles related to control development, operation, and assurance. A similar model can be used for policy development.

•   Asset identification is a cornerstone of any risk management and security management program, yet most organizations do a poor job of it. Asset identification is the first control in the Center for Internet Security Critical Security Controls (CIS CSC), and there is a reason for that.

•   Qualitative asset valuation is sufficient for qualitative risk assessments. But when it’s necessary to calculate figures such as exposure factor or annual loss expectancy, security managers will need to obtain a quantitative valuation for relevant assets. However, precision is challenging because it is difficult to know the probability of threat events.

•   Asset inventory is increasingly difficult to manage successfully because of virtualization and the wide use of cloud-based services.

•   Enacting a data classification scheme is easy, but implementing the program is difficult. Data classification should be extended to include system classification (the classification of a system should be the same as the highest classified data stored or processed on the system), asset classification, and even facilities (work center) classification.

•   Many organizations ruminate over the selection of a control framework. Instead, the organization should select a framework and then adjust its controls to suit the organization.

•   A control framework should generally be considered a starting point, not a rigid and unchanging set of controls—except in cases where regulations stipulate that controls may not be changed.

•   At present, because there are no well-known frameworks for information security metrics, it is up to every organization to develop meaningful and applicable metrics for various audiences interested in receiving them.

•   The methodology for calculating return on security investment is widely discussed but not widely practiced, mainly because it is difficult to calculate the benefit of security controls designed to detect or prevent infrequent incidents.

Questions

1.   An organization’s board of directors wants to see quarterly metrics on risk reduction. What would be the best metric to present to the board?

A.   Number of firewall rules triggered

B.   Viruses blocked by antivirus programs

C.   Packets dropped by the firewall

D.   Time to patch vulnerabilities on critical servers

2.   Which of the following metrics is the best example of a leading indicator?

A.   Average time to mitigate security incidents

B.   Increase in the number of attacks blocked by the intrusion prevention system

C.   Increase in the number of attacks blocked by the firewall

D.   Percentage of critical servers being patched within service level agreements

3.   The primary factor related to the selection of a control framework is:

A.   Industry vertical

B.   Current process maturity level

C.   Size of the organization

D.   Compliance level

4.   The purpose of a balanced scorecard is to:

A.   Measure the efficiency of a security organization

B.   Evaluate the performance of individual employees

C.   Benchmark a process in the organization against peer organizations

D.   Measure organizational performance and effectiveness against strategic goals

5.   In an organization using PCI DSS as its control framework, the conclusion of a recent risk assessment stipulates that additional controls not present in PCI DSS but present in ISO 27001 should be enacted. What is the best course of action in this situation?

A.   Adopt ISO 27001 as the new control framework.

B.   Retain PCI DSS as the control framework and update process documentation.

C.   Add the required controls to the existing control framework.

D.   Adopt NIST 800-53 as the new control framework.

6.   A security manager has developed a scheme that prescribes required methods to protect information at rest, in motion, and in transit. This is known as a(n):

A.   Data classification policy

B.   Asset classification policy

C.   Data loss prevention plan

D.   Asset loss prevention plan

7.   A security leader has developed a document that describes a program’s mission, vision, roles and responsibilities, and processes. This is known as a:

A.   Policy

B.   Charter

C.   Standard

D.   Control

8.   Management in an organization has developed and published a policy that directs the workforce to follow specific steps to protect various types of information. This is known as a:

A.   Privacy policy

B.   Data dictionary

C.   Data classification policy

D.   Data governance policy

9.   The security leader in an organization is developing a first-ever data classification policy. What is the best first step in this endeavor?

A.   Develop the classification levels.

B.   Perform a data inventory.

C.   Interview end users.

D.   Develop the handling procedures.

10.   A security leader wants to develop a scheme whereby the most important assets are protected more rigorously than those deemed less important. What is the best first step in this endeavor?

A.   Map classified data to systems.

B.   Establish a systems inventory.

C.   Interview end users.

D.   Develop the protection guidelines.

11.   A retail organization’s security leader wants to develop an ISMS. Which standard is the best resource for the leader to use?

A.   ISO/IEC 27001

B.   ISO/IEC 27002

C.   NIST SP 800-53

D.   PCI DSS

12.   An IT worker is reading a security-related document that provides suggestions regarding compliance with a particular policy. What kind of a document is the IT worker reading?

A.   Procedure

B.   Policy

C.   Standard

D.   Guideline

13.   An IT worker is reading a security-related document that stipulates which algorithms are to be used to encrypt data at rest. What kind of a document is the IT worker reading?

A.   Procedure

B.   Requirements

C.   Standard

D.   Guideline

14.   An IT worker is reading a document that describes the essential characteristics of a system to be developed. What kind of a document is the IT worker reading?

A.   Procedure

B.   Requirements

C.   Standard

D.   Guideline

15.   The concept of dividing the management of controls into development, operations, and assurance is known as:

A.   Controls framework

B.   Split custody

C.   Separation of duties

D.   Three lines of defense

Answers

1.   D. The metric on time to patch critical servers will be the most meaningful metric for the board of directors. While potentially interesting at the operational level, the other metrics do not convey business meaning to board members.

2.   D. The metric of the percentage of critical servers being patched within SLAs is the best leading indicator because it is a rough predictor of the probability of a future security incident. The other metrics are trailing indicators because they report on past incidents.

3.   A. The most important factor influencing a decision to select a control framework is the industry vertical. For example, a healthcare organization would likely select HIPAA as its primary control framework, whereas a retail organization may select PCI DSS.

4.   D. The balanced scorecard is a tool used to quantify an organization’s performance against strategic objectives. The focuses of a balanced scorecard are financial, customer, internal processes, and innovation/learning.

5.   C. An organization that needs to implement new controls should do so within its existing control framework. It is unnecessary to adopt an entirely new control framework when a few controls need to be added.

6.   A. A data classification policy is a statement that defines two or more classification levels for data, together with procedures and standards for the protection of data at each classification for various use cases such as storage in a database, storage on a laptop computer, transmissions via e-mail, and storage on backup media.

7.   B. A charter document, which describes many facets of a function or program, best fits this description.

8.   C. Management has created a data classification policy, which defines classification levels and handling procedures for information in various forms at each level.

9.   B. The best first step in developing a data classification policy is to develop an inventory of data to understand the various types that are stored in use in the organization.

10.   B. The best first step is the development of an inventory of systems. After that, the best step is the mapping of information (and its classification) stored or processed by each system.

11.   A. ISO/IEC 27001, “Information technology – Security techniques – Information security management systems – Requirements,” defines all of the high-level characteristics of an information security management system (ISMS). The other answers are control frameworks, which are used to develop and organize controls.

12.   D. The IT worker is reading a guideline, a document that provides nonbinding guidance regarding compliance with a policy, control, or standard.

13.   C. The IT worker is reading a standard, a document that stipulates the mandatory use of protocols, algorithms, techniques, products, or suppliers.

14.   B. The IT worker is reading a requirements document, which describes the required characteristics of a system to be developed or acquired.

15.   D. The three lines of defense model describes the separate roles in control management as development, operations, and assurance (audit).