CHAPTER 2

Information Security Governance

In this chapter, you will learn about

• Business alignment

• Security strategy development

• Security governance activities

• Information security strategy development

• Resources needed to develop and execute a security strategy

• Obstacles to strategy development and execution

• Information security metrics

The topics in this chapter represent 24 percent of the Certified Information Security Manager (CISM) examination. This chapter discusses CISM job practice 1, “Information Security Governance.”

ISACA defines this domain as follows: “Establish and/or maintain an information security governance framework and supporting processes to ensure that the information security strategy is aligned with organizational goals and objectives.”

Security governance should be the wellspring from which security-related strategic decisions and all other security activities flow.

Properly implemented, governance is a process whereby senior management exerts strategic control over business functions through policies, objectives, delegation of authority, and monitoring. Governance is management’s oversight for all other business processes to ensure that business processes continue to effectively meet the organization’s business vision and objectives.

Organizations usually establish governance through a steering committee that is responsible for setting long-term business strategy, and by making changes to ensure that business processes continue to support business strategy and the organization’s overall needs. This is accomplished through the development and enforcement of documented policies, standards, requirements, and various reporting metrics.

Introduction to Information Security Governance

Information security governance typically focuses on several key processes. Those processes include personnel management, sourcing, risk management, configuration management, change management, access management, vulnerability management, incident management, and business continuity planning. Another key component is the establishment of an effective organization structure and clear statements of roles and responsibilities. An effective governance program will use a balanced scorecard, metrics, or other means to monitor these and other key processes. Through a process of continuous improvement, security processes will be changed to remain effective and to support ongoing business needs.

Information security is a business issue, and organizations that are not yet adequately protecting their information have a business problem. The reason for this is almost always a lack of understanding and commitment by boards of directors and senior executives. For many, information security is only a technology problem at the tactical level. Recent events have brought the issue of information security to the forefront for many organizations. The challenge is that because of a lack of awareness or cybersecurity savviness, organizations still struggle with how to successfully organize, manage, and communicate about it at the boardroom level.

To be successful, information security is also a people issue. When people at each level in the organization—from boards of directors to individual contributors—understand the importance of information security and their own roles and responsibilities, an organization will be in a position of reduced risk. This reduction in risk or identification of a potential security event results in fewer incidents that, when they do occur, will have lower impact on the organization’s ongoing reputation and operations.

Information security governance is a set of activities that are established so that management has a clear understanding of the state of the organization’s security program, its current risks, and its direct activities. A goal of the security program is to continue to contribute toward fulfillment of the security strategy, which itself will continue to align to the business and business objectives. Whether the organization has a board of directors, council members, commissioners, or some other top-level governing body, governance begins with the establishment of top-level strategic objectives that are translated into actions, policies, processes, procedures, and other activities downward through each level in the organization.

For information security governance to be successful, an organization must also have an effective IT governance program. IT is the enabler and force multiplier that facilitates business processes that fulfill organization objectives. Without effective IT governance, information security governance will not be able to reach its full potential. The result may be that the proverbial IT bus will travel safely but to the wrong destination. This is depicted in Figure 2-1.

Figure 2-1 Vision flows downward in an organization.

While the CISM certification is not directly tied to IT governance, this implicit dependence of security governance on IT governance cannot be understated. IT and security professionals specializing in IT governance itself may be interested in ISACA’s Certified in the Governance of Enterprise IT (CGEIT) certification, which specializes in this domain. While IT governance and information security governance may be separate, in many organizations the governance activities will closely resemble each other. Many issues will span both IT and security governance bodies, and a number of individuals will participate actively in both areas. Some organizations may integrate IT and information security governance into a single set of participants, activities, and business records. The most important thing is that organizations figure out how to establish governance programs that are effective for achieving desired and documented business outcomes.

The purpose of security governance is to align the organization’s security program with the needs of the business. The term information security governance refers to a collection of top-down activities intended to control the security organization (and security-related activities in every part of the organization) from a strategic perspective to ensure that information security supports the business. These are some of the artifacts and activities that flow out of healthy security governance:

• Objectives These are desired capabilities or end states, ideally expressed in achievable, measurable terms.

• Strategy This is a plan to achieve one or more objectives.

• Policy At its minimum, security policy should directly reflect the mission, objectives, and goals of the overall organization.

• Priorities The priorities in the security program should flow directly from the organization’s mission, objectives, and goals. Whatever is most important to the organization as a whole should be important to information security as well.

• Standards The technologies, protocols, and practices used by IT should be a reflection of the organization’s needs. On their own, standards help to drive a consistent approach to solving business challenges; the choice of standards should facilitate solutions that meet the organization’s needs in a costeffective and secure manner.

• Processes These are formalized descriptions of repeated business activities that include instructions to applicable personnel. Processes include one or more procedures, as well as definitions of business records and other facts that help workers understand how things are supposed to be done.

• Controls These are formal descriptions of critical activities to ensure desired outcomes.

• Program and project management The organization’s IT and security programs and projects should be organized and performed in a consistent manner that reflects business priorities and supports the business.

• Metrics/reporting This includes the formal measurement of processes and controls so that management understands and can measure them.

To the greatest possible extent, security governance in an organization should be practiced in the same way that the organization performs IT governance and corporate governance. Security governance should mimic corporate and/or IT governance processes, or security governance may be integrated into corporate or IT governance processes.

While security governance contains the elements just described, strategic planning is also a key component of governance. Strategy development is discussed in the next section.

Reason for Security Governance

Organizations in most industry sectors and at all levels of government are increasingly dependent on their information systems. This has progressed to the point where organizations—including those whose products or services are not information related—are completely dependent on the integrity and availability of their information systems to continue business operations. As an information security professional, it is imperative that you understand the priority of the business with regard to confidentiality, integrity, and availability (CIA). All three of these should be considered when building out the security governance structure, but the type of information used by the business will drive the priority that is given to confidentiality, integrity, and availability. Information security governance, then, is needed to ensure that security-related incidents do not threaten critical systems and their support of the ongoing viability of the organization.

Among information security professionals, it is a known fact that without adequate safeguards, information technology assets that are Internet accessible would be compromised in mere minutes of being placed online. Further, many if not all information technology assets thought to be behind the protection of firewalls and other control points may also be easily accessed and compromised. The tools, processes, and controls needed to protect these assets are as complex as the information systems they are designed to protect. Without effective top-down management of the security controls and processes protecting IT assets, management will not be informed or in control of these protective measures. The consequences of failure can impair, cripple, and/or embarrass the organization’s core operations.

Security Governance Activities and Results

Within an effective security governance program, an organization’s senior management team will see to it that information systems necessary to support business operations will be adequately protected. These are some of the activities required to protect the organization:

• Risk management Management will ensure that risk assessments will be performed to identify risks in information systems and supported processes. Follow-up actions will be carried out that will reduce the risk of system failure and compromise.

• Process improvement Management will ensure that key changes will be made to business processes that will result in security improvements.

• Event identification Management will be sure to put technologies and processes in place to ensure that security events and incidents will be identified as quickly as possible.

• Incident response Management will put incident response procedures into place that will help to avoid incidents, reduce the impact and probability of incidents, and improve response to incidents so that their impact on the organization is minimized.

• Improved compliance Management will be sure to identify all applicable laws, regulations, and standards and carry out activities to confirm that the organization is able to attain and maintain compliance.

• Business continuity and disaster recovery planning Management will define objectives and allocate resources for the development of business continuity and disaster recovery plans.

• Metrics Management will establish processes to measure key security events such as incidents, policy changes and violations, audits, and training.

• Resource management The allocation of manpower, budget, and other resources to meet security objectives is monitored by management.

• Improved IT governance An effective security governance program will result in better strategic decisions in the IT organization that keep risks at an acceptably low level.

These and other governance activities are carried out through scripted interactions among key business and IT executives at regular intervals. Meetings will include a discussion of the impact of regulatory changes, alignment with business objectives, effectiveness of measurements, recent incidents, recent audits, and risk assessments. Other discussions may include such things as changes to the business, recent business results, and any anticipated business events such as mergers or acquisitions.

These are two key results of an effective security governance program:

• Increased trust Customers, suppliers, and partners trust the organization to a greater degree when they see that security is managed effectively.

• Improved reputation The business community, including customers, investors, and regulators, will hold the organization in higher regard.

Business Alignment

An organization’s information security program needs to fit into the rest of the organization. This means that the program needs to understand and align with the organization’s highest-level guiding principles including the following:

• Mission Why does the organization exist? Who does it serve, and through what products and services?

• Goals and objectives What achievements does the organization want to accomplish, and when does it want to accomplish them?

• Strategy What are the activities that need to take place so that the organization’s goals and objectives can be fulfilled?

To be business aligned, people in the security program should be aware of several characteristics about the organization, including the following:

• Culture Culture includes how personnel in the organization work, think, and relate to each other.

• Asset value This includes information the organization uses to operate. This often consists of intellectual property such as designs, source code, production costs, and pricing, as well as sensitive information related to not only its personnel but its customers, its information-processing infrastructure, and its service functions.

• Risk tolerance Risk tolerance for the organization’s information security program needs to align with the organization’s overall tolerance for risk.

• Legal obligations What external laws and regulations govern what the organization does and how it operates? These laws and regulations include the Gramm-Leach-Bliley Act (GLBA), Payment Card Industry Data Security Standard (PCI-DSS), European General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and the North American Electric Reliability Corporation (NERC) standard. Also, contractual obligations with other parties often shape the organization’s behaviors and practices.

• Market conditions How competitive is the marketplace in which the organization operates? What strengths and weaknesses does the organization have in comparison with its competitors? How does the organization want its security differentiated from its competitors?

Goals and Objectives

An organization’s goals and objectives specify the activities that are to take place in support of the organization’s overall strategy. Goals and objectives are typically statements in the form of imperatives that describe the development or improvement of business capabilities. For instance, goals and objectives may be related to increases in capacity, improvements of quality, or the development of entirely new capabilities. Goals and objectives further the organization’s mission, helping it to continue to attract new customers or constituents, increase market share, and increase revenue and/or profitability.

Risk Appetite

Each organization has a particular appetite for risk, although few have documented that appetite. ISACA defines risk appetite as the level of risk that an organization is willing to accept while in pursuit of its mission, strategy, and objectives, and before action is needed to treat the risk.

Risk capacity is related to risk appetite. ISACA defines risk capacity as the objective amount of loss that an organization can tolerate without its continued existence being called into question.

Generally, only highly risk-averse organizations such as banks, insurance companies, and public utilities will document and define risk appetite in concrete terms. Other organizations are more tolerant of risk and make individual risk decisions based on gut feeling. However, because of increased influence and mandates by customers, many organizations are finding it necessary to document and articulate the risk posture and appetite of the organization. This is an emerging trend in the marketplace but is still fairly new to many organizations.

Risk-averse organizations generally have a formal system of accountability and traceability of risk decisions back to department heads and business executives. This activity is often seen within risk management and risk treatment processes, where individual risk treatment decisions are made and one or more business executives are made accountable for their risk treatment decisions.

In a properly functioning risk management program, the chief information security officer (CISO) is rarely the person who makes a risk treatment decision and is accountable for that decision. Instead, the CISO is a facilitator for risk discussions that eventually lead to a risk treatment decision. The only time the CISO would be the accountable party would be when risk treatment decisions directly affect the risk management program itself, such as the selection of a governance, risk, and compliance (GRC) tool for managing and reporting on risk.

Organizations rarely have a single risk tolerance level across the entire business; instead, different business functions and different aspects of security will have varying levels of risk. For example, a mobile gaming software company may have a moderate tolerance for risk with regard to the introduction of new products, a low tolerance for workplace safety risks, and no tolerance for risk for legal and compliance matters. Mature organizations will develop and publish a statement of risk tolerance or appetite that expresses risk tolerance levels throughout the business.

Roles and Responsibilities

Information security governance is most effective when every person in the organization knows what is expected of them. Better organizations develop formal roles and responsibilities so that personnel will have a clearer idea of their part in all matters related to the protection of systems, information, and even themselves.

In the context of organizational structure and behavior, a role is a description of expected activities that employees are obliged to perform as part of their employment. Roles are typically associated with a job title or position title, which is a label assigned to each person that designates their place in the organization. Organizations strive to adhere to more or less standard position titles so that other people in the organization, upon knowing someone’s position title, will have at least a general idea of a person’s role in the organization.

Typical roles include the following:

• IT auditor

• Systems engineer

• Accounts receivable manager

• Individual contributor

Often a position title also includes a person’s rank, which denotes an individual person’s seniority, placement within a command-and-control hierarchy, span of control, or any combination of these. Typical ranks include the following in order of increasing seniority:

• Supervisor

• Manager

• Senior manager

• Director

• Senior director

• Executive director

• Vice president

• Senior vice president

• Executive vice president

• President

• Chief executive officer

• Member, board of directors

• Chairman, board of directors

This should not be considered a complete listing of ranks. Larger organizations also include the modifiers assistant (as in assistant director), general (general manager), and first (first vice president).

A responsibility is a statement of activities that a person is expected to perform. Like roles, responsibilities are typically documented in position descriptions and job descriptions. Typical responsibilities include the following:

• Perform monthly corporate expense reconciliation

• Troubleshoot network faults and develop solutions

• Audit user account terminations and develop exception reports

In addition to specific responsibilities associated with individual position titles, organizations typically also include general responsibilities in all position titles. Examples include the following:

• Understand and conform to information security policy, harassment policy, and other policies

• Understand and conform to code of ethics and behavior

In the context of information security, an organization assigns roles and responsibilities to individuals and groups so that the organization’s security strategy and objectives can be met.

Board of Directors

The board of directors in an organization is a body of people who oversee activities in an organization. Depending on the type of organization, board members may be elected by shareholders or constituents, or they may be appointed. This role can be either paid or voluntary in nature.

Activities performed by the board of directors, as well as directors’ authority, are usually defined by a constitution, bylaws, or external regulation. The board of directors is typically accountable to the owners of the organization or, in the case of a government body, to the electorate.

In many cases, board members have fiduciary duty. This means they are accountable to shareholders or constituents to act in the best interests of the organization with no appearance of impropriety, conflict of interest, or ill-gotten profit as a result of their actions.

In nongovernment organizations, the board of directors is responsible for appointing a chief executive officer (CEO) and possibly other executives. The CEO, then, is accountable to the board of directors and carries out their directives. Board members may also be selected for any of the following reasons:

• Investor representation One or more board members may be appointed by significant investors to give them control over the strategy and direction of the organization.

• Business experience Board members bring outside business management experience, which helps them develop successful business strategies for the organization.

• Access to resources Board members bring business connections, including additional investors, business partners, suppliers, or customers.

Often, one or more board members will have business finance experience in order to bring financial management oversight to the organization. In the case of U.S. public companies, the U.S. Sarbanes-Oxley Act requires board members to form an audit committee; one or more audit committee members are required to have financial management experience. External financial audits and internal audit activities are often accountable directly to the audit committee in order to perform direct oversight of the organization’s financial management activities. As the issue of information security becomes more prevalent in discussions at the executive level, some organizations have added a board member who is technically savvy or have formed an additional committee, often referred to as the Technology Risk Committee.

Boards of directors are generally expected to require that the CEO and other executives implement a corporate governance function to ensure that executive management has an appropriate level of visibility and control over the operations of the organization. Executives are accountable to the board of directors to demonstrate that they are effectively carrying out the board’s strategies.

Many, if not most, organizations are highly dependent upon information technology for their daily operations. As a result, information security is an important topic to boards of directors. Today’s standard of due care for corporate boards requires that they include information security considerations in the strategies they develop and the oversight they exert on the organization. In its publication Cyber-Risk Oversight, the National Association of Corporate Directors has developed five principles about the importance of information security:

• Principle 1: Directors need to understand and approach cybersecurity as an enterprise-wide risk management issue, not just an IT issue.

• Principle 2: Directors should understand the legal implications of cyber risks as they relate to their company’s specific circumstances.

• Principle 3: Boards should have adequate access to cybersecurity expertise, and discussions about cyber-risk management should be given regular and adequate time on board meeting agendas.

• Principle 4: Boards should set the expectation that management will establish an enterprise-wide cyber-risk management framework with adequate staffing and budget.

• Principle 5: Board management discussions about cyber risk should include identification of which risks to avoid, which to accept, and which to mitigate or transfer through insurance, as well as specific plans associated with each approach.

Executive Management

Executive management is responsible for carrying out directives issued by the board of directors. In the context of information security management, this includes ensuring that there are sufficient resources for the organization to implement a security program and to develop and maintain security controls to protect critical assets.

Executive management must ensure that priorities are balanced. In the case of IT and information security, these functions are usually tightly coupled but sometimes in conflict. IT’s primary mission is the development and operation of business-enabling capabilities through the use of information systems, while information security’s mission includes security and compliance. Executive management must ensure that these two sometimes-conflicting missions are successful.

