• Testing When the developers have finished coding and unit testing, a more formal and comprehensive test phase is performed. Here, analysts, dedicated software testers, and perhaps end users will test all of the new and changed functionality to confirm whether it is performing according to requirements. Depending on the nature of the changes, some amount of regression testing is also performed; this means that functions that were confirmed to be working properly in prior releases are tested again to make sure that they continue to work as expected. Testing is performed according to formal, written test plans that are designed to confirm that every requirement is fulfilled. Formal test scripts are used, and the results of all tests should be recorded and archived. The testing that users perform is usually called user acceptance testing (UAT). Often, automated test tools are used, which can make testing more accurate and efficient. After testing is completed, a formal review and approval are required before the process is allowed to continue.

• Implementation When testing has been completed, the software is implemented on production systems. Here, developers hand off the completed software to operations personnel, who install it according to instructions created by developers. This could also involve the use of tools to make changes to data and database design to accommodate changes in the software. When changes are completed and tested, the release itself is carried out with these last two steps:

• Release preparation When UAT and regression testing have been completed, reviewed, and approved, a release management team will begin to prepare the new or changed software for release. Depending upon the complexity of the application and of the change itself, release preparation may involve not only software installation but also the installation or change to database design, and perhaps even changes to customer data. Hence, the software release may involve the development and testing of data conversion tools and other programs that are required so that the new or changed software will operate properly. As with testing and other phases, full records of testing and implementation of release preparation details need to be captured and archived.

• Release deployment When release preparation is completed (and perhaps reviewed and approved), the release is installed on the target systems. Personnel deploying the release will follow the release procedure, which may involve the use of tools that will make changes to the target system at the operating system, database, or other level; any required data manipulation or migration; and the installation of the actual software. The release procedure will also include verification steps that will be used to confirm the correct installation of all components.

• Post-implementation After the software has been implemented, a post-implementation review takes place to examine matters of system adequacy, security, ROI, and any issues encountered during implementation.

Utilizing a Gate Process

Many organizations utilize a “gate process” approach in their release management process. This means that each step of the process undergoes formal review and approval before the next step is allowed to begin. For example, a formal design review will be performed and attended by end users, personnel who created requirements and feature description documents, developers, and management. If the design is approved, development may begin. But if there are questions or concerns raised in the design review, the design may need to be modified and reviewed again before development is allowed to begin.

Agile processes utilize gates as well, although the flow of Agile processes is often parallel rather than sequential. The concept of formal reviews is the same, regardless of the SDLC process in use.

Service-Level Management

Service-level management is composed of the set of activities that confirms whether IS operations is providing adequate service to its customers. This is achieved through continuous monitoring and periodic review of IT service delivery.

An IS department often plays two different roles in service-level management. As a provider of service to its own customers, the IS department will measure and manage the services that it provides directly. Also, many IT departments directly or indirectly manage services that are provided by external service providers. Thus, many IT departments are both service provider and customer, and often the two are interrelated, as depicted in Figure 4-14.

Figure 4-14 The different perspectives of the delivery of IT services

Financial Management

Financial management for IT services consists of several activities, including the following:

• Budgeting

• Capital investment

• Expense management

• Project accounting and project return on investment (ROI)

IT financial management is the portion of IT management that takes into account the financial value of IT services that support organizational objectives.

Capacity Management

Capacity management is a set of activities that confirms there is sufficient capacity in IT systems and IT processes to meet service needs. Primarily, an IT system or process has sufficient capacity if its performance falls within an acceptable range, as specified in service level agreements.

Capacity management is not just a concern for current needs; capacity management must also be concerned about meeting future needs. This is attained through several activities, including the following:

• Periodic measurements Systems and processes need to be regularly measured so that trends in usage can be used to predict future capacity needs.

• Considering planned changes Planned changes to processes and IT systems may have an impact on predicted workload.

• Understanding long-term strategies Changes in the organization, including IT systems, business processes, and organizational objectives, may have an impact on workloads, requiring more (or less) capacity than would be extrapolated through simpler trend analysis.

• Changes in technology Several factors may influence capacity plans, including the expectation that computing and network technologies will deliver better performance in the future and that trends in the usage of technology may influence how end users use technology.

Linkage to Financial Management

One of the work products of capacity management is a projection for the acquisition of additional computer or network hardware to meet future capacity needs. This information needs to be made part of budgeting and spending management processes.

Linkage to Service Level Management

If there are insufficient resources to handle workloads, capacity issues may result in violations to SLAs. Systems and processes that are overburdened will take longer to respond. In some cases, systems may stop responding altogether.

Linkage to Incident and Problem Management

Systems with severe capacity issues may take excessive time to respond to user requests. In some cases, systems may malfunction or users may give up. Often, users will call the service desk, resulting in the logging of incidents and problems.

Service Continuity Management

Service continuity management is the set of activities that is concerned with the ability of the organization to continue providing services, primarily in the event that a natural or manmade disaster has occurred. Service continuity management is ITIL parlance for the more common terms business continuity planning and disaster recovery planning.

Business continuity is discussed in Chapter 5.

Availability Management

The goal of availability management is the sustainment IT service availability in support of organizational objectives and processes. The availability of IT systems is governed by the following:

• Effective change management When changes to systems and infrastructure are properly vetted through a change management process, changes are less likely to result in unanticipated downtime.

• Effective application testing When changes to applications are made according to a set of formal requirements, review, and testing, the application is less likely to fail and become unavailable.

• Resilient architecture When the overall architecture of an application environment is designed from the beginning to be highly reliable, it will be more resilient and more tolerant of individual faults and component failures.

• Serviceable components When the individual components of an application environment can be effectively serviced by third-party service organizations, those components will be less likely to fail unexpectedly.

NOTE   Organizations typically measure availability as a percentage of uptime of an application or service.

Asset Management

Asset management is the collection of activities used to manage the inventory, classification, use, and disposal of assets. Asset management is a foundational activity, without which several other activities could not be effectively managed, including vulnerability management, device hardening, incident management, data security, and some aspects of financial management.

In information security, asset management is critical to the success of vulnerability management. If assets are not known to exist, they may be excluded from processes used to identify and remediate vulnerabilities. Similarly, it will be difficult to harden assets if their existence is not known. And if an unknown asset is attacked, the organization may have no way of directly knowing this in a timely manner; instead, if an attacker compromises an unknown device, the attack may not be known until the attacker pivots and selects additional assets to compromise. This time lag could prove crucial to the impact of the incident.

Asset Identification

A security management program’s main objective (whether formally stated or not) is the protection of the organization’s assets. These assets may be tangible or intangible, physical, logical, or virtual. Here are some examples of assets:

• Buildings and property These assets include real estate, structures, and other improvements.

• Equipment This can include machinery, vehicles, and office equipment such as copiers, printers, and scanners.

• IT equipment This includes computers, printers, scanners, tape libraries (the devices that create backup tapes, not the tapes themselves), storage systems, network devices, and phone systems.

• Virtual assets In addition to the tangible IT equipment cited, virtual assets include virtual machines and software running on them.

• Supplies and materials These can include office supplies as well as materials that are used in manufacturing.

• Records These include business records, such as contracts, video surveillance tapes, visitor logs, and far more.

• Information This includes data in software applications, documents, e-mail messages, and files of every kind on workstations and servers.

• Intellectual property This includes an organization’s designs, architectures, patents, software source code, processes, and procedures.

• Personnel In a real sense, an organization’s personnel are the organization. Without its staff, the organization cannot perform or sustain its processes.

• Reputation One of the intangible characteristics of an organization, reputation is the individual and collective opinion about an organization in the eyes of its customers, competitors, shareholders, and the community.

• Brand equity Similar to reputation, this is the perceived or actual market value of an individual brand of product or service that is produced by the organization.

Sources of Asset Data   An organization that is building or improving its security management program may need to build its asset inventory from scratch. Management will need to determine where this initial asset data will come from. Some sources include the following:

• Financial system asset inventory An organization that keeps all of its assets on the books will have a wealth of asset inventory information. However, it may not be entirely useful: asset lists often do not include the location or purpose of the asset and whether it is still in use. Correlating a financial asset inventory to assets in actual use may consume more effort than the other methods for creating the initial asset list. However, for organizations that have a relatively small number of highly valued assets (for instance, an ore crusher in a gold mine or a mainframe computer), knowing the precise financial value of an asset is highly useful because the actual depreciated value of the asset is used in the risk analysis phase of risk management. Knowing the depreciated value of other assets is also useful, as this will figure into the risk treatment choices that will be identified later.

