4

Guidance for Decision Makers

4.1 Tone at the Top

Chapter 3 made a brief comparison between the accounting profession and the cyber security profession. One reason why this comparison is informative is because many of today’s information security controls were first established as standards by the Electronic Data Processing Auditor’s Association (EDPAA, now the Information Systems Audit and Control Association, ISACA) (Bayuk 2005). A key take away from that comparison is that the accounting profession’s mantra concerning the integrity of financial management applies across the board to cyber security management. That is: “the tone is set at the top” (COSO 2009). Management tone in any endeavor exists whether policy is formally established or not, and management tone is not the same as formal policy establishment. In the domain of cyber security, policy is a documented enterprise agreement on cyber security goals and objectives, and tone is the level of commitment that management has toward that documented policy and corresponding enforcement measures.

There is no single right way for a decision maker to make sure people are really understanding and following cyber security policy. But consciously or unconsciously, every good leader has a method of getting important messages across (Bayuk 2010). For example, one manager will make it a practice to always be at the same level of calm in order to get maximum value out of showing emotion with respect to an important issue. Another will work at a brisk pace, but slow down when explaining something they think is really important. The way a manager behaves toward issues of importance to cyber security policy will set the tone for the enterprise.

The day-to-day decisions made by middle and lower-level managers to facilitate their own business occasionally have unintended consequences on an organization’s overall cyber security posture and require a timely response. Singular policies that seem necessary to adopt in the context of a security crisis may also be inconsistent with an enterprise-level cyber security strategy. Adjustments in both strategy and policy must be customized to the evolving requirements of the organization, which means cumulatively they point to where formal policy should evolve.

For example, it is often the case that responsibility for cyber security policy is set within a low-level information technology department. In many organizations, cyber security planning is seen as a technology risk management function. Although cyber security strategy should be designed to minimize risk, it is not only technology risks that may be minimized with adequate cyber security, but business risks as well. In order to be effective, cyber security strategy must be a mainstream part of business, system, or mission planning, not a subcomponent of a technology-only function. For example, it is not uncommon for a technology department that has no set security strategy to set unreasonably hard standards for user-selected passwords, while sharing administrative passwords among themselves via email. Cyber security in this case would be disruptive to business and at the same time provide poor protection against a determined hacker.

It takes time to craft policy to make sure it is not disruptive to business and interim steps to reduce risk do not always qualify as long-term solutions. A decision maker will often count on an information security professional to shepherd cyber security policy (e.g., a Chief Information Security Officer, or “CISO”), ensuring it remains effective and relevant. If it is not relevant, the void will doubtless be filled with what some security professionals call “security theater.”

Security theater is created when security concerns within the business prompt action, but the action is more visible than effective. This is because people think something needs to be done about security, so they create activity that looks like security where they think people want security to be in place (Schneier 2003). Security theater does not actually prevent anything bad from happening. It just creates the illusion that security is in place. For example, in a building that has experienced a recent rash of thefts, a guard is installed behind a desk in the lobby of a building, and told to ask for identification, but anyone with any kind of laminated card with a name and photo on it can get in. Though it seems like a good return on investment, because it “solves” the security problem, the value here is questionable. Compare it to a true security control designed for the same situation. For example, those authorized to access the building are prescreened for criminal records, have photos taken, and are issued a badge that initiates activation of a floor-to-ceiling turnstile that permits entry into the building. The card has electronic identification on it that is used to check a database for a picture of the person to whom the card had been issued. The guard checks the picture against the person using the card. The turnstile activation is completed by the guard’s active acknowledgement that the photo matches the person attempting entry. A similar procedure is used for internal building doors and building exits. True security controls, such as this one, provide measurable value. In this case, the value is the knowledge of exactly who is in what area of the building at what time.