Typical IT and security-related executive position titles include the following:

• Chief information officer (CIO) This is the title of the topmost leader in a larger IT organization.

• Chief technical officer (CTO) This position is usually responsible for an organization’s overall technology strategy. Depending upon the purpose of the organization, this position may be separate from IT.

• Chief information security officer (CISO) This position is responsible for all aspects of data-related security. This usually includes incident management, disaster recovery, vulnerability management, and compliance. This role is usually separate from IT.

To ensure the success of the organization’s information security program, executive management should be involved in three key areas:

• Ratify corporate security policy Security policies that are developed by the information security function should be visibly ratified or endorsed by executive management. This may take different forms, such as formal minuted ratification in a governance meeting, a statement for the need for compliance along with a signature within the body of the security policy document, a separate memorandum to all personnel, or other visible communication to the organization’s rank and file that stresses the importance of, and need for compliance to, the organization’s information security policy.

• Leadership by example With regard to information security policy, executive management should lead by example and not exhibit behavior suggesting they are “above” security policy—or other policies. Executives should not be seen to enjoy special privileges of the nature that suggest that one or more security policies do not apply to them. Instead, their behavior should visibly support security policies that all personnel are expected to comply with.

• Ultimate responsibility Executives are ultimately responsible for all actions carried out by the personnel who report to them. Executives are also ultimately responsible for all outcomes related to organizations to which operations have been outsourced.

Security Steering Committee

Many organizations form a security steering committee, consisting of stakeholders from many (if not all) of the organization’s business units, departments, functions, and principal locations. A steering committee may have a variety of responsibilities, including the following:

• Risk treatment deliberation and recommendation The security steering committee may discuss relevant risks, discuss potential avenues of risk treatment, and develop recommendations for said risk treatment for ratification by executive management.

• Discussion and coordination of IT and security projects The security steering members may discuss various IT and security projects to resolve any resource or scheduling conflicts. They might also discuss potential conflicts between various projects and initiatives and work out solutions.

• Review of recent risk assessments The security steering committee may discuss recent risk assessments in order to develop a common understanding of their results, as well as discuss remediation of findings.

• Discussion of new laws, regulations, and requirements The committee may discuss new laws, regulations, and requirements that may impose changes in the organization’s operations. Committee members can develop high-level strategies that their respective business units or departments can further build out.

• Review of recent security incidents Steering committee members can discuss recent security incidents and their root causes. Often this can result in changes in processes, procedures, or technology changes to reduce the risk and impact of future incidents.

Reading between the lines, the main mission of a security steering committee is to identify and resolve conflicts and to maximize the effectiveness of the security program, as balanced among other business initiatives and priorities.

Business Process and Business Asset Owners

Business process and asset owners are typically nontechnical personnel in management positions in an organization. While they may not be technology experts, in many organizations their business processes are enhanced by information technology in the form of business applications and other capabilities.

Remembering that IT and information security serve the organization and not the other way around, business process and business asset owners are accountable for making business decisions that sometimes impact the use of information technology, the organization’s security posture, or both. A simple example is a decision on whether an individual employee should have access to specific information. While IT or security may have direct control over which personnel have access to what assets, the best decision to make is a business decision by the manager responsible for the process or business asset.

The responsibilities of business process and business asset owners include the following:

• Access grants Asset owners decide whether individuals or groups should be given access to the asset, as well as the level and type of access. Example access types include combinations of read only, read-write, create, and delete.

• Access revocation Asset owners should also decide when individuals or groups no longer require access to an asset, signaling the need to revoke that access.

• Access reviews Asset owners should periodically review access lists to see whether each person and group should continue to have that access. Access reviews may also include access activity reviews to determine whether people who have not accessed assets still require access to them.

• Configuration Asset owners determine the configuration needed for assets and applications, ensuring their proper function and support of applications and business processes.

• Function definition In the case of business applications and services, asset owners determine which functions will be available, how they will work, and how they will support business processes. Typically, this definition is constrained by functional limitations within an application, service, or product.

• Process definition Process owners determine the sequence, steps, roles, and actions carried out in their business processes.

• Physical location Asset owners determine the physical location of their assets. Factors influencing choices of location include physical security, proximity to other assets, proximity to relevant personnel, and data protection and privacy laws.

Often, business and asset owners are nontechnical personnel, so it may be necessary to translate business needs into technical specifications.

Custodial Responsibilities

In many organizations, asset owners are not involved in the day-to-day activities related to the management of their assets, particularly when those assets are information systems and the data stored within them. Instead, somebody in the IT organization (or several people in IT) acts as a proxy for asset owners and makes access grants and other decisions on their behalf. While this is a common practice, it is often carried too far, resulting in the asset owner being virtually uninvolved and uninformed. Instead, asset owners should be aware of, and periodically review, activities carried out by people, groups, and departments making decisions on their behalf.

The most typical arrangement is that people in IT make access decisions on behalf of asset owners. Except in cases where there is a close partnership between these IT personnel and asset owners, these IT personnel often do not adequately understand the business nature of assets or the implications when certain people are given access to them. Most often, far too many personnel have access to assets, usually with higher privileges than necessary.

Chief Information Security Officer

The CISO is the highest-ranking security person in an organization. A CISO will develop business-aligned security strategies that support present and future business initiatives and be responsible for the development and operation of the organization’s information risk program, the development and implementation of security policies, security incident response, and perhaps some operational security functions.

In some organizations, the CISO reports to the chief operating officer (COO) or the CEO, but in some organizations the CISO may report to the CIO, chief legal counsel, or other person in the organization.

Other similar titles with similar responsibilities include the following:

• Chief security officer (CSO) This position generally has the responsibilities of a CISO plus responsibilities for non-information assets such as business equipment and work centers. A CSO often is responsible for workplace safety.

• Chief information risk officer (CIRO) Generally this represents a change of approach to the CISO position, from being protection-based to being risk-based.

• Chief risk officer (CRO) This position is responsible for all aspects of risk including information risk, business risk, compliance risk, and market risk. This role is separate from IT.

Many organizations do not have a CISO but instead have a director or manager of information security who reports further down in the organization chart. There are several possible reasons for organizations not having a CISO, but generally it can be said that the organization does not consider information security as a strategic function. This will hamper the visibility and importance of information security and often results in information security being a tactical function concerned with basic defenses such as firewalls, antivirus, and other tools. In such situations, responsibility for strategy-level information security implicitly lies with some other executive such as the CIO. This type of situation often results in the absence of a security program and the organization’s general lack of awareness of relevant risks, threats, and vulnerabilities.

The one arena where a CISO may not be required is in small to medium-sized organizations where a full-time strategic leader may not be cost effective. In these situations, it is advisable to contract with a virtual CISO (vCISO) to assist with strategy and planning. The benefit of taking this type of approach for organizations that may not require or cannot afford a full-time person is that it allows the organization to benefit from the knowledge of seasoned security professional to assist in driving the information security program forward.

Rank Sets Tone and Gives Power

A glance at the title of the highest-ranking information security position in an organization reveals much about executive management’s opinion of information security in larger organizations. Executive attitudes about security are reflected in the security manager’s title and may resemble the following:

• Security manager Information security is tactical only and often viewed as consisting only of antivirus software and firewalls. The security manager has no visibility into the development of business objectives. Executives consider security as unimportant and based on technology only.

• Security director Information security is important and has moderate decision-making capability but little influence on the business. A director-level person in a larger organization may have little visibility to overall business strategies and little or no access to executive management or the board of directors.

• Vice president Information security is strategic but does not influence business strategy and objectives. The vice president will have some access to executive management and possibly the board of directors.

• CISO/CIRO/CSO/vCISO Information security is strategic, and business objectives are developed with full consideration for risk. The C-level security person has free access to executive management and the board of directors.

Chief Privacy Officer

Some organizations, typically those that manage large amounts of sensitive data on customers, will employ a chief privacy officer (CPO). Some organizations have a CPO because applicable regulations such as HIPAA, the Fair Credit Reporting Act (FCRA), and GLBA require it, while others have a CPO because they store massive amounts of personally identifiable information (PII).

The roles of a CPO typically include the safeguarding of PII, as well as ensuring that the organization does not misuse PII at its disposal. Because many organizations with a CPO also have a CISO, the CPO’s duties mainly involve oversight into the organization’s properly handling and use of PII.

The CPO is sometimes seen as a customer advocate, and often this is the role of the CPO, particularly when regulations require a privacy officer.

Software Development

Positions in software development are involved in the design, development, and testing of software applications.

• Systems architect This position is usually responsible for the overall information systems architecture in the organization. This may or may not include overall data architecture and interfaces to external organizations.

• Systems analyst A systems analyst is involved with the design of applications, including changes in an application’s original design. This position may develop technical requirements, program design, and software test plans. In cases where organizations license applications developed by other companies, systems analysts design interfaces to other applications.

• Software engineer/developer This position develops application software. Depending upon the level of experience, people in this position may also design programs or applications. In organizations that utilize purchased application software, developers often create custom interfaces, application customizations, and custom reports.

• Software tester This position tests changes in programs made by software engineers/developers.

While the trend to outsourcing applications has resulted in organizations infrequently developing their own applications from scratch, software development roles persist in organizations. Developers are needed for the creation of customized modules within software platforms, as well as integration tools to connect applications to each other. Still, most organizations have a smaller number of developers than they did a decade or two ago.

Data Management

Positions related to data management are responsible for developing and implementing database designs and for maintaining databases. These positions are concerned with data within applications, as well as data flows between applications.

• Data manager This position is responsible for data architecture and data management in larger organizations.

• Database architect This position develops logical and physical designs of data models for applications. With sufficient experience, this person may also design an organization’s overall data architecture.

• Big data architect This position develops data models and data analytics for large, complex data sets.

• Database administrator (DBA) This position builds and maintains databases designed by the database architect and those databases that are included as part of purchased applications. The DBA monitors databases, tunes them for performance and efficiency, and troubleshoots problems.

• Database analyst This position performs tasks that are junior to the database administrator, carrying out routine data maintenance and monitoring tasks.

• Data scientist This position applies scientific methods, builds processes, and implements systems to extract knowledge or insights from data.

EXAM TIP   The roles of data manager, big data architect, database architect, database administrator, database analyst, and data scientist are distinct from data owners. The former are IT department roles for managing data models and data technology, whereas the latter role governs the business use of, and access to, data in information systems.

Network Management

Positions in network management are responsible for designing, building, monitoring, and maintaining voice and data communications networks, including connections to outside business partners and the Internet.

• Network architect This position designs data and voice networks and designs changes and upgrades to networks as needed to meet new organization objectives.

• Network engineer This position implements, configures, and maintains network devices such as routers, switches, firewalls, and gateways.

• Network administrator This position performs routine tasks in the network such as making configuration changes and monitoring event logs.

• Telecom engineer Positions in this role work with telecommunications technologies such as telecomm services, data circuits, phone systems, conferencing systems, and voice-mail systems.

Systems Management

Positions in systems management are responsible for architecture, design, building, and maintenance of servers and operating systems. This may include desktop operating systems as well. Personnel in these positions also design and manage virtualized environments as well as microsegmentation.

• Systems architect This position is responsible for the overall architecture of systems (usually servers), in terms of both the internal architecture of a system and the relationship between systems. This position is usually also responsible for the design of services such as authentication, e-mail, and time synchronization.

• Systems engineer This position is responsible for designing, building, and maintaining servers and server operating systems.

• Storage engineer This position is responsible for designing, building, and maintaining storage subsystems.

• Systems administrator This position is responsible for performing maintenance and configuration operations on systems.

Operations

Positions in operations are responsible for day-to-day operational tasks that may include networks, servers, databases, and applications.

• Operations manager This position is responsible for overall operations that are carried out by others. Responsibilities will include establishing operations and shift schedules.

• Operations analyst This position may be responsible for developing operational procedures; examining the health of networks, systems, and databases; setting and monitoring the operations schedule; and maintaining operations records.

• Controls analyst This position is responsible for monitoring batch jobs, data entry work, and other tasks to make sure they are operating correctly.

• Systems operator This position is responsible for monitoring systems and networks, performing backup tasks, running batch jobs, printing reports, and other operational tasks.

• Data entry This position is responsible for keying batches of data from hard copy or other sources.

• Media manager This position is responsible for maintaining and tracking the use and whereabouts of backup tapes and other media.

Security Operations

Positions in security operations are responsible for designing, building, and monitoring security systems and security controls to ensure the confidentiality, integrity, and availability of information systems.

• Security architect This position is responsible for the design of security controls and systems such as authentication, audit logging, intrusion detection systems, intrusion prevention systems, and firewalls.

• Security engineer This position is responsible for designing, building, and maintaining security services and systems that are designed by the security architect.

• Security analyst This position is responsible for examining logs from firewalls and intrusion detection systems, as well as audit logs from systems and applications. This position may also be responsible for issuing security advisories to others in IT.

• Access administrator This position is responsible for accepting approved requests for user access management changes and performing the necessary changes at the network, system, database, or application level. Often, this position is carried out by personnel in network and systems management functions; only in larger organizations is user account management performed in security or even in a separate user access department.

Security Audit

Positions in security audit are responsible for examining process design and for verifying the effectiveness of security controls.

• Security audit manager This position is responsible for audit operations, as well as scheduling and managing audits.

• Security auditor This position is responsible for performing internal audits of IT controls to ensure that they are being operated properly.

CAUTION Security audit positions need to be carefully placed in the organization so that people in this role can be objective and independent from the departments, processes, and systems they audit.

Service Desk

Positions at the service desk are responsible for providing frontline support services to IT and IT’s customers.

• Service desk manager This position serves as a liaison between end users and the IT service desk department.

• Service desk analyst This position is responsible for providing frontline user support services to personnel in the organization. This is sometimes known as a help-desk analyst.

• Technical support analyst This position is responsible for providing technical support services to other IT personnel and perhaps also to IT customers.

Quality Assurance

Positions in quality assurance are responsible for evaluating IT systems and processes to confirm their accuracy and effectiveness.

• QA manager This position is responsible for facilitating quality improvement activities throughout the IT organization.

• QC manager This position is responsible for testing IT systems and applications to confirm whether they are free of defects.

Other Roles

Other roles in IT organizations include the following:

• Vendor manager This position is responsible for maintaining business relationships with external vendors, measuring their performance, and handling business issues.

• Project manager This position is responsible for creating project plans and managing IT projects.

General Staff

The rank and file in an organization may or may not have explicit information security responsibilities, determined in part by executive management’s understanding of the broad capabilities of information systems and the personnel who use them and determined also in executives’ understanding of the human role in information security.

Typically, general staff security-related responsibilities include the following:

• Understanding and compliance to organization security policy

• Acceptable use of organization assets, including information systems and information

• Proper judgment, including proper responses to people who request information or request that staff members perform specific functions (the primary impetus for this is the phenomenon of social engineering and its use as an attack vector)

• Reporting of security-related matters and incidents to management

Better organizations have standard language in job descriptions that specify general responsibilities for the protection of assets.

Monitoring Responsibilities

The practice of monitoring responsibilities helps an organization confirm that the correct jobs are being carried out in the right way. There is no single approach, but several activities provide information to management, including the following:

• Controls and internal audit Developing one or more controls around specific responsibilities gives management greater control over key activities. Internal audit of controls provides objective analysis on control effectiveness.

• Metrics and reporting Developing metrics for repeated activities helps management better understand work output.

• Work measurement This is a more structured activity used to carefully measure repeated tasks to better understand the volume of work performed.

• Performance evaluation This is a traditional qualitative method used to evaluate employee performance.

• 360 feedback Soliciting structured feedback from peers, subordinates, and management helps subjects and management better understand characteristics related to specific responsibilities.

• Position benchmarking This technique is used by organizations that want to compare job titles and people holding them with those in other organizations. There is no direct monitoring of responsibilities, but instead this helps an organization determine whether they have the right positions in place and that they are staffed by competent and qualified personnel. This may be useful for organizations that are troubleshooting employee performance.

Information Security Governance Metrics

Metrics are the means through which management can measure key processes and know whether their strategies are working. Metrics are used in many operational processes, but in this section, metrics as related to security governance are the emphasis. In other words, there is a distinction between tactical IT security metrics and those that reveal the state of the overall security program. The two, however, are often related, as discussed in the sidebar “Return on Security Investment.”

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

• Firewall metrics Number and types of rules triggered

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

• Anti-malware metrics Number and types of malware blocked, and targeted systems

• Other security system metrics Measurements from data loss prevention (DLP) systems, web content filtering systems, cloud access security broker (CASB) systems, and so on

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

• How much security is enough?

• How should security resources be invested and applied?

• What is the potential impact of a threat event?

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

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

• Key risk indicators (KRIs) These are metrics associated with the measurement of risk.

• Key goal indicators (KGIs) These metrics portray the attainment of strategic goals.