TIP Financial records that indicate the value of an asset do not include the value of information stored on (or processed by) the asset.

• Interviews Discussions with key personnel for purposes of identifying assets are usually the best approach. However, to be effective, several people usually need to be interviewed to be sure to include all relevant assets.

• IT systems portfolio A well-managed IT organization will have formal documents and records for its major applications. While this information may not encompass every IT asset in the organization, it can provide information on the assets supporting individual applications or geographic locations.

• Online data An organization with a large number of IT assets (systems, network devices, and so on) can sometimes utilize the capability of online data to identify those assets. An organization with cloud-based assets can use the asset management portion of the cloud services dashboard to determine the number and type of assets in use there. Also, a systems or network management system often includes a list of managed assets, which can be a good starting point when creating the initial asset list.

• Security scans An organization that has security scanning tools can use them to identify network assets. This technique will identify authorized as well as unauthorized assets.

• Asset management system Larger organizations may find it more cost effective to use an asset management application dedicated to this purpose, rather than rely on lists of assets from other sources.

None of these sources should be considered accurate or complete. Instead, as a formal asset inventory is being assembled, the security manager should continue to explore other sources of assets.

Collecting and Organizing Asset Data   It is rarely possible to take (or create) a list of assets from a single source. Rather, more than one source of information is often needed to be sure that the risk management program has identified at least the important, in-scope assets that it needs to worry about.

NOTE   As part of IT governance, management needs to determine which person or group is responsible for maintaining an asset inventory.

It is usually useful to organize or classify assets. This will help to get identified assets into smaller chunks that can be analyzed more effectively. There is no single way to organize assets, but here are a few ideas:

• Geography A widely dispersed organization may want to classify its assets according to their location. This will aid risk managers during the risk analysis phase since many risks are geographic-centric, particularly natural hazards.

• Service provider An organization utilizing one or more infrastructure-as-a-service (IaaS) providers can group its assets by service provider.

• Business process Because some organizations rank the criticality of their individual business processes, it can be useful to group assets according to the business processes they support. This helps the risk analysis and risk treatment phases because assets supporting individual processes can be associated with business criticality and treated appropriately.

• Organizational unit In larger organizations, it may be easier to classify assets according to the organizational unit they support.

• Sensitivity Usually ascribed to information, sensitivity relates to the nature and content of that information. Sensitivity usually applies in two ways: to an individual, where the information is considered personal or private, and to an organization, where the information may be considered a trade secret. Sometimes sensitivity is somewhat subjective and arbitrary, but often it is defined in laws and regulations.

• Regulation For organizations that are required to follow government and other legal obligations regarding the processing and protection of information, it will be useful to include data points that indicate whether specific assets are considered in scope for specific regulations. This is important because some regulations specify how assets should be protected, so it’s useful to be aware of this during risk analysis and risk treatment.

There is no need to choose which of these methods will be used to classify assets. Instead, an IT analyst should collect several points of metadata about each asset (including location, process supported, and organizational unit supported). This will enable the security manager to sort and filter the list of assets in various ways to better understand which assets are in a given location or which ones support a particular process or part of the business.

TIP Organizations should consider managing information about assets in a fixed-assets application.

Controls

The policies, procedures, mechanisms, systems, and other measures designed to reduce risk are known as controls. An organization develops controls to ensure that its business objectives will be met, risks will be reduced, and errors will be prevented or corrected.

Controls are used in two primary ways in an organization: they are created to ensure desired outcomes, and they are created to avoid unwanted outcomes.

Control Classification

Several types, classes, and categories of controls are discussed in this section. Figure 4-15 depicts this control classification.

Figure 4-15 Control classification shows types, classes, and categories of controls.

Types of Controls

The three types of controls are physical, technical, and administrative:

• Physical These types of controls exist in the tangible, physical world. Examples of physical controls are video surveillance, locking doors, bollards, and fences.

• Technical These controls are implemented in the form of information systems and information system components and are usually intangible. Examples of technical controls include encryption, computer access controls, and audit logs. These are also referred to sometimes as logical controls.

• Administrative These controls are the policies, procedures, and standards that require or forbid certain activities, protocols, and configurations. An example administrative control is a policy that forbids personal use of company-owned information systems. These are also referred to sometimes as managerial controls.

EXAM TIP ISACA does not expressly use the terms type, class, or category to describe and distinguish the variety of controls and their basic characteristics. Rather, these terms are used in this book to highlight the multidimensional nature of controls and how they can be understood and classified. Like other constructs, these are models that enable you to better imagine how controls operate and are used.

Classes of Controls

There are six classes of controls:

• Preventive This type of control is used to prevent the occurrence of an unwanted event. Examples of preventive controls are computer login screens (which prevent unauthorized people from accessing information), keycard systems (which prevent unauthorized people from entering a building or workspace), and encryption (which prevent people lacking an encryption key from reading encrypted data).

• Detective This type of control is used to record both wanted and unwanted events. A detective control cannot enforce an activity (whether it is desired or undesired), but instead it can only make sure that it is known whether, and how, the event occurred. Examples of detective controls include video surveillance and event logs.

• Deterrent This type of control exists to convince someone that they should not perform some unwanted activity. Examples of deterrent controls include guard dogs, warning signs, and visible video surveillance cameras and monitors.

NOTE   Security professionals generally prefer preventive controls over detective controls because preventive controls actually block unwanted events. Likewise, security professionals prefer detective controls to deterrent controls because detective controls record events while deterrent controls do not. However, there are often circumstances where cost, resource, or technical limitations force an organization to accept a detective control when it would prefer a preventive control or to accept a deterrent control when it would prefer a detective control. For example, there is no practical way to build a control that would prevent criminals from entering a bank, but a detective control (security cameras) would record what they did after they arrived.

NOTE   Security managers need to understand one key difference between preventive and deterrent controls. A deterrent control requires knowledge of the control by the potential violator—it can only deter their intentions if they know the control exists. Preventive and detective controls work regardless of whether the violator is aware of them.

• Corrective This type of control is activated (manually or automatically) after some unwanted event has occurred. An example corrective control is the act of improving a process when it is found to be defective.

• Compensating This type of control is enacted because some other direct control cannot be used. For example, a guest sign-in register can be a compensating control when it is implemented to compensate for the lack of a stronger detective control, such as a video surveillance system. A compensating control addresses the risk related to the original control.

• Recovery This type of control is used to restore the state of a system or asset to its pre-incident state. An example recovery control is the use of a tool to remove malware from a computer. Another example is the use of backup software to recover lost or corrupted files.

NOTE   Many controls can be classified in more than one class. For example, a video surveillance camera can be thought of as both a detective control (because it is part of a system that records events) and a deterrent control (because its visibility is designed to discourage persons from committing unwanted acts). Also, an audit log can be thought of as both a detective control and a compensating control—detective because it records events and compensating because it may compensate for a lack of a stronger, preventive control, such as a user IDs and password access control. The organization of controls described in this section is not based on any published standard.

Categories of Controls

There are two categories of controls:

• Automatic This type of control performs its function with little or no human judgment or decision-making. Examples of automatic controls include a login page on an application that cannot be circumvented, and a security door that automatically locks after someone walks through the doorway.

• Manual This type of control requires a human to operate it. A manual control may be subject to a higher rate of errors than an automatic control. An example of a manual control is a monthly review of computer users.

NOTE   Information security professionals generally prefer automatic controls to manual ones, as they are typically less prone to error. However, there are often circumstances where an organization must settle for a manual control because of cost or some other factor, such as the requirement for human decision and intervention, perhaps during an emergency situation or disaster, for example.

Internal Control Objectives

Internal control objectives are statements of desired states or outcomes from business operations. When building a security program, and preferably prior to selecting a control framework, it is important to establish high-level control objectives.

Example control objectives include the following:

• Protection of IT assets

• Accuracy of transactions

• Confidentiality and privacy of sensitive information

• Availability of IT systems

• Controlled changes to IT systems

• Compliance with corporate policies

• Compliance with applicable regulations and other legal obligations