A common approach to ad hoc security theater is to make it apparent that cyber security policy affects technology usability. Make it harder for people to get into the network, to get to their data, to use applications, and so on. Security is somehow perceived as equivalent to cumbersome levels of approval, and authorization workflows present obstacles to gaining cyber access. Often, it is thought that more security control means less cyberspace usability. But it is also true that usability of technology may be strengthened by security policy that supports productive use cases. Once cyber security policy is well understood, it can be appreciated as a shining light with which to illuminate strategy, and to evaluate alternative courses of action to achieve cyber security goals, the majority of which should not require red tape. Policies that constrain rather than guide result in work-arounds rather than work-withins.

True security and security theater may have the same requirements, for example, to hire guards and subject people to authorization processes. The difference between security and security theater is that in the first case, the process behind the authorization is designed for an outcome wherein unauthorized individuals are kept out, and in the second case, the process behind the authorization is more for show and the outcome is random. Of course, any specific decision on how important it is to authorize access as well as to know what people are where should differ depending on the risk to the enterprise. While it is advisable to make risk-based judgments, these should be consistent with a defined policy. It is not unusual for the same company to have inconsistent security measures in two buildings of similar function, wherein one building sports effective security measures, while the other displays security theater. The same people may sheepishly follow both processes, but this does not mean they are blind to the difference. This makes security policy throughout the entire organization seem like a joke, something that is detrimental to management’s credibility. Security theater is a symptom of an ad hoc security strategy. Development of a well-structured, formal security policy exposes the holes in existing strategy and that paves the way to true security.

4.2 Policy as a Project

As described in Chapter 1, cyber security easily lends itself to a Drucker-style management cycle for managing by objectives and self-control, observing and revising plans based on observations (Drucker 2001). The management style also follows military security recommendations for managing battle-action: observe the situation, orient observations based on background knowledge and analysis, decide on a course of action, act, and observe the impact of actions on the situation (Boyd 1987). These activities, in combination, comprise the management cycle of an enterprise security program. Where cyber security is managed as a program, the program structure provides organization, strategy, and operational process to maintain activities in support of cyber security. Where security is viewed as part of, or integrated with, other business or mission goals, it becomes evident that the strategy to achieve security objectives cannot be a stand-alone project, but must be part of a larger program. Within an enterprise management structure, the cyber security program will be a set of interrelated discrete projects and combined with processes managed in a coordinated way to obtain benefits and control not available from managing them individually (PMI 2008).

The process by which cyber security policy is established is a part of that program. As with any important initiative, the establishment of cyber security policy requires task definition, planning, and clear objectives. That is, to create cyber security policy is a project, and should be managed as one. As with any project, cyber security policy creation starts with goals and objectives. It is also helpful to begin with the recognition that policy follows business or enterprise strategy, not the reverse. Figure 4.1 is a more prescriptive and direct version of the security management life cycle presented in Chapter 1. It shows that cyber security management starts with strategy designed to achieve cyber security goals and objectives consistent with enterprise objectives. Policy is an extremely important component of strategy execution because it is used to communicate desired outcomes. Even if an executive issues only one policy statement, that statement will be interpreted in the context of other plans, objectives, and operational environments that complete an organization’s cyber security posture. Clear documentation of desired outcomes is a critical element of enterprise communication and is required for awareness activities that motivate members from executives to first-level employees of the organization to achieve security goals. Progress in goal achievement should be monitored, and gaps in policy compliance or difficulties in following strategy should be corrected if possible, and if there is too much difficulty in complying with policy, that fact should be captured in a management feedback loop.

Figure 4.1 Security cycle.

Given that business, system, and/or mission risk management should drive cyber security strategy and corresponding policy, articulating the risks presented by threats to business, system, and/or mission cyberspace is a good way to begin a cyber security policy project. Though the description of these risks may not be included in the final policy document, it is helpful in creating awareness among stakeholders of why the policy has been deemed necessary. The articulated risks also provide a sanity check against the resulting policy. The policy should be focused on reducing cyber security risk rather than on any externally set goals such as compliance with industry best practices. Such a sanity check should be a formal milestone in the policy project. Figure 4.2 is typical gant chart for a cyber security policy project.