• Key performance indicators (KPIs) These metrics are used to show efficiency or effectiveness of security-related activities.

Effective Metrics

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

• Specific

• Measurable

• Attainable

• Relevant

• Timely

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

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

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

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

You can find more information about the development of metrics in NIST Special Publication 800-55 Revision 1, Performance Measurement Guide for Information Security, available at www.nist.gov.

Strategic Alignment

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

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

Be the best marketplace for job seekers and recruiters

Here are its most recent strategic objectives:

Integrate with leading business social network LinkedIn

Develop an API to facilitate long-term transformation into a leading career and recruiting platform

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

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

Security and metrics would then include these:

Percentage of software developers not yet trained

Number of critical vulnerabilities identified

Time to remediate critical and high vulnerabilities

Based on these criteria, these metrics are all measurable, they align to the security strategy, and they are all leading indicators. The higher these metrics, the more likely a breach would occur that would damage CareerSearchCo’s reputation and ability to earn new business contracts from large corporations.

Risk Management

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

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

• Reduction in the number of security incidents

• Reduction in the impact of security incidents

• Reduction in the time to remediate security incidents

• Reduction in the time to remediate vulnerabilities

• Reduction in the number of new unmitigated risks

Regarding the previous mention of the reduction of security incidents, a security program improving its maturity from low levels should first expect to see the number of incidents increase. This would be not because of lapses in security controls but because of the development of—and improvements in—mechanisms used to detect and report security incidents.

Similarly, as a security program is improved and matures over time, the number of new risks will, at first, increase and then later decrease.

Performance Measurement

Metrics on the performance of information security provide measures of timeliness and effectiveness. Generally speaking, performance measurement metrics provide a view of tactical security processes and activities. As discussed earlier in this section, performance measurements are often the operational metrics that need to be transformed into executive-level metrics for those audiences.

Performance measurement metrics can include any of the following:

• Time to detect security incidents

• Time to remediate security incidents

• Time to provision user accounts

• Time to deprovision user accounts

• Time to discover vulnerabilities

• Time to remediate vulnerabilities

Nearly every operational activity that is security-related and measurable is a candidate for performance metrics.

Convergence

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

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

• Gaps in asset coverage

• Overlaps in asset coverage

• Consolidation of licenses for security tools

• Gaps or overlaps in skills, responsibilities, or coverage

Value Delivery

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

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

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

• Program costs per asset population or asset value

• Program costs per employee population

• Program costs per revenue

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

Resource Management

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

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

• Security involvement in every procurement and acquisition project

• Percentage of assets protected by security controls

The Security Balanced Scorecard

The balanced scorecard (BSC) is a management tool that is used to measure the performance and effectiveness of an organization. The balanced scorecard is used to determine how well an organization can fulfill its mission and strategic objectives and how well it is aligned with overall organizational objectives.

In the balanced scorecard, management defines key measurements in each of four perspectives:

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

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

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

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

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

The balanced scorecard should be used to measure overall organizational effectiveness and progress. A similar scorecard, the security balanced scorecard, can be used to specifically measure security organization performance and results.

Like the balanced scorecard, the security balanced scorecard (security-BSC) has the same four perspectives, mapped to key activities as depicted in Table 2-1.

Table 2-1 Security Balanced Scorecard Domains

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

Business Model for Information Security

Developed by ISACA in 2009, the Business Model for Information Security (BMIS) is a guide for business-aligned, risk-based security governance. The use of BMIS helps security leadership ensure that the organization’s security program continues to address emerging threats, developing regulations, and changing business needs.

BMIS is a three-dimensional, three-sided pyramid, depicted in Figure 2-2. The three foundation elements of the pyramid are people, process, and technology, while the apex element of the pyramid is the organization.

Figure 2-2 The BMIS model (Adapted from The Business Model for Information Security, ISACA)

The BMIS model includes the three traditional elements found in IT, which are people, process, and technology, and adds a fourth element, organization. The elements are connected by dynamic interconnections (DIs), which are culture, governing, architecture, emergence, enabling and support, and human factors. The elements and dynamic interconnections are described in more detail in the following sections.

BMIS is described fully in the document The Business Model for Information Security from ISACA, available at https://www.isaca.org/bmis.

The BMIS is derived from the Systemic Security Management Framework, developed by the University of Southern California (USC) Marshall School of Business in 2006.

BMIS Elements and Dynamic Interconnections

The elements and dynamic interconnections are the major pieces of the BMIS model and are described in detail in this section.

Organization The organization element in the BMIS model makes the model unique. Most other models focus on people, process, and technology—or other aspects of an organization without considering the organization itself.

BMIS defines the organization as “a network of people interacting, using processes to channel this interaction.” This is not unlike the executive management perspective that views the organization as a set of elements that act together to accomplish strategic objectives. The organization includes not only the permanent staff but also temporary workers, contractors, and consultants, as well as third-party organizations that also play roles in helping the organization achieve its objectives.

Organizations are formally structured through organization charts, command-and-control hierarchy, policies, processes, and procedures.

But organizations also have their informal, undocumented organization, which can be viewed like additional synapses that connect people or groups across the organization in ways not intended, nonetheless helping the organization achieve its objectives. This is often seen in distributed organizations, where expediency and pragmatism often rule over policy and process, particularly in locations farther away from corporate headquarters.

People The people element in the BMIS model represents all of the people in an organization, whether full-time employees or temporary workers, contractors, or consultants. Further, as an organization outsources its operations to other organizations, the people in those organizations are also part of the people in the people element in BMIS.

Like the other elements in the BMIS model, people cannot be studied by themselves but instead must be considered alongside the other elements of process, technology, and organization.

Process   The process element in the BMIS model represents the formal structure of all defined activities in the organization, which together help the organization achieve its strategic objectives. Process defines practices and procedures that describe how activities are to be carried out.

ISACA’s Risk IT framework defines an effective process as a reliable and repetitive collection of activities and controls to perform a certain task. Processes take input from one or more sources (including other processes), manipulate the input, utilize resources according to the policies, and produce output (including output to other processes). Processes should have clear business reasons for existing, accountable owners, clear roles and responsibilities around the execution of each key activity, and the means to undertake and measure performance.

Individual processes have the attribute of maturity, which qualitatively describes how well the process is designed, as well as how it is measured and improved over time.

Technology   The technology element in the BMIS model represents all of the systems, applications, and tools used by practitioners in an organization. Technology is a powerful enabler of an organization’s processes and of its strategic objectives, although unless tamed with process and by people, technology by itself can accomplish little for an organization.

As the BMIS model illustrates, technology in an organization does not run by itself. Instead, people and processes are critical to any successful use of technology. Technology can be viewed as a process enabler and as a force multiplier, helping the organization accomplish more work in less time, for less cost, and with greater accuracy.

Culture   The culture DI connects the organization and people elements. Culture as part of a governance model makes BMIS unique, as most other models do not consider culture with strategic importance. BMIS defines culture as “a pattern of behaviors, beliefs, assumptions, attitudes, and ways of doing things.”

Culture is the catalyst that drives behavior, with as much or more influence than formal directives such as policies and standards. Culture determines the degree to which personnel strive to conform to security policy and contribute to the protection of critical assets or whether they behave contrary to policy and put critical assets in jeopardy.

An organization’s culture is considered one of the most critical factors in the success or failure of an information security program. By its nature, culture cannot be legislated or controlled directly, but instead it reflects the attitudes, habits, and customs adopted by the people in the organization.

The civil culture of the community in which the organization resides plays a large role in shaping the organization’s culture. For this reason, establishing a single culture in an organization with many regional or global locations is not feasible.

Of utmost importance to the security strategist is the development of a productive security culture. Like other aspects of organizational culture, a desired security culture cannot simply be legislated through policy but must be carefully curated and grown. Steps to create a favorable security culture include the following:

• Involve personnel in discussions about the protection of critical assets.

• Executive leadership must lead by example and follow all policies.

• Include security responsibilities in all job descriptions.

• Include security factors in employees’ compensation—for example, merit increases and bonuses.

• Link the protection of critical assets to the long-term success of the organization.

• Integrate messages related to the protection of assets, and other aspects of the information security program, into existing communications such as newsletters.

• Incorporate “secure by design” into key business processes so that security is part of the organization’s routine activities.

• Reward and recognize desired behavior; similarly, admonish undesired behavior privately.

Changing an organization’s security culture cannot be accomplished overnight, and it cannot be forced. Instead, every individual needs to understand consistent messaging that reiterates the importance of sound security practices.

For individuals and teams who don’t “get it,” the organization must be willing to take remedial action, not unlike that which would be undertaken when other undesired behavior is witnessed. Individuals who are teachable need to be coached on desired behavior. Those who prove to be unteachable may be dealt with in other ways.

Governing   The governing DI connects the organization and process elements. Per the definition from ISACA, “governance is the set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring that objectives are achieved, ascertaining that risks are managed appropriately and verifying that the enterprise’s resources are used responsibly.”

This means that processes are influenced, even controlled, by the organization’s mission, strategic objectives, and other factors. In other words, the organization’s processes must support the organization’s mission and strategic objectives. When they don’t, governance is used to change them until they are.

The tools used in governing include the following:

• Policies

• Standards

• Guidelines

• Process documentation

• Resource allocation

• Compliance

These tools are used by management to exert control over the development and operation of business processes, ensuring desired outcomes.

Communications is vital in the governing DI. Information flows down from management in the form of directives to influence change in business processes.

When the governing DI fails, processes no longer align with organization objectives and take on a life of their own.

Architecture   The architecture DI connects the organization and technology elements. The purpose of the DI between organization and technology signifies the need for the use of technology to be planned, orderly, and purposeful.

The definition of architecture, according to ISO/IEC 42010, “Systems and software engineering — Architecture description,” is fundamental concepts or properties of a system in its environment embodied in its elements, in its relationships, and in the principles of its design and evolution. The practice of architecture ensures the following:

• Alignment Applications and infrastructure will support the organization’s mission and objectives.

• Consistency Similar or even identical practices and solutions will be employed throughout the IT environment.

• Efficiency The IT organization as well as its environment can be built and operated more efficiently, mainly through consistent designs and practices.

• Low cost With a more consistent approach, acquisition and support costs can be reduced, through economy of scale and less waste.

• Resilience Purposeful architectures and designs with greater resilience can be realized.

• Flexibility Architectures must have the desired degree of flexibility to accommodate changing business needs and external factors such as regulations and market conditions.

• Scalability Sound architectures are not rigid in their size but can be made larger or smaller to accommodate various business needs, such as growth in revenue, various size branch offices, and larger data sets.

• Security With the development of security policies, standards, and guidelines, the principle of “secure by design” is more certain in future applications and systems.

The Zachman framework

The Zachman enterprise architecture framework, established in the late 1980s, continues to be the dominant enterprise architecture standard today. Zachman likens IT enterprise architecture to the construction and maintenance of an office building: at a high (abstract, not number of floors) level, the office building performs functions such as containing office space. As you look into increasing levels of detail in the building, you encounter various trades (steel, concrete, drywall, electrical, plumbing, telephone, fire control, elevators, and so on), each of which has its own specifications, standards, regulations, construction and maintenance methods, and so on.

In the Zachman architecture model, IT systems and environments are described at a high, functional level and then, in increasing detail, encompassing systems, databases, applications, networks, and so on. The Zachman framework is illustrated in Table 2-2.

Table 2-2 The Zachman Framework Shows IT Systems in Increasing Levels of Detail

While the Zachman model allows an organization to peer into cross sections of an IT environment that supports business processes, the model does not convey the relationships between IT systems. Data flow diagrams are used instead to depict information flows.

Data flow diagrams (DFDs) are frequently used to illustrate the flow of information between IT applications. Like the Zachman model, a DFD can begin as a high-level diagram, where the labels of information flows are expressed in business terms. Written specifications about each flow can accompany the DFD; these specifications would describe the flow in increasing levels of detail, all the way to field lengths and communication protocol settings.

Similar to Zachman, DFDs permit nontechnical business executives to easily understand the various IT applications and the relationships between them. Figure 2-3 shows a typical DFD.

Figure 2-3 A typical DFD shows the relationship between IT applications.

Emergence   The emergence DI connects the people and process elements. The purpose of the emergence DI is to bring focus to the way people perform their work. Emergence is seen as the arising of new opportunities for organizations, new processes, new practices, and new ways of doing things. Emergence can be a result of people learning how to do things better, faster, more accurately, or with less effort.

Emergence can be seen as a two-edged sword. The creativity and ingenuity of people can lead to better ways of doing things, but on the other hand, this can lead to inconsistent results including errors or lapses in product or service quality.

Organizations that want to reduce work output deviation caused by emergence have a few potential remedies.

• Increase automation Removing some of the human factors from a process through automation can yield more consistent outcomes.

• Enact controls Putting key controls in place can help management focus on factors responsible for outcome deviation. This can lead to process improvements later.

• Increase process maturity Organizations can enact changes in business process to increase the maturity of those processes. Examples include adding key measurements or producing richer log data so that processes can be better understood and improved over time.

Organizations need to understand which activities can benefit from automation and which require human judgment that cannot be programmed into a computer. This sometimes involves human factors because there may be times when people prefer to interact with a person versus a machine, even if the machine is faster or more accurate. Automation does not always equal improvement to all parties concerned.

Enabling and Support   The enabling and support DI connects the process and technology elements. The purpose of the enabling and support DI is the enablement and support of business processes by technology. Put another way, information technology makes business processes faster and more accurate than if they were performed manually.

In an appropriate relationship between business processes and technology, the structure of business processes determines how technology will support them. Unfortunately, many organizations compromise their business processes by having capabilities in poorly selected or poorly designed technology determine how business processes operate. While it is not always feasible for technology to support every whim and nuance in a business process, many organizations take the other extreme by selecting technology that does not align with their business processes or the organization’s mission and objectives and changing their processes to match capabilities provided by technology. This level of compromise is detrimental to the organization.

A part of the disconnect between business processes and technologies that do not fully support them is that technology experts often do not sufficiently understand the business processes they support, and business owners and users do not sufficiently understand the technologies supporting them. To paint with a broad brush, technology people and businesspeople think differently about technology and business and often find it difficult to understand each other enough to make technology’s support of business processes as successful as they could be.

The tool that is used to fill this gap is the requirements document. Often developed at the onset of a major project (and often a minor one), business people endeavor to develop charts listing required and desired functionality for new technologies to improve their chances of selecting and implementing a technology that will support their business processes.

The BMIS model for enabling and support is a life cycle, as opposed to a do-it-once approach, as depicted in Figure 2-4.

Figure 2-4 BMIS enabling and support life cycle (Adapted from The University of Southern California, Marshall School of Business, Institute for Critical Information Infrastructure Protection, USA)

Human Factors   The human factors DI connects the people and technology elements. The purpose of the human factors DI is the interaction between people and information systems. This is an extensively studied and researched topic, sometimes known as human–computer interaction (HCI). The elements of information systems that people interact with are often known as user interfaces (UIs); considerable research is devoted to the improvement of UIs to make software and systems easier to use and more intuitive.

From an information security perspective, information systems need to implement security requirements in ways that do not impede users’ interaction wherever possible. Where users have choices to make while interacting with a system, security features and functions need to be easy to use and intuitive. Further, users should not be able to easily circumvent security controls put in place to protect systems and data. Finally, systems should be designed so that they cannot be abused or that their use permit abuse of other assets.

There are many considerations that need to be included in the design of information systems (both hardware and software), including the following:

• Consistency Operating an information system should resemble other commonly used systems. For instance, keyboard arrangement should be consistent with other products in use.

• Typing and data entry Entering text should be straightforward and simple. The method for entering data should be commensurate with the interface. For instance, a small touchscreen keyboard would be a poor choice for entering large amounts of data (e.g., sentences and paragraphs). Further, pointing methods should be easy to use and intuitive.

• Display and readability Users should be able to easily read text and images.

• Error recovery Users should be able to repeat a step when they have recognized that they have made an error.

• Sound Sounds as part of interaction should be adjustable and loud enough to be heard. The system should not emit prolonged loud noise, such as banks of cooling fans, if users are expected to work in proximity without hearing protection.

• Voice and biometric recognition Technologies used to recognize voice commands and various types of biometrics should be easy to use and accurate as well.

• Ergonomics Whether portable or stationary, devices should be easy to use without inducing strain or requiring contortions to use.

• Environment Information systems should be designed to operate in a variety of environments where they would typically be used. For instance, ruggedized laptops for use at construction sites should withstand dust, dirt, water, and sunlight, while small portable devices should be water resistant and not break when dropped.

Using BMIS

Organizations employ BMIS to better understand how their people, processes, and technologies help to protect the overall organization. BMIS helps the strategist better understand the holistic relationships between various aspects (the elements) in the organization and the factors that influence them (the dynamic interconnections).