Control objectives are the foundation for controls. For each control objective, one or more controls will exist to ensure the realization of the control objective. For example, the “Availability of IT Systems” control objective will be implemented via several controls, including the following:

• IT systems will be continuously monitored, and any interruptions in availability will result in alerts sent to appropriate personnel.

• IT systems will have resource-measuring capabilities.

• IT management will review capacity reports monthly and adjust resources accordingly.

• IT systems will have anti-malware controls that are monitored by appropriate staff.

Together, these four (or more) controls contribute to the overall control objective on IT system availability. Similarly, the other control objectives will have one or more controls that will ensure their realization.

After establishing control objectives, the next step is to design controls. This can be a considerable undertaking. A better approach is the selection of one of several high-quality control frameworks that are discussed later in this section.

If an organization elects to adopt a standard control framework, the next step is to perform a risk assessment to determine whether controls in the control framework adequately meet each control objective. Where there are gaps in control coverage, additional controls must be developed and put in place.

Information Systems Control Objectives

Information systems control objectives resemble ordinary control objectives but are set in the context of information systems. Examples of information systems control objectives include the following:

• Protection of information from unauthorized personnel

• Protection of information from unauthorized modification

• Integrity of operating systems

• Controlled and managed changes to information systems

• Controlled and managed development of application software

An organization will probably have several additional information systems control objectives on other basic topics such as malware, availability, and resource management.

Like ordinary control objectives, information systems control objectives will be supported by one or more controls.

General Computing Controls

An IT organization supporting many applications and services will generally have some controls that are specific to each individual application. However, IT will also have a set of controls that apply across all of its applications and services. These are usually called its general computing controls (GCCs).

An organization’s GCCs are general in nature and are often implemented in different ways on different information systems, based upon their individual capabilities and limitations, as well as applicability. Examples of GCCs include the following:

• Applications require unique user IDs and strong passwords.

• Passwords are encrypted while stored and transmitted and are not displayed.

• Highly sensitive information, such as bank account numbers, is encrypted when stored and transmitted.

• All administrative actions are logged, and logs are protected from tampering.

If you are familiar with information systems technology, you will quickly realize that these GCCs will be implemented differently across different types of information systems. Specific capabilities and limitations, for example, will result in somewhat different capabilities for password complexity and data encryption. Unless an organization is using really old information systems, the four GCCs shown here can probably be implemented everywhere in an IS environment. How they are implemented is the subject of the next section.

Control Frameworks

A control framework is a collection of controls that is organized into logical categories. Well-known control frameworks such as ISO/IEC 27001, NIST SP 800-53, and CIS 20 Controls are intended to address a broad set of information risks common to most organizations.

Standard control frameworks have been developed to streamline the process of control development and adoption within organizations. If there were no standard control frameworks, organizations would have to assemble their controls using other, inferior methods, including the following:

• Gut feel

• Prior experience in another organization

• From a security practitioner in another organization

• Searching the Internet

• A deficient or incomplete risk assessment

A security manager could perform a comprehensive risk assessment and develop a framework of controls based upon identified risks, and indeed this would not be considered unacceptable. However, with the variety of high-quality control frameworks that are freely available (exception: ISO/IEC 27001 must be purchased), an organization could start with a standard control framework for far less effort.

Selecting a Control Framework

Several high-quality control frameworks are available for organizations that want to start with a standard control framework as opposed to starting from scratch or other means. Table 4-8 lists commonly used control frameworks. Each is discussed in more detail in the remainder of this section.

Table 4-8 Commonly Used Control Frameworks

There is ongoing debate on which control framework is best for an organization. In my opinion, the fact that there is debate on the topic reveals that many do not understand the purpose for a control framework or the risk management life cycle. The common belief is that once an organization selects a control framework, the organization is “stuck” with a set of controls and no changes will be made to the controls used in the organization. Instead, as is discussed throughout this book, selection of a control framework represents a starting point, not the perpetual commitment. Once a control framework is selected, the risk management life cycle is used to understand risk in the organization, resulting in changes to the controls used by the organization. In fact, it may be argued that, in an organization practicing effective risk management, an organization will eventually arrive at more or less the same set of controls, regardless of the starting point.

A different and valid approach to control framework selection has more to do with the structure of controls than the controls themselves. Each control framework consists of logical groupings based on categories of controls. For instance, most control frameworks have sections on identity and access management, vulnerability management, incident management, and access management. Some control frameworks’ groupings are more sensible in certain organizations based on their operations or industry sector.

There is also nothing wrong with a security manager selecting a control framework based on her familiarity and experience with a specific framework. This is valid to a point, however: selecting the PCI-DSS control framework in a healthcare delivery organization might not be the best choice.

EXAM TIP   CISM candidates are not required to memorize COBIT or other frameworks, but familiarity with them will help the CISM candidate to better understand how they contribute to effective security governance and control.

Mapping Control Frameworks

Frequently, organizations find themselves in a position where more than one control framework needs to be selected and adopted. The primary factors driving this are as follows:

• Multiple applicable regulatory frameworks

• Multiple operational contexts

For example, a medical clinic delivers healthcare services and accepts payments by credit card. Both the HIPAA and PCI-DSS frameworks would be applicable in the organization, as neither HIPAA nor PCI-DSS fully addresses the security and compliance needs of the business. In another example, a U.S.-based, publicly traded electric utility will need to adopt both COSO and NERC controls.

In these two examples, the respective organizations may decide to apply each control framework only to relevant parts of the organization. For example, in the medical clinic described earlier, HIPAA would apply to systems and processes that process electronic protected healthcare information (ePHI), and PCI-DSS would apply to systems and processes that process credit card data and payments. In the electric utility, NERC controls would apply to the electric generation and distribution infrastructure while COSO would apply to financial systems. The challenge with this approach is that there will be systems and infrastructure that are in scope for two (or more) frameworks. This can make IT and security operations more complex than they would be otherwise. However, applying all frameworks in use across the entire infrastructure would most likely be overly burdensome.

Organizations with multiple control frameworks often crave a simpler organization for their controls. Often, organizations will “map” their control frameworks together, resulting in a single control framework with controls from each framework present. Mapping control frameworks together is time-consuming and tedious, although in some instances the work has already been done. For instance, Appendix H in NIST SP 800-53 contains a forward and reverse mapping between NIST SP 800-53 and ISO/IEC 27001. Other controls mapping references can be found online.

The problem with mapping controls from multiple frameworks together is that, at a control-by-control level, many controls do not neatly map together. For example, in Appendix H of NIST SP 800-53, ISO/IEC 27001 control A.15.1.2 is mapped to NIST SP 800-53 CM-10. These controls read as follows:

• NIST SP 800-53 CM-10 “The organization: a. Uses software and associated documentation in accordance with contract agreements and copyright laws; b. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and c. Controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.”

• ISO/IEC 27001:2013 A.18.1.2 “Appropriate procedures shall be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products.”

The control in NIST SP 800-53 is far more specific than the control in ISO/IEC 27001:2013. This is a good example of an imperfect mapping.

In another example, in Appendix H of NIST SP 800-53, ISO/IEC 27001:2005 control A.15.3.2 is mapped to NIST SP 800-53 AU-9. The text of each control reads as follows:

• ISO/IEC 27001:2005 A.15.3.2 “Access to information systems audit tools shall be protected to prevent any possible misuse or compromise.”

• NIST SP 800-53 AU-9 “The information system protects audit information and audit tools from unauthorized access, modification, and deletion.”

Here, these controls map together fairly neatly. Unfortunately, this is more of an exception.

Another issue you may have picked up in these examples is that the recent version of NIST SP 800-53 (revision 4) is mapped to an older version of ISO/IEC 27001—the 2005 version. When ISO/IEC 27001 was updated from the 2005 to the 2013 version, some of the controls were renumbered, and many were reworded. The new version of NIST SP 800-53 (revision 5) does map to the latest ISO/IEC 27001:2013 standard. However, since different control frameworks are updated at different times, organizations that rely on control framework mapping will often find their mappings out of date.

Working with Control Frameworks

Once an organization selects a control framework and multiple frameworks are mapped together (if the organization has decided to undertake that), security managers will then need to organize a framework of activities around the selected/mapped control framework.