Figure 4.2 Gant chart.

4.3 Cyber Security Management

Many companies have established a Chief Security Office or Chief Information Security Office. However, those offices generally do not have line authority over operations that are critical to asset preservation and other security goals. These offices generally are skilled in the tools and techniques necessary to enforce security policy, but often do not have the understanding of business or mission that would be required to establish one. This observation is not meant to belittle the role of security professionals; they simply are not as intimate with the daily workflow of each business unit as are their leaders. Also, many security professionals were trained in industries that were early security adopters such as military or finance. It would be unreasonable to expect someone who spent 20 years in one industry to know what business processes should take priority in a completely different one. This is also true of Chief Financial Officers or Human Resources Officers. Though many skills are transferrable, there is always an industry learning curve.

Hence, the team an executive needs to determine security policy is the same team convened to create other important strategic objectives. It should include the Chief Operations Officer or equivalent. It may include business leaders and/or trusted advisors from any area of the enterprise. Of course, if there is a high-ranking individual whose sole job is security, then that person will undoubtedly be a good sounding board when discussing the potential efficacy of a suggested policy, whether or not they are also well versed in the business.

4.3.1 Arriving at Goals

To begin the process of developing cyber security policy, executives may ask themselves:

• What assets need to be in place to maintain operations? Which are the “crown jewels?” Are these changing and/or evolving with our long-term business plans?
• What cyberspace infrastructure houses or impacts our most critical assets?
• Do we have any information that should be kept from general circulation? If so:
  • What criteria would we use to release it to someone within the organization?
  • What criteria would we use to release it to someone outside the organization?
  • If someone with access to it left the organization, should it still be protected?
• Do we participate in socio-technical networks with communities who are hostile to our interests? Are we subject to cyber threats simply from being a bystander within a larger community?

Once these general environmental aspects of the cyber security environment within the enterprise are understood, more detailed questions can be probed with the help of a cyber security task force composed of operations, financial, and technology staff. Such questions may be found in industry standard literature. For example (ANSI and ISA 2010):

• Have we analyzed our cyber liabilities? What legal rules apply to the information that we maintain or that is kept by vendors, partners, and other third parties? What laws apply in different states and countries in which we conduct business?
• Have we assessed our exposure to suits by our customers and suppliers? Have we protected our company in contracts with vendors?
• What is our biggest single vulnerability from a technology or security point of view? How vulnerable are we to attack on the confidentiality, integrity, and availability of our data and systems? How often are we re-evaluating our technical exposures?
• If our system goes down, how long until we are back up and running, and are there circumstances where we do not want to be back up quickly? How prepared are our business continuity plans? What is our risk exposure of technology or business operation failures at our vendors and service providers?
• Do we fully understand the overall financial impact of mishandling communications with our key stakeholders following a cyber security event? Have we budgeted for a cyber security event?
• Do we have a documented, proactive crisis communications plan? Have we identified and trained all the internal resources required to execute the communications plan? Do we have contacts at specialist crisis communications firms if we need their services? In the case of a cyber security event involving personally identifiable information (PII), do we have a system in place to quickly determine who should be notified, and how?
• Have we evaluated the appropriate communication responses to our key stakeholders? Do we have a template timeline for executing the communications plan? Have we considered that, depending on the situation, we may need to craft different messages for different types or levels of clients or employees?
• How do we attract, acclimate, invest in, and engage critical cyber security technical and leadership talent, including those in functional areas requiring cyber security savvy?

From these types of questions, an information classification system can be developed (e.g., customer info, financial info, and marketing info). The classification should be as granular as the corresponding business processes. It may be possible to merge classifications into a hierarchical taxonomy, but in the initial effort, it is important not to miss any distinctions in the value of information that may be blurred by lumping similar-sounding business records into a single bucket.