The structure of BMIS itself is a key factor in its success. Equally important, however, is the ability for holistic thinking rather than detailed thinking. It is vital to understand that BMIS shows how everything is connected to everything else. A change introduced at any element or DI will affect other elements and DIs and most likely affect the adjacent elements and DIs the most.

Considering, again, the structure of BMIS, refer to Figure 2-2.

When a security analyst or strategist is pondering an incident, problem, or situation, they identify the element or DI in the BMIS that corresponds to the subject of the matter. Next, they identify the adjacent elements or DIs and think about the relationships: these represent aspects in the organization that would be related or affected. Examining one element, noting the DI connecting it to another element, helps identify the nature of the connecting factor.

Examples are covered next, which should make these concepts clearer.

Example 1: Adverse Effects of a Policy Change   A security manager wants to enact a new policy regarding the use of personally owned mobile devices for corporate use including e-mail. Policy is a part of the governing DI, and the adjacent elements are organization and process.

The organization element here means that a new policy affects the organization in some way, by altering how it does things. The process element means that one or more processes or procedures may be affected.

But what if the new mobile device policy adversely affects other processes? One would then follow the DIs from process and see where they lead and how they lead. First, the emergence DI connects to people. In the case of this policy, emergence includes ways in which people follow—or don’t follow—the process. Next, following the enabling and support DI to technology, this could indicate how other technologies may be affected by the policy change.

Example 2: Examining Causes for Process Weakness   An organization hired a security consulting company to perform security scans of its internal network. The consulting company found numerous instances of servers being several months behind in their security patches. The organization uses a vulnerability scanning tool and is wondering why patches are so far behind.

Thinking that technology is the problem, the investigator examines the scanning tool to see whether it is operating properly. This would be the technology element. The tool is seen to be operating correctly and is running up-to-date software. The investigator next examines the BMIS model to see what DIs are connected to technology.

First, the architecture DI is examined. This prompts the investigator to think about whether the scanning tool is able to reach all systems in the network. The investigator confirms that it is.

Next, the human factors DI is examined. The investigator contacts the engineer who runs the scanning tool and asks to observe his use of the tool. The investigator is wondering whether the engineer understands how to use the tool properly (there has been a history of problems because the scanning tool is not easy to use). The engineer is using the scanning tool correctly, so the investigator needs to keep looking.

Finally, the enabling and support DI is examined. This prompts the investigator to ponder whether there are any business processes related to the use of the scanning tool that might be a factor. When interviewing engineers, the investigator discovers that there are several new networks in the organization that are not included in the scanner’s configuration.

By using the BMIS tool to understand how things relate to each other, the investigator was able to determine the cause of the problem: the failure of a network change process to notify security personnel caused those security personnel to not configure the scanning tool to include them. Thus, for some time, security scans did not identify vulnerabilities present in systems in the new network segments. The security consulting company’s scans included all of the organization’s networks, including those that the organization did not scan itself.

Security Strategy Development

Among business, technology, and security professionals, there are many different ideas about what exactly a strategy should entail and which techniques are best used to develop it, as well as general confusion on the topic. While a specific strategy itself may be complex, the concept of a strategy is quite simple. It can be defined as follows:

The plan to achieve an objective.

The effort to build a strategy requires more than saying those six words. Again, however, the idea is not complicated. The concept is this: understand where you are now and where you want to be. The strategy is the path you much follow to get from where you are (current state) to where you want to be (strategic objective).

The remainder of this section explores strategy development in detail.

Strategy Objectives

As stated earlier in this section, a strategy is the plan to achieve an objective. The objective (or objectives) is the desired future state for the organization’s security posture and level of risk.

There are, in addition, objectives of a strategy. These objectives are as follows:

• Strategic alignment The desired future state, and the strategy to get there, must be in alignment with the organization and its strategy and objectives.

• Effective risk management A security program must include a risk management policy, processes, and procedures. Without risk management, decisions are made blindly without regard to their consequences or level of risk.

• Value delivery The desired future state of a security program should include a focus for continual improvement and increasing efficiency. No organization has unlimited funds for security; instead, organizations need to reduce risk for the lowest reasonable cost.

• Resource optimization Similar to value delivery, strategic goals should efficiently utilize available resources. Among other things, this means having only the necessary staff and tools to meet strategic objectives.

• Performance measurement While it is important for strategic objectives to be SMART, the ongoing security and security-related business operations should themselves be measurable, giving management an opportunity to drive continual improvement.

• Assurance process integration Organizations typically operate one or more separate assurance processes in silos that are not integrated. An effective strategy would work to break down these silos and consolidate assurance processes, reducing hidden risks.

All of these should be developed in a way that makes them measurable. This is why these six topics were discussed earlier when discussing governance metrics. These components were made to fit together in this way.

Control Frameworks

While every organization may have its unique missions, objectives, business models, tolerance for risk, and so on, organizations need not invent governance frameworks from scratch to manage their IT objectives.

In the context of strategy development, some organizations may already have a suitable control framework in place, while others might not. While it is not always necessary for an organization to select an industry control framework, it is advantageous to do so. Industry-standard control frameworks have been in use in thousands of companies, and they are regularly updated to reflect changing business practices, emerging threats, and new technologies.

It is often considered a mistake to select a control framework because of the presence or absence of a small number of specific controls. Usually such selection is made on the assumption that control frameworks are rigid and inflexible. Instead, the strategist should take a different approach: select a control framework based on industry alignment and then institute a process for developing additional controls based on the results of risk assessments. Indeed, this is exactly the approach described in ISO/IEC 27001, as well as in the NIST Cybersecurity Framework. Start with a well-known control framework and then create additional controls, if needed, to address risks specific to the organization. When assessing the use of a specific framework, there may be occasions where a specific control area may not be applicable. In those cases, do not just ignore the section. Document both the business and technical reasons why the organization chose not to use the control area. This will assist when a question is raised at a point in the future as to why the decision was made to not implement the control area. The date and those involved in the decision should also be documented.

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

• COBIT

• ISO/IEC 27001

• ISO/IEC 38500

• ITIL / ISO/IEC 20000

• HIPAA

• NIST SP 800-53

• NIST CSF

• CIS 20

• PCI-DSS

COBIT

Developed in 1996, Control Objectives for Information and Related Technologies (COBIT) is an IT management framework developed by the IT Governance Institute and ISACA. COBIT’s four domains are Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate.

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

• Ensure risk optimization

• Manage risk

• Manage security

• Manage security resources

• Monitor, evaluate, and assess compliance with external requirements

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

ISO/IEC 27001

ISO/IEC 27001, “Information technology — Security techniques — Information security management systems — Requirements,” is an international standard for information security and risk management. This standard contains a requirements section that outlines a properly functioning information security management system (ISMS), as well as a comprehensive control framework.

ISO/IEC 27001 is divided into two sections: requirements and controls. The requirements section describes required activities found in effective ISMSs. The controls section contains a baseline set of controls that serve as a starting point for an organization. The standard is updated periodically; the latest version was released in 2015 and is known as ISO/IEC 27001:2015.

The requirements in ISO/IEC 27001 are described in these seven sections:

• Context of the organization

• Leadership

• Planning

• Support

• Operation

• Performance evaluation

• Improvement

The 14 control categories in the ISO/IEC 27001 standard are as follows:

• Information security policies

• Organization of information security

• Human resource security

• Asset management

• Access control

• Cryptography

• Physical and environmental security

• Operations security

• Communications security

• System acquisition, development, and maintenance

• Supplier relationships

• Information security incident management

• Information security aspects of business continuity management

• Compliance

While ISO/IEC 27001 is a highly respected control framework, its adoption has been modest, partly because the standard costs about $117. Unlike NIST standards, which are free of charge, it is unlikely that students or professionals will pay this much for a standard to learn more about it. Despite this, ISO/IEC 27001 is growing in popularity in organizations throughout the world.

ISO/IEC 27001 is available from https://www.iso.org/standard/54534.html (registration and payment required).

ISO/IEC 38500

ISO/IEC 38500, “Governance of IT for the Organization,” is an international standard on the corporate governance of information technology, suitable for small and large organizations in the public or private sector.

ISO/IEC 38500 is available from https://www.iso.org/standard/62816.html (registration and payment required).

ITIL / ISO/IEC 20000

Known as the IT Infrastructure Library, ITIL is a framework of processes for IT service delivery and IT service management. ITIL was originally developed by the UK Office of Government Commerce in order to improve its IT management processes. The international standard, ISO/IEC 20000, is adapted from ITIL.

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

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

HIPAA

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

• Administrative safeguards

• Physical safeguards

• Technical safeguards

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

HIPAA is available from https://www.gpo.gov/fdsys/pkg/CRPT-104hrpt736/pdf/CRPT-104hrpt736.pdf.

NIST SP 800-53

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

NIST controls are organized into 18 categories:

• Access control

• Awareness and training

• Audit and accountability

• Security assessment and authorization

• Configuration management

• Contingency planning

• Identification and authentication

• Incident response

• Maintenance

• Media protection

• Physical and environmental protection

• Planning

• Personnel security

• Risk assessment

• System and services acquisition

• System and communications protection

• System and information integrity

• Program management

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

NIST SP 800-53 is available from http://csrc.nist.gov/publications/PubsSPs.html.

NIST Cybersecurity Framework

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

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

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

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

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

• Hiring additional resources

• Training resources

• Adding or changing business processes or procedures

• Changing system or device configuration

• Acquiring new systems or devices

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

Center for Internet Security Critical Security Controls

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

The CIS CSC control categories are as follows:

• Inventory of Authorized and Unauthorized Devices

• Inventory of Authorized and Unauthorized Software

• Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers

• Continuous Vulnerability Assessment and Remediation

• Controlled Use of Administrative Privileges

• Maintenance, Monitoring, and Analysis of Audit Logs

• E-mail and Web Browser Protections

• Malware Defenses

• Limitation and Control of Network Ports, Protocols, and Services

• Data Recovery Capability

• Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

• Boundary Defense

• Data Protection

• Controlled Access Based on the Need to Know

• Wireless Access Control

• Account Monitoring and Control

• Security Skills Assessment and Appropriate Training to Fill Gaps

• Application Software Security

• Incident Response and Management

• Penetration Tests and Red Team Exercises

CIS CSC controls available from https://www.cisecurity.org/critical-controls/(registration required).

PCI-DSS

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

The PCI-DSS has 12 control objectives:

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

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

• Protect stored cardholder data.

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

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

• Develop and maintain secure systems and applications.

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

• Identify and authenticate access to system components.

• Restrict physical access to cardholder data.

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

• Regularly test security systems and processes.

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

PCI-DSS is mandatory for all organizations that store, process, or transmit credit card data. Organizations with larger volumes of card data are required to undergo annual on-site audits.

Many organizations use the controls and the principles in PCI-DSS to protect other types of financial and personal data such as account numbers, Social Security numbers, and dates of birth.

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

Risk Objectives

A vital part of strategy development is the determination of desired risk levels. One of the inputs to strategy development is the understanding of the current level of risk, and the desired future state may also have a level of risk associated with it.

It is quite difficult to quantify risk, even for the most mature organizations. Getting risk to a reasonable “high/medium/low” is simpler, though less straightforward and difficult to do consistently across an organization. In specific instances, the costs of individual controls can be known, and the costs of theoretical losses can be estimated, but doing this across an entire risk-control framework is tedious and yet uncertain because the probabilities of occurrence for threat events amounts to little more than guesswork.

Still, in a general sense, a key part of a security strategy may well be the reduction of risk (it could also be cost reduction or compliance improvement). When this is the case, the strategist will need to employ a method for determining before-and-after risk levels that are reasonable and credible. For the sake of consistency, a better approach would be the use of a methodology—however specific or general—that fits with other strategies and discussions involving risk.

Strategy Resources

Before a strategy can be developed, it is first necessary to understand everything that is in place currently. A strategy describes how goals and objectives are to be met. Without knowing the starting place in a journey, it is not possible to chart a course to the journey’s destination. Before future security capabilities can be mapped out, it’s first necessary to understand an organization’s current capabilities. The differences can be seen as a gap that needs to be filled, whether that means technologies, skills, policies, or practices.

More than simply defining point A in a journey to point B, existing resources also paint a picture of an organization’s current capabilities, including behavior, skills, practices, and security posture.

There are two types of inputs that must be considered: those that will influence the development of strategic objectives and those that define the current state of the security program and protective controls. The following are inputs that must be considered before objectives are developed:

• Risk assessments

• Threat assessments

When suitable risk and threat assessments have been completed, the security strategist can then develop strategic objectives or, if they have been created already, validate that strategic objectives will satisfactorily address risks and threats identified in those assessments.

Next, security strategists can examine several other inputs that help them understand the workings of the current security program, including the following:

• Policy

• Standards

• Guidelines

• Processes and procedures

• Architecture

• Controls

• Skills

• Metrics

• Assets

• Risk ledger

• Vulnerability assessments

• Insurance

• Critical data

• Business impact analysis

• Security incident log

• Outsourced services

• Audits

• Culture

• Maturity

• Risk appetite

All of the focus areas listed here are described in the rest of this section.

Risk Assessment

A strategist should choose to have a risk assessment performed to reveal risks present in the organization. This helps the strategist understand threat scenarios and their estimated impact and frequency of occurrence. The results of a risk assessment give the strategist valuable information on the types of resources required to bring risks down to acceptable levels. This is vital for developing and validating strategic objectives.

Any historical record of risk assessments may give the strategist a better idea of the maturity of the security program, as well as an indication of whether risks in the past had been mitigated. If older risk assessments indicate significant risks that are still present in newer risk assessments or if risk assessments are performed only for compliance purposes and not for making actual improvements in the organization’s security posture, you could wonder whether the organization places much credence in those risk assessments.

Risk assessments should drive the actual creation of strategic objectives. Otherwise, there is a danger that strategic objectives might not include changes to an organization’s security program and the protective measures needed to reduce significant risks.

Threat Assessment

Strategists should have a threat assessment performed so that they can better understand relevant threats. This gives the strategist information about the types of threats most likely to have an impact on the organization, regardless of the effectiveness of controls.

Performing a threat assessment provides an additional perspective on risk. This is because a threat assessment focuses on external threats and threat scenarios, regardless of the presence or effectiveness of preventive or detective controls. While vulnerabilities may change frequently, threats are considered to be more constant. Because of this, security policies need to reflect threats that have been identified.

A threat assessment is an essential element of strategy development. Without a threat assessment, there is a possibility that strategic objectives may fail to address important threats. This would result in a security strategy that will not adequately protect the organization.

A history of threat assessments gives the strategist insight into the maturity of the security program: an absence of threat assessments may be an indication of low maturity or scarce resources. Details in threat assessment records may reveal remediation trends if key threats are not appearing repeatedly, which would be an indication they have not been mitigated.

Policy

An organization’s security policy, as well as its practices in relation to its policy, may say a great deal about the organization’s desired current state.

Security policy can be thought of as an organization’s internal laws and regulations with regard to the protection of important assets (as well as personnel safety). Examination of current security policy can reveal a lot about what behaviors are required in the organization. The following are a few aspects of security policy:

• Breadth of coverage What subject areas are covered by the policy? Does it include expected computer and mobile device usage behavior? Are other topics such as vulnerability management, third-party risk, or software development are included in security policy?

• Relevance Does the policy include content on new technologies and practices?

• Policy strictness Does the policy broadly prohibit certain behaviors such as the occasional personal use of corporate e-mail or limit or prohibit the use of external USB data storage devices?

• Accountability and consequences Does the policy specify expectations for adherence to policy or the consequences of willingly violating policy? For instance, do policy violations include the prospect of suspension or termination of employment?

• Compliance It is important to understand the degree to which the organization is in compliance with its policy, including the margin of compliance. Does the organization’s security policy reflect good practices, and does the organization meet most or all of them? Or does its policy appear to be more of a vision statement of how things could be in the future?

• Last management review It is important to know when an organization’s security was last updated, reviewed, and approved by management. This speaks to more than just the organization’s policy but also to how active its security program has been in the recent past.

Standards

An organization’s security standards describe, in detail, the methods, techniques, technologies, specifications, brands, and configurations to be used throughout the organization.

Like security policy in the preceding section, for the organization’s standards it is important to understand the breadth of coverage, strictness, compliance, and last review and update. These all tell the security manager the extent to which an organization’s security standards are used—if at all.

In addition to the aforementioned characteristics, it is important to know how the organization’s standards were developed and how good they are. For instance, are there device-hardening standards, and are they aligned to or derived from industry-recognized standards such as Center for Internet Security, National Institute for Standards and Technology (NIST), European Union Agency for Network and Information Security (ENISA), Defense Information Systems Agency Security Technical Implementation Guides (DISA STIG), or another?

Similarly, it is important to know whether standards are highly detailed (configuration item by configuration item) or whether they are principle based. If they are the latter, then engineers may exercise potentially wide latitude when implementing these standards. You should understand that highly detailed standards are not necessarily better than principle-based standards; it depends on the nature of the organization, its risk tolerance, and its maturity.