Risk Assessment   Before a control can be designed, the security manager needs to have some idea of the nature of risks that a control is intended to address. In a running risk management program, a new risk may have been identified during a risk assessment that led to the creation of an additional control. In this case, information from the risk assessment is needed so that the control will be properly designed to handle these risks.

If an organization is implementing a control prior to a risk assessment, the organization might not design and implement the control properly. Here are some examples:

• A control might not be rigorous enough to counter a threat.

• A control might be too rigorous and costly (in the case of a moderate or low risk).

• A control might not counter all relevant threats.

In the absence of a risk assessment, the chances for one of these undesirable outcomes are quite high. If an organization is implementing a control, a risk assessment needs to be performed. If an organization-wide risk assessment is not feasible, then a risk assessment that is focused on the control area should be performed so that the organization will know what risks the control will be intended to address.

Control Design   An early step in control use is its design. In a control framework, the control language itself appears, as well as some degree of guidance. The security manager, together with personnel who have responsibility for relevant technologies and business processes, needs to determine what activity needs to take place. In other words, they need to figure out how to operationalize the control.

For instance, an organization wants to comply with NIST SP 800-53 control CM-7 (“The organization: a. Configures the information system to provide only essential capabilities; and b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services.”). This may require the development of one or more component hardening standards, as well as the implementation of scanning or monitoring tools to detect nonconformities. Next, one or more people will need to be assigned as the responsible parties for designing, implementing, and assessing the control. Also, the control will need to be designed in a way that makes them verifiable.

Proper control design will potentially require one or more of the following:

• New or changed policies

• New or changed business process documents

• New or changed information systems

• New or changed business records

Control Implementation   After a control has been designed, it needs to be put into service. Depending upon the nature of the control, this could involve operational impact in the form of changes to business processes and/or information systems. Changes with greater impact will require greater care so that business processes are adversely affected.

After the hardening standards are developed in the preceding example (no easy task, by the way), they will need to be tested and implemented. If a production environment is affected, this could take quite a bit of time to ensure that none of the hardening standard items adversely affects the performance, integrity, or availability of affected systems.

Control Monitoring   After an organization has implemented a control, the organization needs to monitor the control. For this to happen, the control needs to have been designed so that monitoring can take place. In the absence of monitoring, the organization will lack methodical means for observing the control to see whether it is effective.

For example, an organization identified a risk during a risk assessment that indicated that its user accounts were vulnerable to brute-force password guessing. The organization decided to change the login process on affected systems so that incorrect passwords would result in a small delay before the user could re-attempt to log on (to counter machine-driven password guessing) and that user accounts would be temporarily locked out after five unsuccessful attempts within a five-minute period. To facilitate monitoring, the organization also changed the login process to create audit log entries each time a user attempted to log in, regardless of the outcome. This provided the organization with event data that could be examined from time to time to see whether the control was performing as intended.

Some controls are not so easily monitored. For instance, a control addressing abuse of intellectual property rights includes the enactment of new acceptable use policies (AUPs) that forbid employees from violating intellectual property laws such as copyrights. There are many forms of abuse that cannot be easily monitored.

Control Assessment   Any organization that implements controls to address risks should periodically examine those controls to determine whether they are working as intended and as designed. There are several available approaches to control assessment:

• Security review One or more information security staff examines the control along with any relevant business records.

• Control self-assessment Control owners answer questions and include any relevant evidence.

• Internal audit The organization’s internal auditors (or information security staff) perform a formal examination of the control.

• External audit An external auditor formally examines the control.

An organization will select one or more of these methods, guided by any applicable laws, regulations, legal obligations, and results of risk assessments.

The four approaches listed here are described in more detail elsewhere in this chapter.

Dealing with Changing Technology   Technologies change more quickly than standard control frameworks. For this reason, security managers need to keep a close eye on emerging technologies and be “plugged in” to various business processes in the organization so that he will be involved whenever new technologies or practices are being introduced into the organization.

Changes in technologies are often, by design, disruptive. This disruption starts in markets where new products, services, and practices are developed, and it continues inside organizations that adopt them. Disruption is the result of innovation—the realization of new ideas that make organizations better in some way. Here are some examples of disruptive technologies:

• Personal computer Starting in the early 1980s, IBM and other companies sold PCs to organization departments that grew impatient with centralized IT organizations that were too slow to meet their business needs.

• Cloud computing Starting in the early 2000s, many companies developed cloud-based services for data storage and information processing. Organization departments still waiting for corporate IT to help them instead went to the cloud because it was cheaper and faster. Corporate IT followed, as IaaS providers made server operating systems available at far less cost than before. Disruptive technologies within the realm of cloud computing include virtualization, containers, microsegmentation, software-defined networks (SDNs), software-defined security (SDS), identity-defined security (IDS), ransomware, and fileless malware.

• Smartphones BlackBerry was the first widely adopted corporate smartphone, which was minimally disruptive but highly liberating for workers who could then access e-mail and other functions from anywhere. Sold mainly to consumers, Apple’s iPhone proved highly disruptive, as it provided alternative means for workers to get things done.

• Bring your own device (BYOD) Increasingly, company workers bring personal smartphones, tablets, laptop, and other personally owned devices and use them for business operations.

• Shadow IT This is the phenomenon wherein individuals, groups, departments, and business units bypass corporate IT and procure their own computing services, typically through SaaS and IaaS services but also through BYOD.

Security managers understand that they cannot be everywhere at once, nor can they be aware of all relevant activities in the organization. Individual workers, teams, departments, and business units will adopt new services and implement new technologies without informing or consulting with information security. This underscores the need for an annual risk assessment that will reveal emerging technologies and practices so that they may be assessed for risk. While a backward look at technology adoption is not ideal (because risks may be introduced at the onset of use), because security managers are not always involved in changes in the organization, a risk assessment is sometimes the method of last resort to discover risks already present in the business.

ISO/IEC 27001

ISO/IEC 27001, “Information technology – Security techniques – Information security management systems – Requirements,” is a world-renowned set of requirements and controls for building and managing an information security management system. ISO/IEC 27001 also contains a control framework in its appendix, which is explained in greater detail in ISO/IEC 27002.

The ISO/IEC 27001 appendix covers a control framework that consists of 14 control categories and 35 control objectives. Table 4-9 describes these control categories and control objectives.

Table 4-9 ISO/IEC 27001 Control Objectives

The companion standard, ISO/IEC 27002, includes implementation guidance for each of the controls listed in Table 4-9. This guidance provides additional information that helps you better understand the intent of each control, as well as ideas on how it can be implemented.

In addition to its controls, the requirements section in ISO/IEC 27001 describes the necessary activities for an effective information security management system, as shown in Table 4-10.

Table 4-10 ISO/IEC 27001 ISMS Requirements

The language in ISO/IEC 27001 requirements is written in a manner that may give the appearance of vagueness and ambiguity. However, the ISO/IEC 27001 requirements are designed to be scalable to any size organization and for organizations in any industry sector, as well as government, military, education, and nonprofit. The requirements state what must be performed, although ISO/IEC 27001 provides little implementation guidance for its requirements.

For example, ISO/IEC 27001 requirement 7.4 states that “the organization shall determine the need for internal and external communications relevant to the information security management system.” The requirement does not specify the following:

• What to say

• To whom to say it

• What medium to use

These and other considerations are in the hands of the security manager and others who are building an organization’s security management program. As long as the organization is following the ISO/IEC 27001 requirements in a way that works for the organization, that’s all that really counts.

ISO/IEC 27001 and 27002 are available from www.iso.org. These and most other ISO standards are fee-based, meaning that they must be purchased and have licensing and usage restrictions that govern their use in an organization. Generally, these standards are purchased in single quantities and are “single user” in nature, and they are not permitted to be stored on file servers for multi-user usage.

NIST SP 800-53

NIST SP 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” is published by the Computer Security Division of the U.S. National Institute for Standards and Technology. A summary of controls in NIST SP 800-53 appears in Appendix D, “Security Control Baselines,” and detailed descriptions of all controls is found in Appendix F, “Security Control Catalog.”

NIST SP 800-53 includes the concept of Low, Medium, and High baselines. These baselines represent collections of controls to be implemented according to the impact level of the information system. In other words, for an information system classified as high impact, the controls to be selected would come from the High baseline in Appendix D. Then, within each control, an organization would implement any stated control enhancements, again based on impact level.