The answers to questions such as those above should provide the foundation from which to articulate security goals. Because committees are often motivated by regulatory requirements, the temptation is to use regulation as the foundation for security strategy. We caution against starting with that approach. Everyone’s business process is different and regulations are not always concurrent with change in industry. A strategy to protect a business process should also protect regulatory-specified information, but the opposite is rarely true. By concentrating on a business process rather than regulatory requirements, it is likely that efficient and economical techniques will cover both. Once a cyber security policy serves the needs of the business, a simple internal audit should confirm that it also meets the needs of the regulators, or identify a gap that can be closed in a way compatible with the agreed-upon business security requirements.

Cyber security business or mission goals should be focused on how security can contribute to enterprise mission or purpose. Sample cyber security goals are:

• Make operations safe from hackers
• Make it extremely hard to steal information stored on physical assets without insider collaboration
• Always detect cyber-space-enabled asset fraud or theft.

Note that it is not reasonable to expect that cyber security goals are 100% achievable. They are simply guideposts and sanity checks meant to ensure that any cyber security strategy and policy established have some tangible value. They lay the foundation on which to specify the scope of system and process level security efforts. However, executives should not mistake progress in technology implementation of cyber security best practices for cyber security goal achievement. As discussed in Chapter 3, verification measures that cyber security technology is deployed provide a completely different information from validation measures that systems are safe from hackers. It is incumbent on the decision maker to understand the validation measures and contribute to an assessment of whether they have been achieved. Any cyber security program that does not make progress toward its goals is not achieving its objective. These security goals, in conjunction with asset and information inventory terminology, should be discussed in the context of business operations. There should be some agreement on a strategy appropriate for validating them.

Armed with tangible goals, a cyber security program can justify both its strategies and corresponding policy. Cyber security policy statements should be phrased in a language native to the same team of executive decision makers that set cyber security goals. For example, if customers are called clients in the business literature, the policy should use that term, or if telecommunications lines are called facilities in the business literature, that term should not be used to describe buildings. Sample cyber security policy statements based on the three sample goals above might be:

• Critical program information includes the software, systems configurations, documentation, and test generation methods for all business applications, and these include electronically enabled controls for mechanical equipment. The integrity of all critical program information shall be maintained.
• Physical access to all information assets shall be restricted to those required to operate them via job functions. Any physical device capable of storing information that is small enough to be portable shall be centrally encrypted with keys that do not leave the internal network.
• Where any asset is capable of being disbursed via online mechanisms, the software controlling the disbursement shall require end-to-end nonrepudiation using physical, geographical, and logical authentication, authorization, and robust delivery verification.

Note that a policy statement does not dictate how the situation described in its “shall” statements will be accomplished. As part of an overall strategy, the implementation mechanisms may be central or distributed among various stakeholders within the policy scope. The policy should be specific enough for its outcomes to be measureable, but general enough to allow for appropriate information handling procedures to be described at the business process level.

Nevertheless, it is important to compose an information security policy document so that the organizations within scope are unmistakably aware of the existence of well-defined objectives for security and an agreed-upon management approach for securing information. If there is debate over the content of the policy, the debate will continue through attempts to enforce it, with the consequence that the Information Security Program itself will be dysfunctional.

It is also true that cyber security policy statements that reflect a poor security posture do not stand alone. An executive may accept that the negative aspects of a given policy statement are more likely to occur than the positive ones, but may issue such a directive in the context of an overall strategy that provides compensating controls intended to shore an organization’s resiliency to the negative impact expected due to lack of security measures.

4.3.2 Cyber Security Documentation

As illustrated in Figure 4.1, policy awareness is a necessary step to complete after policy development and before implementation. If people are not aware of the decisions made in strategy and policy, then they will have no reason to implement in accordance with them. This is why security standards, operating procedures, and guidelines are also often issued in conjunction with policy to demonstrate how compliance with a given policy may be achieved. Though every organization draws the line between what types of directives are mandated policy and which are relegated to standards as they see fit, standards typically document the implementation details for specific technology platforms, while policy statements are reserved for higher-level management control objectives. There may be multiple, equally effective, methods of implementing policy within a technology platform and standards are generally adopted for economy and efficiency. They are often stated in the form of settings for technology configuration variables, that, when configured and combined with control activities such as procedures, will achieve policy compliance.