Guidelines

While an organization’s guidelines are not “the law” per se, the presence of guidelines may signal a higher-than-average maturity. Many organizations don’t get any further than creating policies and standards, so the presence of proper guidelines means that the organization may have (or had in the past) sufficient resources or prioritization to make documenting guidance on policies important enough to do.

According to their very nature, guidelines are typically written for personnel who need a little extra guidance on how to adhere to policies.

Like other types of security program documents, guidelines should be reviewed and updated regularly. Because guidelines bridge rarely changing policy with often-changing technologies and practices, a strategist examining guidelines should find them being changed frequently—or they may be found to be irrelevant. But that, too, is possibly evidence of an attempt to improve maturity or communications (or both) but with the absence of long-term commitment.

Processes and Procedures

An organization’s processes and procedures may speak volumes about its level of discipline, consistency, risk tolerance, and maturity of not only its security program but of IT and the business in general. Like other types of documents discussed in this section, the relevance, accuracy, and thoroughness of process and procedure documents are indicators of maturity and commitment to a solid security program.

Relying on process documentation is not sufficient. Strategists need to examine more than process and procedure documents. Additionally, they must interview personnel, examine business records, and observe processes in action to ensure that they are being carried out as designed.

Further evidence of process and procedure effectiveness can be found in risk assessments and audits. Those topics are discussed later in this section.

Architecture

An organization’s architecture—that is, its documentation of systems, networks, data flows, and other aspects of its environment—gives the security strategist a lot of useful information about how the organization has implemented its information systems.

While it’s good to look for and examine network diagrams, system diagrams, data flow diagrams, and so forth, it’s nearly as valuable to find good and consistent designs even if they aren’t documented anywhere. I’d rather see an organization’s infrastructure as modern, effective, and consistent versus a collection of outdated diagrams or, worse yet, inconsistent uses of technologies and techniques throughout an organization. Whether architecture diagrams exist or not is a concern that is similar to that regarding policies, standards, guidelines, and other artifacts.

Equally important here is whether the architecture of technology effectively supports the organization. Does an organization’s technology and the way that the technology has been implemented adequately support the organization’s goals, objectives, and operations? Like so many other aspects of information security and information technology, alignment with the business and its goals and objectives is critical and cannot be disregarded. Making key changes in this regard may need to be part of an overall strategy.

Another aspect of architecture is known as technical debt. This is a term that represents two characteristics of an organization’s infrastructure:

• Poor design Lack of an overall design, or a poor design, causes subsequent additions and changes to the environment to be done in a less than optimal manner, further degrading the environment in terms of performance, resilience, or simplicity.

• Outdated and unsupported components In this instance, major hardware or software components of the environment have exceeded their service life, are no longer supported by their manufacturers, or have subcomponents that cannot be easily replaced.

The concept of technical debt is a metaphor for financial debt in two aspects. First, “interest payments” come in the form of additional effort every time the environment requires attention. Next, “retiring the debt” requires major architectural changes and/or replacement of many components.

Technical debt is accumulated when organizations lack personnel capable of creating good architectural designs and also when an organization fails to upgrade end-of-life components.

Controls

The presence of controls—and the control framework—speaks volumes about the organization’s security program. However, controls may exist only on paper and not in practice. It is useful to read about the organization’s controls, but by themselves we know very little. The strategist needs to understand whether the controls are actually implemented. More than that, it’s important to know whether they are effective.

When examining control documentation, the strategist should look for details such as control owners, the purpose and scope of controls, related process and procedure documents, and other metadata that will help the strategist understand their purpose.

Next, the strategist should look for artifacts or interview personnel to see whether specific controls are in place. Again, the presence of documentation alone may not indicate they are actually being carried out or whether documentation is just more shelf-ware. Interviewing personnel and observing controls in action is a better way to see whether controls are in place.

Internal and external audits, discussed later in this section, are another way to understand control effectiveness. See the “Audits” section.

A strategist will want to understand whether the controls in place are part of a control framework such as ISO27001, NIST 800-53, HIPAA, or PCI. But more than that, are all controls in the control framework implemented, or have some been omitted? The reason for omission may vary from irrelevance to irresponsible avoidance.

Finally, the strategist should look for additional controls that have been implemented. This may be a sign of regulatory requirements or the result of an effective risk management program where identified risks compelled management to enact additional controls to mitigate risk.

Skills

An inventory of skills provides the strategist with an idea of what staff members are able to accomplish. This is useful on a couple of levels.

• Tenure This includes how many years of different types of experience a staff member may have.

• Behavioral This includes leadership, management, coordination, and logistics.

• Disciplines This includes fields such as systems engineering, network engineering, controls development, audit, risk management, and risk analysis.

• Technologies This includes skills with specific technologies such as Palo Alto Networks firewalls, CentOS operating systems, Logrhythm, and AppScan.

Understanding skills at all of these levels helps the strategist understand the types of work that the current staff is able to perform, where minor skills gaps are, and where the strategist may recommend adding additional staff through hiring, contracting, or professional services.

A key consideration a strategist needs to keep in mind is the potential for a major shift in technologies. A good example is if the organization has been using products from a particular vendor for many years, but because of a change in leadership and a good deal by a different vendor, the decision was made to migrate to a different vendor’s products. Without fully understanding the skills and capabilities of the team, an organization can create significant risks because of the lack of ability to effectively manage the new products. This could lead to outages, departure of key resources, increased cost associated with consulting, and a loss of trust from the end-user community.

Metrics

Metrics indicate the state of an information security program over time. Effective metrics help personnel see how effectively the security program is protecting the organization; this is a key consideration for the people developing long-term strategies.

If metrics were properly established, they’ll serve as a guide for the long-term effectiveness of security controls. This helps the strategist understand what works well and where improvement opportunities are. The strategist can then design end states with more certainty and confidence than if metrics didn’t exist.

When examining metrics, a strategist needs to understand the audience. For example, were security metrics developed for internal security operations’ use only, or were the metrics developed for consumption by other audience, such as internal users, senior management, or the board of directors? Next, the strategist will want to look for evidence that metrics were delivered to these other audiences and whether metrics were ever used as a reason for making tactical or strategic changes in the security program.

Assets

It is often said among information security professionals, “You cannot protect what you cannot find.” This saying refers to assets in an organization, namely, servers, network devices, end-user workstations, and mobile devices—but also application software and software tools. Because many security incidents involve the exploitation of a vulnerability (usually with malware), this necessitates that organizations have effective vulnerability management programs in place. The life-cycle process in a vulnerability management program is as follows:

• Identify the environment to be scanned.

• Scan assets for vulnerabilities.

• Identify and categorize vulnerabilities.

• Remediate vulnerabilities (often through applying security patches but sometimes through configuration changes or increased monitoring and alerting).

Depending on an organization’s tools and methods, it’s typical that only known identified assets are scanned. Unknown or unidentified assets may or may not get scanned, but even if they do, they might get lost in the process later. Intruders are familiar with this and use this to their advantage: by performing scans of their own, they can identify unpatched systems and use them as a beachhead from which to infiltrate the organization.

Risk Ledger

A risk ledger can give the strategist a great deal of insight into risk management and risk analysis activities in the organization. Depending on the detail available in the risk ledger, a strategist may be able to discern the following:

• Scope, frequency, quality, and maturity of risk assessments

• Presence or absence of risk treatment

• Security incidents

A risk ledger is the business record reflecting the history and findings from risk assessments, threat assessments, vulnerability assessments, security incidents, and other activities. Its content reflects the types of activities occurring in the information security program and the significant results of those activities.

The lack of a risk ledger would indicate that the organization’s security management program is not taking a risk-based approach. Instead, the organization may be compliance based or, worse yet, asset based or ad hoc. These approaches are signs of lower maturity where the organization’s security personnel are mainly reactive and do little planning.

Vulnerability Assessment

Strategists may choose to have a vulnerability assessment performed so that they may better understand the current security posture of the organization’s infrastructure. The vulnerability assessment may target network devices, appliances, operating systems, subsystems such as web servers and database management system, and applications—or any suitable combination thereof.

The results of a vulnerability assessment will tell the strategist several things about the organization, including the following:

• Operational maturity The consistency of vulnerabilities among targets will reveal whether the organization has configuration standards or automated tools for managing the configuration across targets. When a vulnerability assessment finds variations in vulnerabilities among similar systems, you may assume that the organization is not using automated tools to distribute patches to its systems but instead appears to be installing patches in an ad hoc manner. On the other hand, when the vulnerability assessment shows consistency in vulnerabilities among similar systems, this is an indication of greater operational maturity and possibly the presence and use of automated tools for system management.

• Security maturity The range of vulnerabilities among targets will reveal the maturity of the organization’s vulnerability management program. If the presence or absence of security patches is inconsistent or if there are numerous older vulnerabilities found, this may indicate that vulnerability management is given a low priority or insufficient resources. When a vulnerability assessment identifies large numbers of vulnerabilities—particularly “high” and “critical” vulnerabilities dating back many months or longer—this is an indication that the organization is not placing emphasis on basic security hygiene.

Insurance

The security strategist may want to know whether the organization has cybersecurity insurance or any general insurance policy that covers some types of cyber events and incidents.

As important as having cyber insurance is, equally important is the reason the organization purchased it. A strategist will want to explore possible reasons.

• Compliance The organization may have purchased a cyber-insurance policy to be compliant with a law, regulation, or standard.

• Customer requirement The organization may have a cyber-insurance policy because a key customer required it.

• Prior incidents Perhaps the organization has a cyber-insurance policy because a costly incident occurred in the past. Similarly, a company known to the organization’s management may have suffered an incident, prompting the organization to purchase cyber insurance in case a similar event could happen to them.

• Risk treatment The organization may have purchased cyber-insurance because risks were identified that the organization chose to have transferred to another organization.

It is vitally important to understand the terms of any cyber-insurance policy. While the amounts of benefits are important, the most important aspects of a cyber-insurance policy are its terms and conditions. Many organizations have been known to purchase cyber-insurance policies only to find out that they receive little or no relief from them because of one or more exclusions. Cyber-insurance policies vary quite a lot, and many require policyholder organizations to have many policies and controls in place. Interestingly enough, organizations that have the required components in their security programs are much less likely to experience significant security incidents—but this is the whole point of developing an information security strategy and the use of cyber insurance: risk reduction. This is similar to automobile insurance, homeowners’ insurance, and renters’ insurance: it is important to read and fully understand insurance policies in detail.

Critical Data

Most organizations do not have an accurate notion regarding the location and use of their critical data. Organizations have their key business applications that store and process their critical data, but in most organizations, copies of parts of their critical data also reside in many other places, including internal file servers, sanctioned data storage services such as Box and Dropbox, and unsanctioned data storage services and unsanctioned cloud-based applications.

While this section is not about the cloud and cloud services, it is precisely the existence and ease of use of cloud services that make it so easy for individuals and groups in an organization to upload critical data to these services. The fact that many cloud-based services offer low-cost and zero-cost services encourages this phenomenon all the more. This has given rise to the colloquial phrase “bring your own app” as a way of labeling this growing problem. Sanctioned or not, most organizations have lost sight of all the locations and uses of their critical data.

Another component of critical data is the bring-your-own-device (BYOD) phenomenon, which results in sensitive business information residing on personally owned devices, outside of the organization’s direct control. The ubiquity and openness of IT services makes it all but impossible for organizations to prevent staff members from using personally owned devices as part of their work.

The cloud and BYOD underscore the lack of visibility and control over critical and sensitive data. Understanding this is important for strategists when determining the current state of security, which, as stated before, is required if a viable strategy is to be developed to take the organization to a desired future state. This is one of many categories where a strategist will be unable to gather all desired facts about the state of security and where experience and judgment is required to tread on without knowing all that should be known.

Business Impact Analysis

A business impact analysis (BIA) is used to identify an organization’s business processes, the interdependencies between processes, the resources required for process operation, and the impact on the organization if any business process is incapacitated for a time.

A BIA is a cornerstone of a business continuity and disaster recovery (BCDR) program because the BIA indicates which business processes and underlying resources are the most vital to the organization. The most critical processes are those that receive the most attention during the development of disaster recovery and business continuity plans.

The BIA is also useful for information security professionals aside from business continuity purposes. Again, the BIA indicates the most critical processes (and underlying resources such as information systems and other IT infrastructure), giving the security strategist a better idea of which business processes and systems warrant the greatest protection.

The presence of a BIA provides a strong indication of the organization’s maturity, through its intention to protect its most critical processes from disaster scenarios. Correspondingly, the absence of a BIA suggests that the organization does not consider BCDR as having strategic importance.

Security Incident Log

A security incident log provides the strategist with a history of security incidents in the organization. Depending on the information that is captured in the incident log, the strategist may be able to discern the maturity of the organization’s information security program, especially its incident response program. For instance, a highly mature organization will perform post-mortem analysis on significant incidents and direct changes to take place in people, processes, and technology to reduce the probability, impact, or scope of similar incidents in the future.

Like other business records and activities, the strategist needs to understand the reason for the existence of the security incident log. Is it in place merely for compliance purposes (in which case the incident log may be sparsely populated and there may be an absence of corrective actions), or does the organization really want to learn from and even anticipate security incidents? These are the deeper questions that the security strategist needs to discover and know.

An organization with a sparsely populated incident log may be an indication of several things, including the following:

• Lack of/deficient SIEM A security information and event management (SIEM) is a system that collects log data from servers, endpoints, network devices such as firewalls, and other sources such as antivirus consoles; correlates this log data; and produces security alerts when actionable security-related activities are taking place. An organization without a SIEM may have little way of knowing whether security incidents such as break-ins are occurring. Similarly, an organization with a SIEM that is not well maintained may also have many blind spots and be unaware of incidents occurring in its environment.

• Training Personnel may not be trained in the recognition of security incidents. Security incidents might be occurring but go unrecognized, resulting in incidents with greater impact and the loss of learning opportunities.

Outsourced Services

Most organizations outsource a good portion of their IT systems and services. Unlike earlier eras when organizations had their own data centers and when most or all applications were running in-house (usually called on-premise), today the model has almost completely flipped: organizations are moving the bulk of their business applications to cloud-based infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) environments.

The degree to which any particular organization has outsourced its business applications to the cloud is not the concerning matter. Instead, what’s important is the amount of due care exercised in the process of outsourcing.

The practice of determining and managing risks associated with outsourcing is called third-party risk. In lawyer-speak, these external organizations are called third parties (and the organizations they outsource to are called fourth parties).

The third-party risk practices that the strategists are looking for include the following:

• Up-front due diligence This is an assessment of risk performed on a service provider prior to the organization electing to use the service. This initial risk assessment gives the organization an opportunity to enforce security-related terms and conditions on the service provider in the legal agreement. An up-front risk assessment may include one or more of the following:

• Relationship risk assessment Here, the organization analyzes the strategic importance of the service provider in terms of contract value and service criticality.

• Inherent risk assessment This is an analysis of the service provider’s financial health and geopolitical risk.

• Control risk assessment This is an analysis of the controls that the organization would like the service provider to use to protect the organization’s data.

• Site visit The organization may elect to visit one or more of the service provider’s processing sites and perhaps corporate offices.

• Risk tiering This is the practice of establishing tiers of service provider risk. Each service provider, based on the nature of services provided to the organization, is assigned a risk level, or tier. The due diligence activities performed for each tier are commensurate with the risk level. For example, services providers at the highest risk tier may be issued a lengthy questionnaire annually, required to undergo annual penetration tests, as well as an on-site visit to confirm the presence of key controls. Service providers at a middle tier of risk may be issued a shorter questionnaire annually, and service providers at the lowest tier may be issued a brief questionnaire annually. Response to questions in questionnaires answered negatively will also vary according to risk tier. For top-tier services providers, this may involve a detailed mitigation plan; at lower tiers, there is lower concern.

• Ongoing due diligence Throughout the duration of a service provider relationship, the organization will periodically assess each service provider to ensure that risks discovered at the start of the relationship have not significantly changed. An organization will carry out a number of activities, as outlined for up-front due diligence.

Audits

Internal and external audits can tell the strategist quite a bit about the state of the organization’s security program. A careful examination of audit findings can potentially provide significant details on control effectiveness, vulnerabilities, disaster preparedness, or other aspects of the program—depending on the objectives of those audits.

When examining audit results, a security strategist needs to understand several things.

• Objective The objective or purpose of the audit tells the reader why the audit took place. This often provides additional insight on why certain people, processes, or technologies were examined while others were apparently omitted. For example, was an audit performed because it is required by regulation or another requirement, or was it performed voluntarily as another means of self-improvement?

• Scope The scope of an audit tells the reader which technologies, business processes, business locations, or other aspects of the organization were examined.