Table 4-11 lists the categories of controls in NIST SP 800-53. NIST SP 800-53 is available from http://csrc.nist.gov/publications/PubsSPs.html. The standard is available without cost or registration.

Table 4-11 NIST SP 800-53 Control Categories

Center for Internet Security 20 Controls

The Center for Internet Security (CIS) maintains a popular and respected control framework called the CIS Controls or commonly known as the CIS 20. Still referred to as the SANS 20 Critical Security Controls, this control framework was originally developed by the SANS Institute.

Regarded as a simpler set of security controls, the CIS Controls framework has been widely adopted by organizations seeking a control framework, while avoiding more burdensome frameworks like NIST SP 800-53 or ISO/IEC 27001 controls, which must be purchased.

Table 4-12 shows the structure of the CIS Control framework.

Table 4-12 CIS Control Framework (Source: The Center for Internet Security (CIS) www.cisecurity.org)

The CIS Control framework is structured in a way that makes it easier for security practitioners to understand and use. Within each control category, there is a section entitled “Why Is This Control Critical?” followed by the individual controls. This is followed by a section called “Procedures and Tools” that provides additional guidance. Finally, each control category includes a system entity relationship diagram that depicts the control’s implementation in an environment. Many consider the CIS Controls as more pragmatic and less academic than NIST SP 800-53 or PCI-DSS.

The CIS Control framework includes one or more controls within each control category. Some controls are flagged as “foundational,” meaning they are essential in any organization. The controls not marked as “foundational” may be considered optional.

Some controls include advanced implementation guidelines. For instance, control 8.3 (“Limit use of external devices to those with an approved, documented business need. Monitor for use and attempted use of external devices. Configure laptops, workstations, and servers so that they will not auto-run content from removable media, like USB tokens [i.e., “thumb drives”], USB hard drives, CDs/DVDs, FireWire devices, external serial advanced technology attachment devices, and mounted network shares. Configure systems so that they automatically conduct an anti-malware scan of removable media when inserted.”) includes in its advanced guidance, “Actively monitor the use of external devices (in addition to logging).”

The CIS Control framework is available from www.cisecurity.org/critical-controls.cfm without cost, although registration may be required.

Cyber Security Framework

The NIST Cyber Security Framework (CSF) is a risk management methodology and control framework designed for organizations that want a single standard for identifying risk and implementing controls to protect information assets. Developed by the U.S. National Institute for Standards and Technology (NIST) and initially released in 2014, the CSF appears to be gaining acceptance in organizations lacking regulations requiring specific control frameworks (such as HIPAA for organizations in the healthcare industry).

The CSF consists of a framework core comprising five key activities in a security management program. These activities are as follows:

• Identify Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities.

• Protect Develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services.

• Detect Develop and implement the appropriate activities to identify the occurrence of a cybersecurity event.

• Respond Develop and implement the appropriate activities 319 to take action regarding a detected cybersecurity event.

• Recover Develop and implement the appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired because of a cybersecurity event.

The CSF contains a methodology that an organization can use to assess the overall capability of the organization’s overall information security program. The capabilities assessment resembles a maturity assessment, where the program is determined to be in one of the following tiers:

• Partial Risk management is not formalized but instead is reactive and limited to few in the organization. There are no formal relationships with external entities, and supply chain risk management (SCRM) processes are not formalized.

• Risk Informed Risk management is formalized but not working organization-wide. External relationships are established but not formalized. Supply chain risk management processes occur but are not formalized.

• Repeatable Risk management practices are formal and approved. The risk management program is integrated into the business. External parties are engaged more so that the organization can respond to events. Supply chain risk management process is governed.

• Adaptive Risk management practices are monitored and adapted to meet changing threats and business needs. The risk management program is fully integrated into the organization’s business and process. The organization shares information with external parties on a methodical basis, and receives information as well, to prevent events. The supply chain risk management process provides high-level risk awareness to management.

These maturity ratings are similar to those used in the Software Engineering Institute Capability Maturity Model (SEI-CMM) and others.

The CSF contains a methodology for establishing or making improvements to an information security program. The steps in this methodology are similar to the structure in this book:

• Step 1: Prioritize and Scope Here, the organization determines which business units or business processes are part of the scope of a new or improving program.

• Step 2: Orient The organization identifies assets that are in scope for the program; the risk approach; and applicable laws, regulations, and other legal obligations.

• Step 3: Create a Current Profile The organization identifies the category and subcategory outcomes from the Framework Core (the CSF controls) that are currently in place.

• Step 4: Conduct a Risk Assessment Here, the organization conducts a risk assessment covering the entire scope of the program. This is an ordinary risk assessment like those described throughout this book, where threats (together with their likelihood and impact) are identified for each asset or asset group.

• Step 5: Create a Target Profile The organization determines the desired future states for each of the framework’s categories and subcategories (the controls). This includes the desired tier level for each category and subcategory.

• Step 6: Determine, Analyze, and Prioritize Gaps The organization compares the current profile (developed in step 3) and the target profile (step 5) and develops a list of gaps. These gaps are analyzed and prioritized, and the necessary resources to close gaps are identified. A cost-benefit analysis is performed, which also helps with prioritization.

• Step 7: Implement Action Plan The organization develops plans to close gaps identified and analyzed in step 6. After action plans have been completed, controls are monitored for compliance.

Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard (PCI-DSS) is a control framework whose main objective is the protection of cardholder data. PCI-DSS was developed by the PCI Security Standards Council, a nonprofit organization started by the major credit card brands in the world including Visa, MasterCard, American Express, Discover, and JCB.

Table 4-13 shows the two-tiered structure of PCI-DSS.

Table 4-13 PCI-DSS Control Framework (Source: PCI Security Standards Council, www.pcisecuritystandards.org.)

The PCI Security Standards Council has also defined business rules around the PCI-DSS standard. There is a tier structure based on the number of credit card transactions; organizations whose credit card volume exceeds set limits are subject to on-site annual audits, while organizations with lower volumes are permitted to complete annual self-assessments. There is also a distinction between merchants (retail and wholesale establishments that accept credit cards as a form of payment) and service providers (all other organizations that store, process, or transmit credit card data); service providers are required to comply with additional controls.

The PCI Security Standards Council also has a program of annual training and exams for personnel who can perform PCI audits and for the organizations that employ those people. The certifications are as follows:

• Payment Card Industry Qualified Security Assessor (PCI-QSA) These are external auditors who perform audits of merchants and service providers that are required to undergo annual audits (as well as organizations that undertake these audits voluntarily).

• Payment Card Industry Internal Security Assessor (PCI-ISA) These are employees of merchants and service providers required to be compliant with the PCI-DSS. The PCI Security Standards Council does not require any employees of merchants or service providers to be certified to PCI-ISA; however, the certification does help those so certified to better understand the PCI-DSS standard, thereby leading to better compliance.

• Payment Card Industry Professional (PCIP) This is an entry-level certification for IT professionals who want to learn more about the PCI-DSS standard and earn a certification that designates them as a PCI subject-matter expert.

The PCI Security Standards Council has published additional requirements and standards, including the following:

• Payment Application Data Security Standard (PA-DSS) This is a security standard for commercial credit card payment applications.

• PCI Forensic Investigator (PFI) Requirements for organizations and individuals who will perform forensic investigations of credit card breaches.

• Approved Scanning Vendors (ASV) Requirements for organizations that will perform security scans of merchants and service providers.

• Qualified Integrators and Resellers (QIR) Requirements for organizations that sell and integrate PCI-certified payment applications.

• Point-to-Point Encryption (P2PE) This is a security standard for payment applications that utilize point-to-point encryption of card data.

• Token Service Providers (TSP) Physical and logical security requirements and assessment procedures for token service providers that generate and issue EMV payment tokens.

• PIN Transaction Security (PTS) Requirements for the secure management, processing, and transmission of personal identification number (PIN) data during online and offline transactions at ATMs and POS terminals.

Health Insurance Portability and Accountability Act

The U.S. Health Insurance Portability and Accountability Act (HIPAA) was enacted in 2008 to address a number of issues around the processing of healthcare information, including the protection of healthcare information in electronic form, commonly known as electronic protected healthcare information (ePHI). Organizations that deliver medical care, as well as organizations with access to such information, including medical insurance companies and most employers, are required to comply with HIPAA Security Rule requirements. Table 4-14 shows the structure of the HIPAA Security Rule.