Procedures are documented step-by-step implementation instructions that a technician may follow in order to be successful in implementing policy and standards. They are used not only to guarantee a policy-compliant technical configuration, but also to train new technicians on the mechanics of configuring the technology. Procedures therefore must be written at a much lower level of detail than policies or standards, and they must fully explain how to operate technology.

Guidelines are the most general type of security document. They are designed to raise awareness among those who must comply with policy. They provide options for policy compliance. They do not dictate exactly how to comply or what must be done, but instead contain education and advice for individuals who must make daily choices about security as part of their job function.

Because security professionals like CISOs are often the people who document cyber security policy, it is important to understand that these are not necessarily the same set of people as the cyber security strategists. Cyber security specialists often act as trusted advisors to executive decision makers, but are not as well-versed on overall organizational mission as the executives who would be expected to create cyber security strategy. Cyber security specialists usually advise on matters of cyber security technology and implementation while leaving the organizational goals that form the basis of the policy to executive decision makers. Once an executive decision maker clearly articulates goals for cyber security, a cyber security specialist may be drafted to translate those goals into cyber security policy directives. As illustrated in the gant chart of Figure 4.2, these directives would then be reviewed, circulated among stakeholders, and refined by executive management. It is, after all, the executive who signs, and thereby owns responsibility for, the resulting cyber security policy, and its overall impact to the organization strategy and operating plan.

The Chief Security Officers today are similar to the Chief Information Officers (CIOs) in the 1990s. The title was new, and the function was not quite like technology advisors before them, cyber security advisors are a recent addition to the executive staffroom. They comprise a new specialist field because there is a significant requirement to address cyber security issues, but as yet no common understanding in the general public, nor even the general research community, as to what is meant generically by a cyber security. Like CIOs in the 1990s, their job is not well understood even by those who hired them. Their responsibilities change frequently, and their tenure is often short due to matters beyond their control. They will seek to establish standard ways in which to configure technology so that it can be easily verified to be policy-compliant. They will seek to supplement those standards with education and training for individuals responsible for configuring equipment. They may mandate that staff perform step-by-step procedures in areas that previously had no need for them (e.g., the guard at the door). They may draft guidelines and expect others to follow their advice. Only an executive who truly understands the end goal of their activities will be able to provide the tone at the top necessary to support such a CISO-led cyber security program.

There is also a technique used by cyber security professionals, both security staff and auditors, where policy and standards are translated into a set of questions about the technology environment. Rather than directly evaluate technology, a cyber security assessor may instead present management with a series of questions about the security of a given technology environment. These questions are typically formulated with a specific cyber security policy or standard in mind, but they do not replace the standard. They are information-gathering conveniences for the assessor. People who participate in this type of process often treat the questions themselves as policy, but they are not. Such sets of security questions lie entirely outside of the cyber security management process. Moreover, although this type of the question and answer routine is typically used in due diligence processes where security must to some extent be evaluated, it should not be mistaken for a professional technology audit (Bayuk 2005).

When an executive fully understands the motivation and origin for enterprise security policy, the process for implementation should be as easy to manage as any other technology endeavor. This is not to say that technology endeavors are ever easy to manage. However, typical managerial techniques such as continuous monitoring in the style of Drucker and Deming go as far in cyber security as they do for any other domain (Drucker 2001; Pande, Neuman et al. 2001). Applied to cyber security, such techniques allow for advancement of the enterprise purpose or strategic mission, and fortify its resiliency against currently unknown threats. Moreover, the application of sound management practices to the domain of security carries the happy unintended consequence of the ability to pass technology audits.

4.4 Using the Catalog

The next two chapters of this book describe a catalog approach to cyber security policy and provide numerous examples of cyber security policy statements that have been adopted by others. A thorough read of these chapters will provide an appreciation for the breadth and depth of issues that come under the general heading of cyber security, most of which will never be faced by any one individual. However, it also makes it easy to see how policy decisions made by some individuals in their own domains will affect others.