• Qualifications of auditors An audit is going to be only as effective as its auditors are skilled and experienced in performing audits, as well as their familiarity with the things being audited. An IT auditor with little operational IT experience is not going to be as effective and insightful as an IT auditor with a background in some aspect of IT engineering or operations.

• Audit methodologies It is important for the reader to understand the audit methodologies used in any particular audit. For instance, did the auditor interview personnel, examine systems and records, observe personnel performing their tasks, or perform tasks of their own? Equally important are sampling methodologies, including how samples are selected and who performs the selection.

The security strategist needs to consider the bigger picture. Mainly, is the organization taking audit results and driving improvements into the organization, or are audit reports merely shelfware to show to regulators on their annual visit?

Culture

The culture of an organization can tell the strategist a lot about the state of security. Many people mistakenly believe that information security is all about the technology. While technology is part of security, the most important aspect of information security is people. No amount of technology can adequately compensate for the wrong attitude and understanding about protecting an organization’s information assets. People are absolutely key.

A strategist will want to explore a few aspects of an organization’s culture, including the following:

• Leadership It is important to understand the actions of executive management, mainly to see whether they abide by company policies and lead by example. A classic example is on the topic of “no personal devices for company business” policy, but the CEO wants his personal iPad connected to corporate e-mail.

• Accountability The strategist will look for evidence that the organization enforces company policies and requires employees to be accountable for violations. Equally important is the observation of outcomes of bad decisions—are decision-makers held accountable?

• Empowerment Organizations are sometimes measured by employee empowerment and whether employees are implicitly given the go-ahead to act and “ask for forgiveness” if something goes wrong versus organizations that do not empower employees, requiring them to “ask for permission” before acting. There is not so much about good versus bad but rather to have an understanding of how the organization behaves. Also important is the organization’s behavior when things go wrong. Does the organization seek to punish the guilty, learn from its mistakes, or somewhere in between?

• Security awareness Even now, people seem to lack much Internet safety common sense and seem willing to click anything arriving in their inboxes. While this may seem a discouraging point of view, many organizations do an inadequate job of informing their personnel about the various risks associated with Internet and computer usage. A strategist will want to investigate the organization’s security awareness program to see how engaging the program is, how rigorous any training is, and whether there are rewards for good behavior and penalties for risky behavior. The other aspects in this section—leadership, accountability, and empowerment—are all related to security awareness because they help the strategist understand whether executives lead by example, whether empowered personnel make good decisions that impact security, and whether personnel are accountable for their actions.

These and other aspects of an organization’s culture help the strategist better understand the organization’s present state.

Maturity

The characteristics of a security management program discussed in this section all contribute to the overall maturity of the organization’s program. By itself, the maturity level of the program doesn’t tell the strategist anything about the program’s details. But the strategist’s observations of the overall program will provide a “thumb in the air” feeling for its overall maturity.

The strategist will probably find that the maturity levels of various aspects of the organization’s security program vary widely. For instance, the organization may have mature asset management and vulnerability management programs but be lacking in other areas such as internal audit and security awareness.

The levels of maturity are discussed in greater detail in the next section, “Strategy Development.” Maturity also plays a part during a gap assessment, also discussed in the next section.

Strategy Development

After the security strategist has performed risk and threat assessments and carefully reviewed the state of the security program through the examination of artifacts, the strategist can develop strategic objectives. Generally speaking, strategic objectives will fall into one of these categories:

• Improvements in protective controls

• Improvements in incident visibility

• Improvements in incident response

• Reductions in risk, including compliance risk

• Reductions in cost

• Increased resiliency of key business systems

These categories all contribute to strategic improvements in an organization’s security program. Depending on the current and desired future state of security, objectives may represent large projects or groups of projects implemented over several years to develop broad new capabilities, or they may be smaller projects focused on improving existing capabilities.

Examples of broad, sweeping objectives for developing new security capabilities include the following:

• Define and implement a SIEM to provide visibility into security and operational events.

• Define and implement a security incident response program.

• Define and implement a security awareness learning program.

Examples of objectives for improving existing capabilities include the following:

• Integrate vulnerability management and GRC systems.

• Link security awareness and access management programs so that staff members must successfully complete security awareness training to retain their system access.

Once one or more objectives have been identified, the security strategist will undertake several activities that are required to meet the objectives. These activities are explained in the remainder of this section.

The strategist must consider many inputs before developing objectives and strategies to achieve them. These inputs serve a critical purpose: to help the strategist understand the organization’s current state. The journey to developing and achieving a strategy is not possible without understand the journey’s starting point. These are discussed in the previous section, “Strategy Resources.”

Gap Assessment

To implement a security strategy and accomplish objectives, security professionals often spend too much time focusing on the end goal and not enough time on the starting point. Without sufficient knowledge of the starting point, accomplishing objectives will be more difficult, and achieving success will be less certain.

A gap assessment will need to focus on several aspects of a security program, including one or more of these:

• Existing/previous strategy Understanding prior strategies can reveal much about the security program in the past. Several aspects of prior strategies to consider include the following:

• Was the prior strategy actually a strategy, or was it an objective, a road map, or something else?

• Was the strategy achievable?

• Was the strategy achieved, or was reasonable progress made?

• Was the strategy business aligned?

• Was the strategy measurable?

• Were sufficient resources made available to achieve the strategy?

• Security charter The organization may have a charter that defines a strategy, roles and responsibilities, objectives, or other matters.

• Security policy Existing security policy needs to be carefully studied to understand alignment between security policy and the strategy. The security manager should review security policy enforcement as well as exceptions and related incidents.

• Security standards Existing security standards should be examined to understand what emphasis has been placed on proven and consistent methods for hardening systems. The security manager will want to look at the approach. Are security standards a set of principles only, or do they include configuration details?

• Security procedures This includes security procedures, as well as IT and other business procedures that have security subject matter or implications.

• Security guidelines While security guidelines are considered optional, it is important to understand what they say about implementing security policies and procedures. Content in security guidelines may provide important clues on organizational culture and its views about policy.

• Security controls While it is necessary to review control objectives and control narratives, it is equally important to understand control effectiveness and how well controls support existing objectives.

• Risk assessments Available risk assessments may provide insight into risks observed in the organization. This would provide a valuable, risk-based perspective on the state of the organization in the recent—or not so recent—past.

• Internal and external audit results Audit reports are generally seen as an in-depth view of the effectiveness of internal controls in the organization. A security manager needs to understand how to read the audit report—as well as be able to read in between the lines—to understand specific audit methodologies used to examine controls and report on them. Note that for some audits, auditors are examining specific controls, whether or not they actually exist in the organization. Understanding the scope of an audit is also important, as it may in some cases be quite narrow and not provide a broad view of control risk.

• Security metrics Examining security metrics over time should give a security manager some important information. Not only can certain details of the security program be seen, but the bigger picture is also important: the metrics that the organization chose to measure. If metrics have been in place long enough, there may be trends that can be observed.

• Risk ledger An organization’s risk ledger can provide insight into the issues that are considered important security issues. Depending on the details are available in the risk ledger, a security manager may be able to discern the various activities and methods in place to capture content for the risk ledger.

• Risk treatment decision records When available, risk treatment records reveal what issues warranted attention, discussion, and decisions. Coupled with the risk ledger, information here can provide a record of issues tackled by the organization’s risk management process.

• Security incident program This includes program objectives, processes, procedures, records, tools, and practices. Further, the presence of playbooks indicates a desire to respond quickly and effectively when an incident occurs.

• Security incident records The record of security incidents can reveal a lot about the capabilities and attitudes in the security program. A sparse record might indicate gaps in capabilities or skills. A rich record is probably an indication of a more mature program and personnel intent on identifying issues so that improvements can be made.

• Third-party risk Vendor risk, also known as third-party risk, is a near-universal problem for organizations, given the trend in outsourcing line-of-business applications and the use of cloud-based services. Here, the security manager needs to understand the degree of attention the organization places on third-party risk, including the completeness of business records, the frequency of risk and control assessments, the history of site visits, and the organization’s practice of following up on risk issues discovered in key third parties.

• Business continuity and disaster recovery program The presence of business continuity planning (BCP) and/or disaster recovery planning (DRP) activities is a good indication (although not a certain one) that the organization cares enough about its long-term viability that it wants to minimize the impact of natural and man-made disasters. A security manager needs to understand whether BCP/DRP records and procedures are up-to-date and to what extent the organization elects to train its personnel and conduct tests of its plans.

• Security awareness training program A security awareness training and communications program says a lot about an organization, namely, the extent to which the organization acknowledges that people are a critical aspect to the success of a program and its ability to protect itself from harm. The variety of messaging techniques used, as well as their frequency, are important aspects of a security awareness program, but they are not as important as the program’s alignment with the organization.

• IT and security projects Business records for recent projects speak volumes about the organization’s value and emphasis on security. The security manager will want to look through the list of project participants to see whether security personnel are included. Equally important are the presence (or absence) of security requirements—if requirements are part of bigger projects.

When examining all of this and other information about an organization’s security program, the security strategist should bring the right measure of skepticism. There is much to know about what information is found, but the absence of information may speak volumes as well. Here are some considerations:

• Absence of evidence is not evidence of absence This time-honored quote applies to artifacts in any security program. For instance, a sparse or nonexistent security incidents log may be an indication of several things: the organization may not have the required visibility to know when an incident has taken place, the organization’s staff may not be trained in the recognition of incidents, or the organization may only be watching for “black swan” events and be missing the routine incidents.

• Freshness, usefulness, and window dressing When it comes to policy, process, and procedure documentation, it is important to find out whether documents are created for appearances only (in which case they may be well-kept secrets except by their owners) or whether they are widely known and utilized. A look at these documents’ revision histories tells part of the story, while interviewing the right personnel completes the picture by revealing how well their existence is known and whether they are really used.

• Scope, turf, and politics In larger organizations, the security manager needs to understand current and historical practices with regard to roles and responsibilities for security and security-related activities. For example, records for a global security program might instead reflect only what is occurring in the Americas, even though there may not be anything found in writing to the contrary.

• Reading between the lines Depending upon the organization’s culture and the ethics of current or prior security personnel, records may not accurately reflect goings-on in the security program. There may be overemphasis, underemphasis, distortions, or simply “looking the other way” situations that may result in records being incomplete.

• Off the books For various reasons, certain activities and proceedings in a security program may not be documented. For example, certain incidents may conveniently not be present in the incident log—otherwise, external auditors might catch the scent and go on a foxhunt, causing all manner of unpleasantries.

• Regulatory requirements When examining each aspect of a security program, the security manager needs to understand one thing: Is that activity there because it is required by regulations (with hell and fury from regulators if absent) or because the organization is managing risk and attempting to reduce the probability and/or impact of potential threats?

When performing a gap assessment, a strategist is examining the present condition of processes, technologies, and people. But by definition, a gap assessment is the study of the difference between the present condition of something and the desired future state. A common approach to determining the future state is to determine the current maturity of a process or technology and compare that to the desired maturity level. Continue reading in the next section for a discussion on maturity levels.

Strengths, Weaknesses, Opportunities, Threats Analysis

Strengths, weaknesses, opportunities, and threats (SWOT) analysis is a tool used in support of strategy planning. SWOT involves introspective analysis where the strategist asks four questions about the object of study:

• Strengths What characteristics of the business give it an advantage over others?

• Weaknesses What characteristics of the business put it at a disadvantage?

• Opportunities What elements in the environment could the business use to its advantage?

• Threats What elements in the environment threaten to harm the business?

SWOT analysis uses a matrix, as shown in Figure 2-5.

Figure 2-5 A SWOT matrix with its four components (Courtesy of Xhienne)

Capability Maturity Models

The Software Engineering Institute (SEI) at Carnegie Mellon University accomplished a great deal with its development of the Capability Maturity Model Integration for Development (CMMi-DEV). Capability maturity models are useful tools for understanding the maturity level of a process. Maturity models in other technology disciplines have been developed, such as the Systems Security Engineering Capability Maturity Model (SSE-CMM).

The CMMi-DEV uses five levels of maturity to describe the formality of a process.

• Level 1: Initial This represents a process that is ad hoc, inconsistent, unmeasured, and unrepeatable.

• Level 2: Repeatable This represents a process that is performed consistently and with the same outcome. It may or may not be well-documented.

• Level 3: Defined This represents a process that is well-defined and well-documented.

• Level 4: Managed This represents a quantitatively measured process with one or more metrics.

• Level 5: Optimizing This represents a measured process that is under continuous improvement.

Not all security strategists are familiar with maturity models. Strategists unaccustomed to capability maturity models need to understand two important characteristics of maturity models and how they are used:

• Level 5 is not the ultimate objective. Most organizations’ average maturity level targets range from 2.5 to 3.5. There are few organizations whose mission justifies level 5 maturity. The cost of developing a level 5 process or control is often prohibitive and out of alignment with risks.

• Each control or process may have its own maturity level. It is neither common nor prudent to assign a single maturity level target for all controls and processes. Instead, organizations with skilled strategists can determine the appropriate level of maturity for each control and process. They need not all be the same. Instead, it is more appropriate to use a threat-based or risk-based model to determine an appropriate level of maturity for each control and process. Some will be 2, some will be 3, some will be 4, and a few might even be 5.

The common use of capability maturity models is the determination of the current maturity of a process, together with analysis, to determine the desired maturity level process by process and technology by technology.

Road Map Development

Once strategic objectives, risk and threat assessments, and gap analyses have been completed, the security strategist can begin to develop road maps to accomplish each objective.

A road map is a list of steps required to achieve a strategic objective. The term road map is an appropriate metaphor because it represents a journey that, in the details, may not always appear to be contributing to the objective. But in a well-designed road map, each task and each project gets the organization closer to the objective.

A road map is just a plan, but the term road map is often used to describe the steps that an organization needs to take to undertake a long-term, complex, and strategic objective. Often a road map can be thought of as a series of projects—some running sequentially, others concurrently—that an organization uses to transform its processes and technology to achieve the objective.

Figure 2-6 depicts a road map for an 18-month identity and access management project.

Figure 2-6 Sample road map for identity and access management initiative (Courtesy of High Tech Security Solutions Magazine)

Policy Development

The execution of a security strategy may result in additions or improvements in its security-related capabilities. These additions or improvements might require that one or more security policies be updated to reflect these new or improved capabilities.

While security policies are designed to be durable and not tied to specific technologies, significant changes in technologies might put security policy at odds with them. Here is an example:

The Fast Car Company recently implemented its first security incident and event monitoring system that produces alerts whenever actionable security events occur. Prior to implementing the SIEM, IT and security personnel would examine security logs every day to see whether any security events had occurred in the past 24 hours.

Before implementing the SIEM, Fast Car Company’s security policy stated that appropriate personnel were required to examine security logs daily and log any actions taken. Now that Fast Car Company has a SIEM, IT and security personnel no longer need to examine logs. The company’s policy needs to be changed so that 1) personnel are required to respond to security alerts, and 2) personnel are required to periodically examine the SIEM’s configuration so that it will produce alerts for relevant events.

Security policies are supposed to align with current capabilities and not be a vision statement describing future capabilities. This is the case whether policies are addressing the use of technologies or business processes. It’s generally considered unwise to develop a security policy that requires an activity that the organization is incapable of performing.

Industries generally consider security policies as being out-of-date if they are not examined and updated annually. This is not saying that security policies are required to be updated annually but that they be examined annually and updated as needed.

While not generally required in most industries, it is nonetheless a common practice to structure the organization’s security policy with one or more relevant standards or frameworks. Common standards and frameworks used in this way include

• NIST SP 800-53

• ISO 27001

• HIPAA/HITECH

• PCI-DSS

• CIS CSC 20

Because security frameworks are moderately to highly technical, some organizations develop a shorter information security policy focused in Internet hygiene and data protection for all of its workers (often called an acceptable-use policy) and a separate technical security policy for its technology workers who design, implement, and manage information systems and applications. This pragmatic approach helps to avoid, for instance, nontechnical office workers trying to understand and comply with cryptography and access management policy; with such unintelligible content, workers are more likely to “tune out” the security policy in its entirety and not benefit from the relevant parts of policy that really matter, such as recognizing phishing scams.

The goal of a good security policy is to define the “rules of the road” for an organization’s employees. Policies should be clear, concise, and applicable to the organization. The policies should be developed in a collaborative manner to reduce prevent situations like the previous example. Additionally, if policies are written without the involvement or buy-in of the different stakeholders, an organization risks deploying policies that it cannot adhere to or will cause significant investment to comply to the policy.

Controls Development

When an organization executes a security strategy, often this means that the organization has made changes to its security-related capabilities. This, in turn, may necessitate changes to one or more aspects of existing controls, as well as the development of new control and the retirement of controls that are no longer necessary.