Table 4-14 Requirement Sections in the HIPAA Security Rule

Each requirement in the HIPAA Security Rule is labeled as Required or Addressable. Requirements that are Required must be implemented. For those requirements that are Addressable, organizations are required to undergo analysis to determine whether they must be implemented.

COBIT 5

To ensure that a security program is aligned with business objectives, the COBIT 5 control framework of 5 principles and 37 processes is an industry-wide standard. The five principles are as follows:

• Meeting Stakeholder Needs

• Covering the Enterprise End-to-End

• Applying a Single, Integrated Framework

• Enabling a Holistic Approach

• Separating Governance from Management

COBIT 5 contains more than 1100 control activities to support these principles.

Established in 1996 by ISACA and the IT Governance Institute, COBIT is the result of industry-wide consensus by managers, auditors, and IT users. Today, COBIT 5 is accepted as a best-practices IT process and control framework. Starting with Version 5, COBIT has absorbed ISACA’s Risk IT Framework and Val IT Framework.

COSO

The Committee of Sponsoring Organizations of the Treadway Commission (COSO) is a private-sector organization that provides thought leadership through the development of frameworks and guidance on enterprise risk management, internal control, and fraud deterrence. Its control framework is used by U.S. public companies for management of their financial accounting and reporting systems.

COSO is a joint initiative of the following private-sector associations:

• American Accounting Association (AAA)

• American Institute of Certified Public Accountants (AICPA)

• Financial Executives International (FEI)

• The Association of Accountants and Financial Professionals in Business (IMA)

• The Institute of Internal Auditors (IIA)

The COSO framework is constructed through a set of 17 principles within 5 framework components, which are shown in Table 4-15. The COSO framework itself is proprietary and can be purchased from www.coso.org.

Table 4-15 COSO Framework and Principles

Figure 4-16 depicts the multifaceted structure of the COSO framework.

Figure 4-16 COSO framework components

NERC Reliability Standards

The North American Electric Reliability Corporation (NERC) develops standards for use by electric utilities in most of North America. These standards encompass all aspects of power generation and distribution, including security. Table 4-16 shows the security portion of NERC standards.

Table 4-16 NERC Critical Infrastructure Protection Framework

Prior to the Northeast Blackout of 2003, NERC standards were voluntary. The Energy Policy Act of 2005 authorized the Federal Energy Regulatory Commission (FERC) to designate NERC standards as mandatory. NERC has the authority to enforce its standards and does so through audits and levies fines to public utilities that are noncompliant.

CSA Control Framework

The Cloud Security Alliance (CSA) has developed a control framework known as the Cloud Controls Matrix (CCM) that is designed to provide security principles to cloud vendors and to assist customers with assessments of cloud vendors.

Table 4-17 shows the structure of the CSA CCM.

Table 4-17 Domains of the Cloud Security Alliance Cloud Controls Matrix

The Cloud Security Alliance has developed an assurance framework known as CSA STAR that includes three assurance levels:

• Self-assessment

• Third-party assessment-based certification

• Continuous monitoring-based certification

Service Organization Controls

The trend of IT outsourcing has continued unabated and is even accelerating with so many organizations shifting to cloud-based applications and infrastructure. Obtaining assurance that IT controls exist and are effective in these third-party organizations can be cost-prohibitive: most organizations’ internal IT audit functions do not have sufficient resources to audit even the topmost critical service providers. And most service providers will not permit their customers to audit their controls as this is also costly for service providers.

In the early 1990s, the American Institute for Certified Public Accountants (AICPA) developed the Statement on Auditing Standards No. 70 (SAS-70) standard that opened the door for audits that could be performed by public accounting firms on service providers, with audit reports made available to service providers’ customers. After the Sarbanes–Oxley Act (SOX) took effect in 2003, SAS70 audits of service providers satisfied the requirements for U.S. public companies to obtain assurance of control effectiveness for outsourced IT service providers, particularly those that supported financial applications.

The SOC1, SOC2, and SOC3 audit standards are discussed next.

Service Organization Controls 1   In 2010, the SAS-70 standard was superseded by the Statement on Standards for Attestation Engagements No. 16 (SSAE16) standard in the United States and by International Standards for Assurance Engagements No. 3402 (ISAE3402) outside the United States. In 2017, SSAE16 was replaced with SSAE18. SSAE16, SSAE18, and ISAE3402 are commonly known as Service Organization Controls 1 (SOC1).

In a SOC1 audit, the service organization specifies the controls that are to be audited. While a service organization has complete latitude on which controls are in scope for a SOC1 audit, the service organization must be mindful of which controls its customers and their internal and external auditors will expect to see in a SOC1 audit report.

There are two basic types of SOC1 audits:

• Type I This is a point-in-time examination of the service organization’s controls and their design.

• Type II This is an audit that takes place over a period of time (typically six months to one year), where the auditor examines not only the design of in-scope controls (as in the Type I) but also business records that reveal whether controls are effective.

SOC1 audits must be performed by CPA firms in good standing.

Service Organization Controls 2   The Service Organization Controls 2 (SOC2) audit standard was developed for IT service providers of all types that want to demonstrate assurance in its controls to its customers.

A SOC2 audit of a service provider is an audit of one or more of the following five trust principles:

• Security The system is protected against unauthorized access.

• Availability The system is available for operation and use as committed or agreed.

• Processing integrity System processing is complete, valid, accurate, timely, and authorized.

• Confidentiality Information designated as confidential is protected as committed or agreed.

• Privacy Personal information is collected, used, retained, disclosed, and destroyed in accordance with the privacy notice commitments.

There are several controls within each trust principles. All controls within each selected trust principle are included in a SOC2 audit.

There are two basic types of SOC2 audits:

• Type I This is a point-in-time examination of the service organization’s controls and their design.

• Type II This is an audit that takes place over a period of time (typically six months to one year), where the auditor examines not only the design of in-scope controls (as in the Type I) but also business records that reveal whether controls are effective.

SOC1 audits must be performed by CPA firms in good standing.

Service Organization Controls 3   A Service Organization Control 3 (SOC3) audit is similar to a SOC2 audit, except that a SOC3 report lacks a description of control testing or opinion of control effectiveness. Like a SOC2, a SOC3 audit includes any or all of the five trust principles: security, availability, processing integrity, confidentiality, and privacy.

Controls Development

The development of controls is a foundational part of any security program. To develop controls, a security manager must have an intimate level of knowledge of the organization’s mission, goals, and objectives, as well as a good understanding of the organization’s degree of risk tolerance. Figure 4-17 illustrates the relationship between an organization and the fundamentals of a security program.

Figure 4-17 Relationship between an organization’s mission, goals, objectives, risk tolerance, policies, and controls

As stated elsewhere in this book, the most common approach to controls development is the selection of an already-established control framework, such as any of those discussed earlier in this section. However, an organization is also free to develop a control framework from scratch. Table 4-18 illustrates the pros and cons of each approach.

Table 4-18 Controls Development Comparison

Developing Controls from Scratch

For organizations that have elected to develop their controls from scratch, the first step is the development of high-level control objectives. These control objectives could be thought of as overarching principles, out of which individual controls will be developed.

Control objectives are typically similar from organization to organization. However, since each organization is different, some organizations will have one or two unique control objectives that address specific business activities or objectives.

Table 4-19 shows a sample set of control objectives.

Table 4-19 Sample Control Objectives

Developing Control Details

Whether the organization adopts an existing control framework or develops controls from scratch, the security manager must develop several elements for each control. These elements include the following:

• Control number The index number assigned to this control, according to the control numbering scheme adopted by the organization. This could be a simple number (e.g., 1, 2, 3) or a hierarchical number (e.g., 10.5.4).

• Mapping Any relationships of this control to one or more controls in other control frameworks, whether those other control frameworks are specific to the organization or they are industry-standard control frameworks.

• Title The title or name of the control.

• Control objective In a control framework with high-level control objectives, this is a statement of a desired activity.

• Narrative A detailed description of the control. Generally, this should not include implementation details (which could vary from system to system or from place to place) but instead the details needed so that a business owner, auditor, or IT worker understands the intent of the control. There should be enough detail so that IT workers and other personnel can properly implement the control.