As in a physical security environment, each significant social, economic, institutional, and political segment of the community has a number of potential resources that can be brought to bear (NCPI 2001). There is a role for the police, for private security services, for technology vendors, for government, for the insurance industry, for civic groups, for the business community, for industry associations, and for citizen organizations. Each group’s role needs clarity in its scope and potential impact on the overall problem. The cyber security policy issues in Chapter 6 have been organized in a role-based manner accordingly.

However, the policy statements in Chapter 6 are not meant as a pick-list from which to choose a cyber security policy befitting one’s role. Not only is the chapter not customized to the nomenclature of any given enterprise, there are certainly statements concerning cyber security policy of use to executive management that do not appear in this guidebook. The list is not expected to ever be exhaustive. Even if it were possible to complete such a list before the time this guidebook went to publication, by the time the publication process was finished, there would be some change in cyberspace that necessitated new ways of policy formulation. At best, this book provides executives with the capability to properly analyze new cyber security situations within a well-understood framework of policy issues.

There is also a large class of policy statements that were omitted intentionally. These are technical security configurations for hardware and software components of cyberspace of the sort described in Section 1.3.4. While many organizations publish technical security specifications under the heading of policy, they do not reflect management objectives themselves. Rather, they provide implementation standards for technical professionals charged with executing management policy directives. Where it is imperative that these technical standards are implemented consistently without exception, they may qualify as cyber security policy. However, depending on the enterprise or mission, there are in fact implementation standards that executive management may not be expected to completely understand, much less to dictate.

Cyber attacks require coordinated response. However, in order to coordinate response, one first needs an ability to detect cyber attacks, access to intelligence with which to analyze them, and a method and means of response (Amoroso 2006). An individual organization may lay plans to coordinate its own response, but for response to cross all communities of interest, more coordinated policies are required on common fronts. As you read through Chapter 6, you may find a way to self-categorize issues into those you may be able to control, those you may have influence over, and those concerning which the most you can do is maintain awareness.

Although there are circumstances under which influence should be sought as well as provided, we caution against the active solicitation of customers or other end users to participate in the cyber security policy goals of any given enterprise. Citizen participation should not be solicited until policymakers understand the point and purpose of individual action. Citizen awareness programs that stimulate fear but provide no effective response to attack are not useful in minimizing the potential societal effect of any threat (Siegel 2005). However, where problems are obvious and remedies are easily available, citizen groups may be counted on to recognize issues in their own domains and unite along lines that may preexist in various communities. Bridge clubs and book club discussions may lead to local community participation in crime surveys and then to government meetings and eventual legislation. Where there is an opportunity for self-policing to occur, for example, neighbors on the same cable connection, it should be as supported and encouraged just as much as physical neighborhood crime watches. It may be well within an enterprise policy framework to actively court such interests to contribute to well-defined cyber security strategies.

Policy should not only address goals, but also identify key barriers to goal achievement and anticipate resistance to change. The resistance may come from sources both internal and external to the organization. Those with experience in accountability for security measures well understand that security policy is often used as a shield against change. Where the security policy mandates that are composed for a given business operation seem to work well, the evolution of that business operation may be at risk due to an inflexible security policy. That is, those who oppose a proposal for innovation may use a legacy system’s security policy as an excuse to resist change. Where policy has been mistakenly framed as an enterprise-level directive in support of the elusive concept of “security” rather than framed as support of a given operation or mission, this attitude receives considerable support because no one wants to be accountable for introducing vulnerability. However, a true enterprise strategist will see security policy as a flexible tool with which to achieve objectives, not as a barrier or disincentive to innovation.

When things are quiet, it makes sense to plan. As the CISO of AT&T, historically one of the most hacked targets on the planet, has put it, “During a period of seeming quiet, never confuse good luck with improved cyber security”(Amoroso 2006).