Controls are generally changed as a result of a risk assessment, where some unacceptable risk was identified and a decision made to implement a control to ensure better outcomes. Quite possibly, a risk assessment may have compelled the organization to make some changes in the form of security projects that were part of a strategy. When these projects are executed and completed, controls related to the processes or technologies involved need to be changed accordingly. Here are some of the possible outcomes:

• Changes to control narrative Changes to processes, procedures, or technologies will undoubtedly impact control narratives, which often describe controls in detail. Project deliverables will include these changes.

• Changes to scope Changes in processes, procedures, or technologies may require that the scope of one or more controls be changed. For instance, if an organization replicates sensitive data to another data center as part of a business continuity strategy, the scope of controls related to the protection of sensitive data may need to be expanded to include the additional data center.

• Changes in control testing New or different processes, procedures, or technologies will often mean that the procedures for testing a control will have changed. One of the project deliverables will be updates to control testing procedures. For example, the implementation of a new single sign-on (SSO) tool will require new instructions for control testing so that internal auditors and others will know what steps to perform to view information related to access controls.

• Entirely new control Sometimes a new or changed security capability provides an opportunity (or possibly a mandate) to create a new control. For instance, the acquisition of a new identity and access management auditing tool brings an entirely new capability, that of auditing various aspects of user accounts, roles, and accesses. Prior to the tool, performing the work manually was infeasible, so there was no control. And this absence may have been documented in a risk assessment, which gave way to the project that enables this capability. When the new capability is finally implemented, a new control is developed to ensure the user audits are regularly performed.

Selecting a Control Framework

Organizations that desire to raise their security maturity often start by selecting a control framework. Organizations often spend an excessive amount of time selecting a control framework, typically struggling to decide between CIS CSC, ISO/IEC 27002, and NIST 800-53. An organization lacking a control framework typically spends too much time stuck at this point, arguing the finer points of each control framework without realizing that there is not a great deal of difference between them. This is like a person accustomed to walking everywhere shopping for an automobile and getting hung up on two-door versus four-door or gas-powered versus diesel or hybrid, all the while ignoring the fact that any of these choices is going to result in a significant shift in travel time.

Standards Development

An organization executing a security strategy may find that one or more of its standards are impacted or that new standards need to be developed.

While policies define what is to be done, standards define how policies are to be carried out. For instance, a policy may stipulate that strong passwords are to be used for end-user authentication. A password standard, then, would be more specific by defining the length, complexity, and other characteristics about a strong password.

Where policies are designed to be durable and long-lasting, they do so at the expense of being somewhat unspecific. Standards take on the burden of being more specific but also that they change more frequently because they are closer to the technology and are concerned with the details of the implementation of policy.

Standards need to be developed carefully, for several reasons:

• They must properly reflect the intent of one or more corresponding policies.

• They will have to be able to be successfully implemented.

• They need to be unambiguous.

• Their directives will need to be able to be automated, where large numbers of systems, endpoints, devices, or people are involved, leading to consistency and uniformity.

There are several types of standards in use, including the following:

• Protocol standards Examples include TLS 1.2 for web server session encryption, AES-256 for encryption at rest, 802.11ac for wireless networking, and SAML 2.0 for authentication.

• Vendor standards For example, tablet computers are to be Apple iPad and iPad Pro, perhaps with specific model numbers.

• Configuration standards For instance, a server-hardening standard would specify all of the security-related settings to be implemented for each type of server operating system in use.

• Programming language standards Examples include C++, Java, and Python. Organizations that do not establish and assert programming language standards may find themselves with programs written in dozens of different languages, which may drive up the cost of maintaining them.

• Methodology standards Examples include the use of factor analysis of information risk (FAIR) risk analysis techniques; Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) for security assessments: and SMART for the development of strategic objectives.

• Control frameworks These include NIST SP800-53, PCI-DSS, HIPAA, COBIT, and ISO 27002.

Because technologies change so rapidly, standards are often reviewed and updated more frequently than policies. New security strategies are not the only reason that standards are reviewed and updated; other reasons include the release of new versions of hardware and software, new techniques for data protection, and the acquisition of new network devices and applications.

Processes and Procedures

Processes and procedures describe the steps to be followed when carrying out functions and tasks. They exist so that these activities may be performed more consistently, in the right sequence, and in the right way.

Implementation of a security strategy means that new things will be done, some things will be done differently, and other things will no longer be done. All of these have a direct impact on processes and procedures.

Often, the purpose of a new security strategy is the increase in maturity of security-related technologies and activities in an organization. And because many organizations’ security maturity levels are low, often this means that many important tasks are poorly documented or not documented at all. The desired increase in maturity might compel an organization to identify undocumented processes and procedures and assign staff to document them. An organization in such a state might also consider developing document management procedures and standards so that there is consistency among all processes, procedures, and their written documents, as well as consistent development and review.

Roles and Responsibilities

The implementation of a new security strategy often impacts the way people work. When the strategy involves changes in technologies or processes (as they usually do), this may in turn impact the roles and responsibilities for security personnel, IT workers, and perhaps other staff. Where business processes are added or changed, this often means that changes need to be made to the roles and responsibilities of personnel.

In organizations without documented roles and responsibilities, this is an opportunity to document them. This can be done in a number of different ways, including the following:

• Job descriptions

• Department charter documents

• Department policy documents

• Roles and responsibility sections of process documents

Training and Awareness

Execution of a new security strategy often has broad reach, impacting technology as well as policies, standards, processes, and procedures. The result of this is new information, in many forms and for several audiences, including the following:

• General security awareness

• New and updated processes and procedures

• New and updated technologies

Each of these may necessitate additions or updates to training content.

Recent studies indicate that more than 90 percent of breaches begin with phishing attacks. Arguably, security awareness training is one of the most important defenses available for an organization, given that with even the best spam filters, some phishing attacks do successfully penetrate even the best organizations’ defenses. The next line of defense is sound judgment on the part of every worker with an e-mail account. Organizations implementing new security strategies often do so to improve their defenses; it makes sense, then, to include a review and perhaps an upgrade in security awareness training for all personnel. Some of the new features available in security awareness training include the following:

• Engaging, multimedia content Rather than just text on a screen, audio and video content, including playback of computer sessions, will better hold viewers’ attention, ensuring they will retain content.

• Opportunities to learn and practice skills Better training programs, even online varieties, provide opportunities to practice skills such as creating strong passwords, spotting phishing messages, and understanding how to recognize other threats.

• Quizzes at the end of each topic Short quizzes throughout training sessions hold a viewer’s interest and keep them engaged. Better training programs don’t let a participant proceed until previous learning has been proven.

• Built-in acknowledgment of organization security policy Online and in-person awareness training can incorporate acknowledgment of security policy. This helps raise awareness of corporate security policy and its content, as well as driving the point that all staff members are expected to comply with it.

• A permanent record of quiz scores and completion Modern learning management systems (LMSs) keep a permanent record of test and quiz scores. This helps to reinforce the notion that an employer is holding staff members responsible for complying with policy.

When new technologies are introduced into the organization, often there are individuals and even entire teams that need to be trained so that they will better understand how to operate and maintain the new programs and products. Unfortunately, many organizations skimp on training, and this often results in organizations underutilizing new products or not using them correctly.

Developing a Business Case

Many organizations require the development of a business case prior to approving expenditures on significant security initiatives. A business case is a written statement that describes the initiative and describes its business benefits. The typical elements found in a business case include the following:

• Problem statement This is a description of the business condition or situation that the initiative is designed to solve. The condition may be a matter of compliance, a finding in a risk assessment, or a capability required by a customer, partner, supplier, or regulator.

• Current state This is a description of the existing conditions related to the initiative.

• Desired state This is a description of the future state of the relevant systems, processes, or staff.

• Success criteria These are the defined items that the program will be measured against.

• Requirements This is a list of required characteristics and components of the solution that will remedy the current state and bring about the desired future state.

• Approach This is a description of the proposed steps that will result in the desired future state. This section may include alternative approaches that were considered, with reasons why they were not selected. If the initiative requires the purchase of products or professional services, business cases may include proposals from vendors. Alternatively, the business case may include a request for proposal (RFP) or request for information (RFI) that will be sent to selected vendors for additional information.

• Plan This will include costs, timelines, milestones, vendors, and staff associated with the initiative.

Mature organizations utilize an executive steering committee that evaluates business cases for proposed initiatives and makes go/no-go decisions for initiatives. Business cases are often presented to a steering committee in the form of an interactive discussion, providing business leaders with the opportunity to ask questions and propose alternative approaches.

Characteristics of business cases should include the following:

• Alignment with organization The business case should align with the organization’s goals and objectives, risk appetite, and culture.

• Statements in business terms Problem statements, current state, and future state descriptions should all be expressed in business terms.

Establishing Communications and Reporting

Effective communications and reporting are a critical element of a successful security program. Because success depends mainly on people, in the absence of effective communications, they won’t have the required information to make good security-related decisions. Without regard for information security, the results of decisions may include harmful incidents.

These are common forms of communications and reporting that are related to information security:

• Board of directors meetings Discussions of strategies, objectives, risks, incidents, and industry developments keep board members informed about security in the organization and elsewhere.

• Governance and steering committee meetings Discussions of security strategies, objectives, assessments, risks, incidents, and developments guide decision-makers as they discuss strategies, objectives, projects, and operations.

• Security awareness Periodic communications to all personnel help keep them informed on changes in security policy and standards, good security practices, and risks they may encounter, such as phishing and social engineering attacks. New hires often get a healthy dose of security-related information that includes current security policies and practices, acceptable use, security tools, and where to go for help.

• Security advisories Communications on potential threats helps keep affected personnel aware of developments that may require them to take steps to protect the organization from harm.

• Security incidents Communications internally as well as with external parties during an incident keep incident responders and other parties informed. Organizations typically develop security incident plans and playbooks in advance, which include business rules on internal communications as well as with outside parties, including customers, regulators, and law enforcement.

• Metrics Key metrics are reported upward in an organization, keeping management, executives, and board members informed as to the effectiveness and progress in the organization’s security program.

When building or expanding a security program, it’s best to utilize existing communications channels and add relevant security content to those channels, as opposed to building new, parallel channels. An effective security program makes the best use of existing processes, channels, and methods in an organization.

Obtaining Management Commitment

The execution of a security strategy requires management commitment. Without that commitment, the security strategist will be unable to obtain funding and other resources to implement the strategy.

Getting management commitment is not always straightforward. Often, executives and board members are unaware of their fiduciary responsibilities as well as the potency of modern threats. Many organizations mistakenly believe they are an unlikely target of hackers and cyber-criminal organizations because they are small or uninteresting. Further, the common perception of executives and senior managers is that information security is a tactical problem solved with “firewalls and antivirus software” and that information security is in no way related to business issues and business strategy.

A security strategist in a situation where top management lacks a strategic understanding about security will need to embark on efforts to inform top management on one or more aspects of modern information security management. When success is elusive, it may be necessary to bring in outside experts to convince executives that their security manager is not attempting to build a kingdom but instead is just trying to build a basic program to keep the organization out of trouble. As part of developing an effective communication approach, the security strategist should not use fear, uncertainty, and doubt (FUD) in an attempt to move the leadership team toward adopting the strategy. The better approach, as noted in this section, is to relate it to the leadership team in business terms and as opportunities to improve business functions.

Normalcy Bias

People at all levels can suffer from normalcy bias, a pattern of thinking in which people believe that because a disaster or breach has never occurred, it will never occur. Normalcy bias manifests itself in many situations, the common theme being a general lack of preparedness for disastrous events. This may be part of the reason that organizations do not take information security seriously—because they have never had a breach before. Experienced information security professionals understand that an organization claiming to have not suffered from security breaches in the past may simply be unaware of them because of a lack of visibility into events in their environment. A common saying in the information security profession is, “There are two types of organizations: those that have been breached and those that do not yet realize they have been breached.”

Strategy Constraints

While the development of a new security strategy may bring hope and optimism to the security team, there is no guarantee that changes in an organization can be implemented without friction and even opposition. Instead, there are many constraints and obstacles that the security manager should anticipate and be prepared to maneuver around, over, or through.

No security manager plans to fail. However, the failure to anticipate obstacles and constraints may result in the failure to execute even the best strategy. The presence of an excellent strategy, even with executive support, does not mean that obstacles and constraints will simply get out of the way. Instead, obstacles and constraints represent the realities of human behavior, as well as structural and operational realities that may present challenges to the security manager and the organization as a whole. There is apt meaning to the phrase “the devil’s in the details.”

Typical constraints, obstacles, and other issues are discussed in this section.

Basic Resistance to Change

It is our basic human nature to be suspicious of change, particularly when we as individuals have no control over it and have no say about it. Change is bad, or so we tend to think.

For this reason, organizations need to consider methods of involving management and staff members about anticipated changes, such as town-hall meetings, surveys, and cross-functional committees. Organizations are cautioned to ensure these efforts are not merely window dressing but serious efforts to better understand staff points of view.

Culture

Organizational culture, according to the Business Dictionary (www.businessdictionary.com), is the collection of values and behaviors that “contribute to the unique social and psychological environment of an organization.” In other words, it’s the way that people think and act in an organization and how people feel as employees.

Aspects of organizational culture that are important for the security strategist to understand include the following:

• Strong culture The culture reflects and aligns with stated organizational values. Personnel understand and support organizational goals and objectives and need little prodding to figure out how to be productive and provide value to the organization and its constituents.

• Weak culture The culture is not well-aligned with the organization. As a result, management must spend more time managing staff who are not motivated and feel micromanaged.

• Culture of fear Workers are distrustful of management who act as tyrants, resulting in pervasive feelings of fear and doubt.

• Healthy culture Workers and management value and respect each other, have a strong sense of accountability, and cooperate to be successful and accomplish organizational goals and objectives.

One might consider organizational culture as the collective consciousness of all workers, regardless of rank. The security strategist should not expect to significantly change the culture but instead should work with the culture when developing and executing the information security strategy.

Organizational Structure

The security strategist must understand the organization’s command-and-control structure, which is often reflected by the organizational chart. However, there may be an undocumented aspect to the org chart, which is actually more important: who is responsible for what activities, functions, and assets. In other words, security strategists must understand “who owns what turf” and develop collaborative relationships with those individuals and groups if they want the strategy to be successful.

Like other considerations in a security strategy, alignment with written and unwritten organizational structures is key to success.

Staff Capabilities

A security strategy generally represents the introduction of new capabilities, as well as changes or upgrades to existing capabilities. A strategy cannot be expected to succeed if the new or changed capabilities do not align with what staff members are able to do. A gap analysis to understand the present state of the organization’s security program (discussed earlier in this chapter) needs to include staff knowledge, skills, and capabilities. Where gaps are found, the strategy needs to include training or other activities to impart the necessary skills and language to staff.

This is not limited to technical workers who design, build, and manage information systems and application. To the extent that all staff members are impacted by some change introduced by the strategy, those staff members need to be informed or trained so that they too will be successful.

For example, an organization that needs to better protect its sensitive data includes the development of a data protection program in its strategy. The strategy for data protection includes the development of a data classification scheme with data-handling policies and procedures for data at each classification level and in each use case. This is a high-impact endeavor that will require that many, if not all, workers in the organization be trained in data classification and handling procedures. If there are new security systems in place that augment manual tasks, personnel will need to be trained in the use of those tools as well.

When an organization lacks staff with specific knowledge on security techniques or tools, organizations may look to external resources to augment internal staff. The security strategist needs to consider the costs and availability of with these resources. Consultants and contracts in many skill areas are difficult to find; even larger firms may have backlogs of several months as a result.

Budget and Cost

A security strategy is a statement of changes to take place in the organization to better protect critical or sensitive information and systems. These changes will have hard and soft costs associated with them that represent expenditures for hardware, software, and cloud services, as well as consultants, contractors, and the value of existing workers’ time.

The security strategist must determine, with a high degree of precision, all of the hard and soft costs associated with each element of a strategy. Often, executive management will want to see alternative approaches; for example, if additional labor is required, the security strategist may want to determine the costs of hiring additional personnel versus the retention of consultants or contractors.

Every organization has a core business to run, with budgeted costs for all associated activities. A security strategy almost always represents added costs, which must also be funded. While it is possible to obtain out-of-budget money for unbudgeted activities, usually it is necessary to take security strategy initiatives and attempt to get those activities budgeted in future fiscal cycles. For initiatives in future budget cycles, the security strategist needs to determine the price increases that may occur that will impact the strategy. A key project that will cost $100,000 this year may cost $105,000 to $110,000 a year from now and be even more expensive in future years.

Time

As security strategies take shape, each initiative will have its own project plan with associated timelines for executing various tasks. Realistic project planning is needed so that everyone will know when project and strategy milestones will be completed. Project and strategy timelines need to take into account all business circumstances, including peak period and holiday production freezes (where IT systems are maintained in a more stable state), external events such as regulatory audits, and other significant events that may impact schedules.

Time constraints may also involve legal and regulatory obligations, discussed next.