• Scope The locations, business units, departments, or systems that are affected by the control.

• Risk A description of the risk that this control is intended to address.

• Owner The business owner (or owners) of the control.

• Affected and related business processes The business processes related to the control, as well as the business processes affected by the control.

• Control frequency How often the control is performed, executed, or used.

• Classification This includes whether it is automatic or manual, preventive or detective, and other classification details.

• Testing procedure The steps required to evaluate the control for effectiveness. Like the control narrative, this should be a general description and not specific to any particular technology.

• Developed by The name of the person who developed the control.

• Approved by The name of the person who approved the control.

• Approval date The date of the most recent approval of the control.

• Version The version number of the control, according to whatever version numbering system is used by the organization.

• Cross-references Cross-references to other controls, control frameworks, systems, documents, departments, processes, risk assessments, or risk treatment. Cross-references can help personnel better understand how controls relate to other activities or events in the organization.

• Modification history A list of the changes made to the control, including a description, who made each change, who approved each change, and the date.

While organizations may prefer to document its controls in worksheets, a better approach is the development of individual documents for each control. This will lead to better outcomes as it will be easier to control versions of individual control documents.

Control Assessment

Control assessment consists of activities intended to determine whether individual controls or groups of controls are effectively functioning. Controls can be assessed in several ways, including the following:

• Internal audit

• External audit

• Control self-assessment

These techniques are discussed in detail earlier in this chapter in the “Audits” section.

Metrics and Monitoring

A metric is a measurement of a periodic or ongoing activity for the purpose of understanding the activity within the context of overall business operations. Metrics is the use of collecting these measurements and revealing or publishing them to various business audiences.

In the context of 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 of 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.

Types of Metrics

There are many different activities and events in an information security program and its controls that can be measured, as well as different ways of depicting and explaining those measurements. When building and improving an information security program, security managers need to understand that there is no single framework of metrics. Instead, security managers need to determine what metrics are important for various audiences and purposes and proceed to develop those metrics.

One of the most important aspects of metrics is context. Producing raw numbers such as the number of packets dropped by an Internet firewall rarely has meaning to any audience. Security managers need to develop metrics that have appropriate context for whatever audience they are intended.

Aside from automated systems that keep records that can be examined later, there is often little point in developing metrics that have no audience. Such a pursuit would only take time away from more valuable activities.

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 willingness and ability for the organization to initiate corrective action when noncompliant activities occur.

Organizational Awareness

Organizational awareness metrics help management understand the number of workers who understand security policies and requirements and how well they are known. 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 are used to perform essential functions. Productivity metrics can help build business cases for 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

Operational support metrics show the degree of support of organizational objectives. Arguably this is a subjective metric, as it can be difficult to produce meaningful measurements. While 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.

Technical Security Architecture

Technical security architecture metrics are typically the measures of events taking place in automated systems such as firewalls, intrusion detection and prevention systems, data loss prevention systems, spam filters, and anti-malware systems. This is generally the richest set of metrics data available to a security manager but also a category of metrics that is often presented without proper business context. For example, the number of attacks blocked by a firewall or the number of malware infections blocked by anti-malware software may have operational meaning, but these will mean nothing to management. Executives would be right to ask whether an increase in the number of 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, intrusion detection and prevention systems, and web filters, which resulted in unscheduled downtime

• Number of malware attacks that circumvented anti-malware 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 onset of a security incident and incident declaration

• Elapsed time between 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 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 are used to measure the resources required for key controls. Security managers need to be careful with cost efficiency metrics, as demands for improvement (e.g., reduced costs) over time can result in increased risk. This is compounded by the fact that it is relatively easy to measure cost, whereas the measurement of risk is more subjective and qualitative.

Example cost efficiency metrics include the following:

• Cost of anti-malware controls per user

• Cost of anti-phishing and anti-spam controls per user

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

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

Audiences

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 person. For example, a metric showing the number of packets dropped by a firewall will have absolutely no meaning to a board of directors—nor would a trend of this metric or time have any meaning.

Some metrics will have only operational value, while other operational metrics 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, successful malware attacks that result in business disruptions have far more meaning. Or, a metric on patch management SLAs by itself has no business context, but transforming that into a metric showing critical systems not patched within SLAs depicts higher-than-desired business risk and makes sense to executive audiences.

Continuous Improvement

Continuous improvement represents the desire to increase the efficiency and effectiveness of processes and controls over time. It could be said that continuous improvement is a characteristic of an organization’s culture. The pursuit of continuous improvement is a roundabout way of pursuing quality.

A requirement in ISO/IEC 27001 requires that management promote continual improvement and that security policy include a commitment to the continual improvement of the ISMS. ISO/IEC 27001 also requires that management review of the ISMS identify opportunities for continual improvement. The standard also explicitly requires organizations to “continually improve the suitability, adequacy, and effectiveness of its information security management system.”

NIST SP800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” similarly requires that an organization’s risk management program incorporate a feedback loop for continuous improvement. Control SA-15 (6) states the following: “The organization requires the developer of the information system, system component, or information system service to implement an explicit process to continuously improve the development process.”

The NIST Cyber Security Framework cites the requirement for continuous improvement throughout the standard. For instance, in the seven steps for creating an information security program, NIST CSF asserts in section 3.2 that “these steps should be repeated as necessary to continuously improve cybersecurity.”

Chapter Review

An information security program is comprised of activities used to identify and treat risks. At tactical and strategic levels, all activities in a program fulfill this purpose. A security program is also outcomes-based; when a strategy is developed, the objectives of the strategy are desired end states, or outcomes. Tasks and projects carried out in the program bring the organization closer to these desired outcomes.

A charter document defines the main, long-term objectives of a security program, and it defines roles and responsibilities. The charter will typically define the scope of a program—the departments, business units, and locations that will be subject to the program. A road map is a strategic document that describes the steps to be taken to realize key objectives.

Security management frameworks are models for the overall operation of a security program. Typically, these frameworks are high level and include key activities such as risk management and governance.

Security architecture represents the overall vision as well as the details that define the role of technology and asset protection. The Open Group Architecture Framework (TOGAF) and the Zachman framework are two architecture frameworks that can be used to build a security architecture.

Security governance is the set of activities that enable management to have visibility and exert control over the security program. A key to successful governance is to establish a security steering committee or security council consisting of stakeholders from across the business.

Risk management is a life-cycle process used to identify, analyze, and treat risks. The four options for risk treatment are accept, mitigate, transfer, and avoid. These risk treatment decisions should be made by senior management or by an executive-level steering committee. Proceedings including risk decisions should be documented and maintained as part of the security program’s business record.

The risk management life cycle consists of regular and ad hoc risk assessments. In a typical risk assessment, assets and threats against them are identified and evaluated. Risk analysis is a detailed activity that is used to better understand individual risks and to explore various risk mitigation and risk treatment options.

A risk assessment consists of asset identification, threat analysis, vulnerability identification, probability, and impact analysis. The risk assessment continues with qualitative, semiquantitative, or quantitative risk analysis.

Organizations undertake internal and external audits and reviews as part of its overall effort to determine the effectiveness of its controls. Like risk assessments, the organization needs to properly scope and empower audit projects so that there are sufficient resources to successfully perform and complete the audit. Control self-assessments are a form of internal audit, performed by control owners as a means for reinforcing accountability for the effectiveness of controls.

When developing security policies, the security manager needs to carefully weigh many considerations including applicable laws, risk tolerance, controls, and organizational culture. Security policy needs to align with the business and also with its controls.

Third-party risk management is a critical activity whose purpose is to identify risks in third-party organizations that have access to critical or sensitive data or that perform critical operational functions. Various techniques are needed to identify and manage risks since many third parties are less than transparent about their internal operations and risks.

Security programs include a variety of administrative activities that are vital to its success. One important success factor is the development of strategic partnerships with many internal departments in an organization, as well as external organizations and agencies. These partnerships enable the security manager to better influence internal events, learn more about external events, and obtain assistance from outside entities as needed.

Security managers need to understand how to develop business cases to secure funding for security projects. Rather than focus on return on investment (ROI), security managers need to focus on risk reduction and how each project contributes toward the fulfillment of strategic objectives.