Legal and Regulatory Obligations

An organization may be including items in its strategy that may represent business capabilities that are required to exist for legal or regulatory reasons. For example, a public company may be compelled to complete a key identity and access management project before its next public audit cycle begins to ensure a favorable audit outcome. In another example, an organization may be undertaking implementation of an intrusion prevention system (IPS) to meet a contractual obligation with a customer that has a hard deadline. In a final example, an organization may be implementing a web application firewall (WAF) in order to maintain its PCI-DSS compliance.

As seen in these examples, legal and regulatory obligations often have time components. New laws and contracts require organizations to have specific capabilities in place by established deadlines. For organizations that have failed to meet a deadline, the obligation still exists, and its completion has a greater sense of urgency.

Legal and regulatory requirements often have international considerations. What is legal and required in one country may be forbidden in another. For instance, an international organization may have, as a part of its strategy, key improvements in its pre-employment and post-employment background checks. The organization needs to understand that some countries such as the United States are quite permissive with background checks, while other countries such as France do not permit background checks for most positions. In another example, a security project that is improving its endpoint protection capabilities with cloud-based web proxy filters will find that users’ Internet access activities may not be observed or logged in some countries.

Acceptable Risk

A security strategist who develops an information security policy needs to be familiar with the organization’s current risk appetite or threshold for acceptable risk.

Risk is, by its nature, difficult to quantify. Most organizations, then, have a cultural “feel” for risk appetite that may or may not be documented. The security strategist must be familiar with the organization’s risk appetite, in whatever formal or informal sense, and keenly understand two important aspects of the strategy:

• Its alignment with risk appetite Initiatives in the security strategy need to align with executive management’s risk appetite. For example, implementation of a data loss prevention (DLP) system together with restricting the use of USB-attached external storage may help to better protect data but may be seen as excessive in some organizations. A common mistake made by security strategists is the incorporation into strategies of new capabilities that may not be urgently needed. This can happen, especially if a strategy is developed without soliciting input from key stakeholders in the organization.

• Its impact on risk appetite Specific initiatives within the security strategy may, by design, “push the envelope.” A typical organization’s security strategy probably contains initiatives that improve security capabilities that better align capabilities with risk appetite. But because many organizations are deficient in their security practices, the perception is that the organization is becoming less tolerant of risk, when in fact it’s just trying to get its practices into alignment with its risk tolerance. The appearance of lowering risk appetite may more of a “catchup.”

The Obstacle of Organizational Inertia

Every organization has a finite capacity to undergo change. This is a fact that is often overlooked by overly ambitious security strategists who want to accomplish a great deal in too short a time. I have coined the term organizational inertia to represent an analogy to Newton’s laws of motion: an object either remains at rest or continues to move at a constant velocity, unless acted upon by a force. In an organization, this means that things will be done in the same way until change is exerted upon the organization to change what is done or how things are done.

The nature of organizational inertia, or its resistance to change, is threefold:

• Operational people performing change For an organization to make major changes, some of the people making the change are the same people who perform the work. Because business processes undergoing change must continue operation, changes must be enacted slowly and carefully so that operational and quality levels are not adversely affected.

• Learning curve Any time there is significant change to a system or process, affected personnel need to learn the new systems, processes, or procedures. This involves a learning curve and possibly training that will take them offline for hours or even days.

• Human resistance to change Left alone, people have a tendency to want to do things the same way, even if new and better ways are developed. People, particularly when they have no influence, tend to resist change, which makes adoption take longer.

Chapter Review

Information security governance is the top-down management and control of security and risk management in an organization. Governance is usually undertaken through a steering committee that consists of executives from throughout the organization. The steering committee is responsible for setting overall strategic direction and policy, ensuring that security strategy is in alignment with the organization’s IT and business strategy and objectives. The wishes of the steering committee are carried out through projects and tasks that steer the security organization toward strategic objectives. The steering committee can monitor progress through metrics and a balanced scorecard.

For an information security program to be successful, it must align with the business and its overall mission, goals and objectives, and strategy. The security program must take into account the organization’s notion of asset value, culture, risk tolerance/appetite, legal obligations, and market conditions. A successful and aligned security program does not lead the organization but enables and supports it as it carries out its mission and pursues its goals.

Risk appetite is the level of risk that an organization is willing to accept while in the pursuit of its mission, strategy, and objectives. Risk treatment and risk acceptance decisions should be assigned to and made by associated business owners and executives who are accountable for those decisions. The chief information security officer is there to facilitate and communicate the information and only in specific instances will own a risk item.

Security governance is accomplished using the same means as IT governance: it begins with board-level involvement that sets the tone for risk appetite and is carried out through the chief information security officer, who develops security and privacy policies, as well as strategic security programs, including software assurance, change management, vendor management, configuration management, incident management, vulnerability management, security awareness training, and identity and access management.

Security governance is used to establish roles and responsibilities for security-related activities throughout all layers of the organization, from the board of directors to individual staff. Roles and responsibilities are defined in job description, in policy and process documents, and in RACI charts.

The board of directors in the defined team is responsible for overseeing all activities in an organization. Boards select and manage a chief executive officer who is responsible for developing a governance function to manage assets, budgets, personnel, processes, and risk.

The security steering committee is responsible for security strategic planning. The security steering committee will develop and approve security policies and appoint managers to develop and maintain processes, procedures, and standards, all of which should align with each other and with the organization’s overall mission, strategy, goals, and objectives.

The chief information security officer develops business-aligned security strategies that support the organization’s overall mission and goals and is responsible for the organization’s overall security program, including policy development, risk management, and perhaps some operational activities such as vulnerability management, incident management, access management, and security awareness training. In some organizations, the topmost security executive has a title of chief security officer or chief information risk officer.

The chief privacy officer is responsible for the protection and proper use of sensitive personal information (often referred to as personally identifiable information). The CPO’s information protection responsibilities are sometimes shared with the CISO who has overall information protection responsibilities.

Virtually all other roles in IT have security responsibilities, including software development and integration, data management, network management, systems management, operations, service desk, internal audit, and all staff members.

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

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

The business model for information security, developed by ISACA, is a guide for business-aligned, risk-based security governance. BMIS consists of four elements: organization, people, process, and technology. It consists of six dynamic interconnections: culture (connecting organization and people elements), governing (connecting organization and process elements), architecture (connecting organization and technology elements), emergence (connecting people and process elements), enabling and support (connecting process and technology elements), human factors (connecting people and technology elements). BMIS helps the strategist understand the dynamics between the four elements and how they may be manifested. The key takeaway from BMIS is that everything is connected to everything else.

A strategy is a plan to achieve a defined set of objectives to enable the vision of the organization to be successfully achieved. Objectives are the desired future states in an organization and, in the context of information security, in the organization’s information security program. A strategy should be business-aligned, deliver value, optimize resources, and be measurable.

The development of an overall security strategy includes the adoption of or alignment with a control framework. Most organizations select an industry-standard control framework such as COBIT, NIST 800-53, ISO/IEC 27001, HIPAA, or PCI-DSS. Then, as part of the organization’s risk management processes, additional controls are added as identified risks warrant.

Strategy development may include establishing desired risk levels. This may be expressed in qualitative or quantitative terms, depending upon an organization’s maturity.

Many resources are needed for the development of a strategy. These resource include several types of information that reveal the current state of the organization, including risk assessments, vulnerability assessments, business impact analysis, metrics, risk ledger, and incident log. Several other inputs are required that define the structure of the security program, including policy, standards, guidelines, processes and procedures, insurance, and outsourced services.

To develop a strategy, the security strategist first must understand the organization’s present state and then define one or more desired future states. A gap analysis helps the strategist understand missing capabilities. The development of a road map defines the steps to develop missing capabilities and augment existing capabilities so that the strategy will be realized.

The security strategist may choose to use the strengths, weaknesses, opportunities, threats (SWOT) analysis model in support of strategy planning. The strategist may also employ capability maturity models to help determine appropriate future states of key security processes.

Often it is necessary to build a business case so that executive management will agree to support and fund a strategy. A business case typically includes a problem statement, followed by a description of the current state, the desired future state, requirements, an approach, and a plan to achieve the strategy. Often a business case is reviewed by a business or IT steering committee consisting of business stakeholders.

A security strategist must be aware of potential obstacles to achieving strategic objectives, including culture, organizational structure, existing staff capabilities, budgets, time, and legal and regulatory obligations. A business-aligned strategy should take these obstacles into account and minimize them if the strategy is to be approved and achieved.

Notes

• The addition of information security as part of fiduciary duty by board members and executives is an important and growing trend in business today.

• Security executives and the board of directors are responsible for implementing a security governance model encompassing information security strategy and mandates. As such, the industry is seeing a shift from a passive to a more active board when it comes to cybersecurity issues.

• A security program should be in alignment with the organization’s overall mission, goals, and objectives. This means that the chief information security officer and others should be aware of, and involved in, strategic initiatives and the execution of the organization’s strategic goals.

• Risk appetite is generally expressed in qualitative terms such as “very low tolerance for risk” and “no tolerance for risk.” Different activities in an organization will have differing risk appetites.

• An organization’s definitions of roles and responsibilities may or may not be in sync with its culture of accountability. For instance, an organization may have clear definitions of responsibilities documented in policy and process documents and yet may rarely hold individuals accountable when preventable security events occur.

• Ideally, an organization’s board of directors will be aware of information security risks and may direct that the organization enact safeguards to protect the organization. However, in many organizations the board of directors is still uninvolved in information security matters; in these cases, it is still possible to have a successful risk-based information security program, provided it is supported by senior executives.

• While the use of security steering committees is not required, organizations find it helpful to implement single-level or multilevel security steering groups as a cross-functional vehicle for discovering security risks and disseminating security organization.

• Information security is the responsibility of every person in an organization; however, the means for assigning and monitoring security responsibilities to individuals and groups varies widely.

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

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

• Security managers developing an information security strategy in an organization without a program will need to rely on their past experiences, anecdotal accounts of practices, and policies in the organization.

• Security strategists should be mindful of each organization’s tolerance for change within a given period of time. While much progress may be warranted, the amount of change that can be reasonably implemented within a year’s time is limited.

• The business model for information security is a useful model for understanding the qualitative relationships among various aspects of an organization, as well as the types of activities that relate to these aspects.

• Many organizations ruminate over the selection of a control framework. Instead, the organization should select a framework and then make adjustments to its controls to suit the business. A control framework should generally be considered a starting point, not a rigid and unchanging list of controls—except in cases where regulations stipulate that controls may not be changed.

• While it is important for the security strategist to understand the present state of the organization when developing a strategic road map, the strategist must proceed, knowing that there can never be a sufficient level of understanding. Besides, if even the most thorough snapshot has been taken, the organization is slowly (or perhaps quickly) changing anyway. Execution of a strategic plan is to accelerate changes in certain aspects of an organization that is slowly changing anyway.

• Capability maturity models are useful tools for understanding the maturity level of a process and developing desired future states. The maturity of processes in the organization will vary, as it is appropriate for some processes to have high maturity while it is acceptable for others to have lower maturity. The right question to ask about each separate process is, what is the appropriate level of maturity for this process?

• Each organization has its own practice for the development of business cases for the presentation, discussion, and approval for strategic initiatives.

• A security strategist must anticipate obstacles and constraints affecting the achievement of strategic objectives and consider refining those objectives so that they can be realized.

Questions

1. Security governance is most concerned with:

A. Security policy

B. IT policy

C. Security strategy

D. Security executive compensation

2. A gaming software startup company does not employ penetration testing of its software. This is an example of:

A. High tolerance of risk

B. Noncompliance

C. Irresponsibility

D. Outsourcing

3. An organization’s board of directors wants to see quarterly metrics on risk reduction. What would be the best metric for this purpose?

A. Number of firewall rules triggered

B. Viruses blocked by antivirus programs

C. Packets dropped by the firewall

D. Time to patch vulnerabilities on critical servers

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

A. Average time to mitigate security incidents

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

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

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

5. What are the elements of the business model for information security (BMIS)?

A. Culture, governing, architecture, emergence, enabling and support, human factors

B. People, process, technology

C. Organization, people, process, technology

D. Financial, customer, internal processes, innovation, and learning

6. The best definition of a strategy is:

A. The objective to achieve a plan

B. The plan to achieve an objective

C. The plan to achieve business alignment

D. The plan to reduce risk

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

A. Industry vertical

B. Current process maturity level

C. Size of the organization

D. Compliance level

8. As part of understanding the organization’s current state, a security strategist is examining the organization’s security policy. What does the policy tell the strategist?

A. The level of management commitment to security

B. The compliance level of the organization

C. The maturity level of the organization

D. None of these

9. While gathering and examining various security-related business records, the security manager has determined that the organization has no security incident log. What conclusion can the security manager make from this?

A. The organization does not have security incident detection capabilities.

B. The organization has not yet experienced a security incident.

C. The organization is recording security incidents in its risk register.

D. The organization has effective preventive and detective controls.

10. The purpose of a balanced scorecard is to:

A. Measure the efficiency of a security organization

B. Evaluate the performance of individual employees

C. Benchmark a process in the organization against peer organizations

D. Measure organizational performance and effectiveness against strategic goals

11. A security strategist has examined a business process and has determined that personnel who perform the process do so consistently, but there is no written process document. The maturity level of this process is:

A. Initial

B. Repeatable

C. Defined

D. Managed

12. A security strategist has examined several business processes and has found that their individual maturity levels range from Repeatable to Optimizing. What is the best future state for these business processes?

A. All processes should be changed to Repeatable.

B. All processes should be changed to Optimizing.

C. There is insufficient information to determine the desired end states of these processes.

D. Processes that are Repeatable should be changed to Defined.

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

A. Adopt ISO 27001 as the new control framework.

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

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

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

14. A security strategist is seeking to improve the security program in an organization with a strong but casual culture. What is the best approach here?

A. Conduct focus groups to discuss possible avenues of approach.

B. Enact new detective controls to identify personnel who are violating policy.

C. Implement security awareness training that emphasizes new required behavior.

D. Lock users out of their accounts until they agree to be compliant.

15. A security strategist recently joined a retail organization that operates with slim profit margins and has discovered that the organization lacks several important security capabilities. What is the best strategy here?

A. Insist that management support an aggressive program to quickly improve the program.

B. Develop a risk ledger that highlights all identified risks.

C. Recommend that the biggest risks be avoided.

D. Develop a risk-based strategy that implements changes slowly over an extended period of time.

Answers

1. C. Security governance is the mechanism through which security strategy is established, controlled, and monitored. Long-term and other strategic decisions are made in the context of security governance.

2. A. A software startup in an industry like gaming is going to be highly tolerant of risk: time to market and signing up new customers will be its primary objectives. As the organization achieves viability, other priorities such as security will be introduced.

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

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

5. C. The elements of BMIS are organization, people, process, and technology. The dynamic interconnections (DIs) are culture, governing, architecture, emergence, enabling and support, and human factors.

6. B. A strategy is the plan to achieve an objective. An objective is the “what” that an organization wants to achieve, and a strategy is the “how” the objective will be achieved.

7. A. The most important factor influencing a decision of selecting a control framework are the industry vertical. For example, a healthcare organization would likely select HIPAA as its primary control framework, whereas a retail organization might select PCI-DSS.

8. D. By itself, security policy tells someone little about an organization’s security practices. An organization’s policy is only a collection of statements; without examining business processes, business records, and interviewing personnel, a security professional cannot develop any conclusions about an organization’s security practices.

9. A. An organization that does not have a security incident log probably lacks the capability to detect and respond to an incident. It is not reasonable to assume that the organization has had no security incidents since minor incidents occur with regularity. Claiming that the organization has effective controls is unreasonable, as it is understood that incidents occur even when effective controls are in place (because not all types of incidents can reasonably be prevented).

10. D. The balanced scorecard is a tool that is used to quantify the performance of an organization against strategic objectives. The focus of a balanced scorecard is financial, customer, internal processes, and innovation/learning.

11. B. A process that is performed consistently but is undocumented is generally considered to be Repeatable.

12. C. There are no rules that specify that the maturity levels of different processes need to be the same or at different values relative to one another. In this example, each process may already be at an appropriate level, based on risk appetite, risk levels, and other considerations.

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

14. A. Organizational culture is powerful, as it reflects how people think and work. In this example, there is no mention that the strong culture is bad, only that it is casual. Punishing people for their behavior may cause resentment, a revolt, or people to leave the organization. The best approach here is to better understand the culture and to work with people in the organization to figure out how a culture of security can be introduced successfully.

15. D. A security strategist needs to understand an organization’s capacity to spend its way to lower risk. In an organization with profit margins, it is unlikely that the organization is going to agree to an aggressive improvement plan. Developing a risk ledger that depicts these risks may be a helpful tool for communicating risk, but by itself there is no action to change anything. Similarly, recommending risk avoidance may mean discontinuing the very operations that bring in revenue.