Event monitoring is the activity whereby security events that occur in information systems will be made known to security personnel who can act on them to correct situations and avoid incidents.

Vulnerability management is the activity where tasks are carried out to identify vulnerabilities in information systems, which are followed by remediation such as installing security patches or changing security configurations.

Secure engineering and development is focused on the safe development of applications and systems that are free of exploitable security defects by design and also on the protection of systems and information related to engineering and development such as source code.

Several means are used to protect networks (and the systems and applications that reside on them) including firewalls, network segmentation, intrusion prevention systems, network anomaly detection, packet sniffers, web content filters, cloud access security brokers, DNS filters, spam and phishing filters, and network access control.

Endpoint systems, including desktop computers, laptop computers, tablet computers, and smartphones, require particular protective controls to protect them from compromise.

Identity and access management is comprised of technologies and activities to ensure that only authorized personnel have access to systems and information.

Because so many security incidents are a result of human error, security awareness training is an essential activity that helps all personnel better understand the hazards caused by poor judgment and lapses in attention.

Data security controls help to ensure that only authorized personnel are able to access, add, delete, and update business information. Several controls are often used in combination to protect information, including access controls, cryptography, backup and recovery, data loss prevention, cloud access security brokers, and user behavior analytics.

IT service management represents a collection of operational activities designed to ensure the quality of IT services. These activities include several business processes including service desk, incident management, problem management, change management, configuration management, release management, service-level management, financial management, capacity management, service continuity management, and availability management.

Controls and control frameworks are used to enforce desired outcomes. Controls need to be carefully considered, as each consumes resources. Security managers need to understand the various types of controls (e.g., preventive, detective, deterrent, manual, automatic, etc.) so that the right types of controls can be implemented.

Metrics are used to measure key activities and are used to determine whether key objectives are being met. Security managers need to select metrics carefully and consider the audience for each.

Notes

• Involving stakeholders from across the business will help ensure the success of a security program. This is because stakeholders will feel that they have a voice in how security is managed in the organization.

• In a typical security program, the security manager will select a control framework as a starting point and then add, change, or remove controls over time as a result of the risk management process. The initial control framework should be considered only a starting point and not the set of controls that the organization is required to permanently manage.

• When performing a risk assessment, the security manager will typically select assets to be assessed and will use a generic list of typical threats such as the list contained in NIST SP 800-33, “Guide for Conducting Risk Assessments.” The security manager will add other relevant threats to this list.

• The outcome of risk assessments may result in one or more additions to the organization’s risk register.

• While security policy should cover a wide range of topics, the security manager is free to include them in a comprehensive document or in separate documents.

• Third-party risk management is best thought of as an extension of an organization’s risk management program, with special procedures for conducting risk assessments of third-party organizations that store, process, or transmit sensitive or critical data on behalf of the organization or that perform critical operations.

• Because of the worldwide shortage of qualified security personnel, it is especially important for the security manager to pay particular attention to the state and development of security staff to ensure they are engaged, challenged, and adequately compensated.

• Security managers need to avoid the return on investment or return on security investment trap and focus budget efforts instead on risk reduction.

• Security managers should resist the temptation to utilize every type of network protection technology and instead implement those in response to specific risks and threats.

• As an organization moves away from individual system and application authentication to centralized authentication, the implementation of stronger password controls as well as multifactor authentication becomes more important. This is because the consequences of compromised credentials increases since those credentials provide access to potentially many systems.

• Despite the most effective controls and the best intentions on the part of security personnel, employees who are intent on stealing internal information are usually able to do so. Rather than invest everything in preventive controls, some attention to detective controls is warranted.

• Without effective IT service management, no security manager can hope that information security will become truly effective.

• Security managers prefer preventive controls but will sometimes need to settle on detective controls.

• The selection of a control framework is less important than the risk management process that will, over time, mold it into the controls that need to exist.

• Many organizations need to implement multiple control frameworks in response to applicable regulations and other obligations. In such cases, security managers should consider mapping them into a single control framework.

• For security metrics, context and audience are critical.

• There is always room for improvement.

Questions

1. The purpose of security governance is to:

A. Make risk treatment decisions.

B. Enforce violations of information security policy.

C. Provide management with visibility and control of the security program.

D. Ensure compliance with applicable laws and regulations.

2. The purpose of risk management is to:

A. Identify risks and make decisions about them.

B. Control risk mitigation activities.

C. Facilitate risk assessments and risk analysis.

D. Facilitate the achievement of strategic program objectives.

3. The definition of risk is:

A. Threat times impact

B. Threat plus vulnerability

C. Threat times vulnerability

D. Probability times impact

4. The identification of unwanted events and their likelihood of occurrence is known as:

A. Risk analysis

B. Vulnerability analysis

C. Threat analysis

D. Probability analysis

5. A weakness in a system that makes it possible for an attacker to successfully compromise it is known as a:

A. Threat

B. Vulnerability

C. Risk

D. Patch

6. The purpose of quantitative risk analysis is to:

A. Update financial statements with risk scenarios.

B. Understand the potential cost of a breach.

C. Understand the probability of a breach.

D. Determine the most likely method of a breach.

7. The four options for risk treatment are:

A. Mitigate, transfer, avoid, accept

B. Accept, share, transfer, ignore

C. Ignore, accept, share, mitigate

D. Mitigate, ignore, share, accept

8. The best place to document new risks is:

A. Asset ledger

B. Risk ledger

C. Incident log

D. GRC system

9. The purpose of control self-assessments is to:

A. Transfer risk to control owners.

B. Reduce audit costs.

C. Reduce workload in internal audit.

D. Reinforce accountability for control effectiveness.

10. The purpose of security policy is:

A. Comply with regulations requiring policy.

B. Enforce accountability for all employees.

C. Restate security controls in everyday language.

D. Define acceptable and unacceptable behavior.

11. The best method for identifying third-party service organizations is to:

A. Inventory all legal agreements.

B. Examine firewall access logs.

C. Consult with legal, procurement, and IT.

D. Consult with accounting and legal.

12. The purpose of event monitoring to is:

A. Identify anomalous behavior on the part of employees.

B. Confirm that all systems and devices are performing adequately.

C. Confirm that all systems and devices are in compliance with policy.

D. Identify unwanted events that could be a sign of a security breach.

13. The purpose of vulnerability management is to:

A. Identify and remediate vulnerabilities in all systems.

B. Transfer vulnerabilities to low risk systems.

C. Identify exploitable vulnerabilities in all systems.

D. Transfer vulnerabilities to third parties.

14. Intrusion prevention systems are different from firewalls because:

A. Their rules can be changed automatically.

B. They examine the contents of headers instead of the entire payload.

C. They examine the contents of packets instead of just the headers.

D. They alert personnel about threats but do not stop them.

15. The purpose of web content filters is to:

A. Permit management to track who visits which web sites.

B. Block user access to web sites that pose a threat.

C. Block user access to web sites that are a waste of time.

D. Scan content for malware.

Answers

1. C. The purpose of security governance is to create a means by which executive management is made aware of developments in the organization’s security program and to enable them to control outcomes in the program.

2. A. Risk management is the life-cycle process whereby new risks are identified, analyzed, and decisions made concerning their disposition.

3. D. The definition of risk is probability × impact.

4. C. Threat analysis is the examination of all reasonable threats.

5. B. A vulnerability is a weakness in a system that could be exploited by an attacker.

6. B. Quantitative risk analysis is used to determine the potential cost of a breach.

7. A. The four options for risk treatment are mitigate, transfer, avoid, and accept.

8. B. New risks are recorded in the organization’s risk ledger.

9. D. Control self-assessments involve control owners and empower them to identify problems with their controls.

10. D. Security policy, and every other policy, defines acceptable and unacceptable behavior.

11. C. The best method for identifying an organization’s third-party service organizations is to work with key departments including IT, legal, procurement, finance, and others.

12. D. Event monitoring is used to identify events that could be a sign of unwanted behavior including a security breach.

13. A. The purpose of vulnerability management is to identify vulnerabilities in information systems and devices and to remediate vulnerabilities on a schedule according to risk.

14. C. The main difference between intrusion prevention systems and firewalls is that intrusion prevention systems examine the entire contents of packets, whereas firewalls examine only packet headers.

15. B. The main purpose of web content filters is to block user access to web sites that pose a threat of some kind.