Policies and Standards Design Considerations

All documents in a policy and standards library are meant for people to read, understand, and implement. Policies and standards are not guidelines that offer suggestions. They are a collection of concrete definitions, procedures, and standards that describe acceptable and unacceptable human behavior. There are consequences for failing to follow approved standards. Developing them is not a trivial undertaking.

NOTE

Most often, the questions related to where, when, and how are more appropriate for procedures or guidelines rather than policies or standards. Try to keep your policies and standards at the what, who, and why level of detail.

There’s little point in writing documents that people cannot understand or that make compliance highly difficult or impossible. The best kinds of documents are clearly worded and address the six key questions of who, what, where, when, why, and how. These questions provide a consistent direction in writing policies and standards. Journalists traditionally ask these six questions as they research and write news stories. Most readers, of news articles and policy documents alike, are busy. They need concise and precise information. Lack of clarity forces readers to make assumptions. Often those assumptions are wrong. When you answer these questions within the first few sections of your documents, you increase the reader’s comfort level and increase the likelihood of compliance.

TIP

When writing policies and standards, avoid using terms like should when you mean must or need to.

Effective policies are those that employees understand and embrace. It’s simply human nature for people to work harder for something they believe in. This depends on a shared belief system. These shared beliefs are collectively described as the organizational culture. Some organizations have a strong command and control culture. This dictates that policies and standards are written as strong, imperative statements; for example, “You must log off at the end of each workday.” Other organizations use subtler phrases and tone, intended to persuade those who must follow the policy. But it’s important to avoid using vague language or loose terms when developing your documents. This includes any terms that are vague. If the employees cannot understand clearly what is intended by the policies, they cannot comply. If you allow people to interpret your requirements on their own, they might look for ways to opt out of them.

The challenge is how to establish, or recognize, a core set of beliefs that can influence how you write policies. One method is to break the problem down into how the security controls are to be implemented and what controls are needed.

Operating Models

An operating model can help you understand how the security controls are to be implemented. One issue over which disagreement often arises is how much security should be centralized or decentralized within the business. A discussion of the operating model within the company can identify areas of disagreement and create a common set of beliefs on the proper placement and implementation of controls.

There are different ways to have this broad operational concept conversation. One way is outlined in a book entitled Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, by Jeanne W. Ross, Peter Weill, and David C. Robertson. Their approach was to analyze and categorize the primary operating model of the business on the basis of four concepts: diversified, coordinated, replicated, and unified. As you can see by FIGURE 7-1, these operating model concepts are aligned with how the business chooses to integrate and standardize with an enterprise solution. In general, the higher the level of integration and standardization in an enterprise solution, the easier it is to implement security policies. The more the leaders of the business are deploying their own solution, the harder it is to implement security policies. The following defines each quadrant of Figure 7-1 in the context of IT solutions:

FIGURE 7-1 The four basic business operating models.

• Diversified—In the diversified operating model, the technology solution has a low level of integration and standardization with the enterprise. Typically, the exchange of data and use of services outside the business unit itself is minimal.
• Coordinated—In a coordinated operating model, the technology solution shares data across the enterprise; however, the level of shared services and standardization are minimal.
• Replicated—In a replicated operating model, the technology solution shares services across the enterprise; however, the level of data sharing is minimal.
• Unified—In a unified operating model, the technology solution both shares data and has standardized services across the enterprise.

These are not mutually exclusive. You can certainly have a coordinated model that is also replicated. Typically, you will have both highly integrated and less integrated systems across the enterprise. These choices are made by the business and reflect the beliefs the business holds. For example, if a business makes several changes to an application over a year, it may want more direct control over the technology. The staff may see control as critical to their success. This is especially true if they feel they must make technological changes throughout the year to keep up with the market. This approach can lead to standalone solutions that are business-specific and less integrated with enterprise solutions.

The four concepts align with service integration and service standardization. Service integration generally refers to how much shared data is used across a business. Service standardization, on the other hand, refers to how much control the business has in setting up its solutions and processes. For example, a real estate business may have a high degree of service integration. The company may share data on new home purchases between the business unit that sold the home and the unit that sells insurance for the home.

Those four models are not the only ways of looking at a business; however, they are useful and clear models. They are a good starting point for considering your organization’s business model and how it impacts security policies. The operating model can have a profound effect on how your controls are implemented and how policies are written. The challenge is balancing the needs of the business and the enterprise needs to control security. These deliberate choices the business makes typically reflect the beliefs of the business’s leaders.

Principles for Policy and Standards Development

No two organizations or risk assessment outcomes are the same; there are no universal recipes for building an IT security program. Instead, principles help you make decisions in new situations using proven experience and industry best practices. By considering several principles, you can derive control requirements and help make implementation decisions.

Use the following principles to help you develop policies, standards, baselines, procedures, and guidelines. These are the common core security principles recommended for industry best practices, regardless of the organization’s business nature:

NOTE

It is important not to underestimate the strong feelings the business has in the level of controls it wants over technology. The challenge is selecting an operating model that the business can commit to and that will ensure that IT security policies are enforced.

• Accountability principle—The personal responsibility of information systems security should be explicit. Some roles in the organization are accountable only for the work they perform daily. Other roles are accountable for their own work, plus all the work performed by their team of employees. Accountability helps to ensure that people understand they are solely responsible for actions they take while using organization resources. You can think of accountability as a deterrent control.
• Awareness principle—Owners, providers, and users of information systems, as well as other parties, should be informed of the existence and general context of policies, responsibilities, practices, procedures, and organization for security of information systems. Put more simply, it is unlikely that stakeholders will comply with policies they are not aware of.
• Ethics principle—The way information systems are designed, and the level of access to data reflected in the security controls, should operate in accordance with the organization’s ethical standards. This includes the level of disclosure and access to customer data. This also needs to be entrenched in the organizational culture in order to be effective.
• Multidisciplinary principle—Policy and standards library documents should be written to consider everyone affected, including technical, administrative, organizational, operational, commercial, educational, and legal personnel.
• Proportionality principle—Security levels, costs, practices, and procedures should be appropriate and proportionate to the value of the data and the degree of reliance on the system. They should also be proportional to the potential severity, probability, and extent of harm to the system or loss of the data. In other words, don’t spend $1000 to protect $500 worth of assets.
• Integration principle—Your documents should be coordinated and integrated with each other. They should also integrate with other relevant measures, practices, and procedures for a coherent system of security.
• Defense-in-depth principle—Security increases when it is implemented as a series of overlapping layers of controls and countermeasures that provide three elements to secure assets: prevention, detection, and response. This is referred to as defense in depth. It is both a military concept and an information security concept. Defense in depth dictates that security mechanisms be layered so that the weaknesses of one mechanism are countered by the strengths of two or more other mechanisms. This is a core security concept.
• Timeliness principle—All personnel, assigned agents, and third-party providers should act in a timely and coordinated manner to prevent and to respond to breaches of the security.
• Reassessment principle—The security of information systems should be periodically reassessed. Risks to technology change daily, and periodic reassessments are needed to ensure that security requirements and practices are kept current with these changes. Standards also need reassessments, at least annually, to ensure they represent the current state of affairs.
• Privacy principle—The security of an information system should include secure private information of users of the system. In other words, consider your users or partners when requiring information that could place their privacy rights at risk.
• Internal control principle—Information security forms the core of an organization’s information internal control systems. Regulations mandate that internal control systems be in place and operating correctly. Organizations rely on technology to maintain business records. It’s essential that such technology include internal control mechanisms. These maintain the integrity of the information and represent a true picture of the organization’s activities.
• Adversary principle—Controls, security strategies, architectures, and policy library documents should be developed and implemented in anticipation of attack from intelligent, rational, and irrational adversaries who may intend harm. This is also the case with threat assessment.
• Least privilege principle—People should be granted only enough privilege to accomplish assigned tasks and no more. This is another core principle of security.
• Separation of duty principle—Responsibilities and privileges should be divided to prevent a person or a small group of collaborating people from inappropriately controlling multiple key aspects of a process and causing harm or loss. For example, in an accounting department, the person preparing invoices for payment should not be the same person writing the checks for payment.
• Continuity principle—Identify your organization’s needs for disaster recovery and continuity of operations. Prepare the organization and its information systems accordingly.
• Simplicity principle—Try to favor small and simple safeguards over large and complex ones. Security is improved when it’s made simpler. Obviously, security should not be oversimplified, but instead made as simple as practically possible.
• Policy-centered security principle—Policies, standards, and procedures should be established as the formal basis for managing the planning, control, and evaluation of all information security activities.

In addition to these principles, there are some specific steps that should be taken when developing security policies:

• Risk identification—Always begin by identifying the risks that the policies are trying to mitigate.
• Legal compliance—Make certain that policies comply with any legal or regulatory requirements.
• Practicality—Make sure the policy is something you can implement and enforce.

The Importance of Transparency with Regard to Customer Data

Policies related to the handling and use of customer data should include the concept of transparency. Organizations should be transparent and should notify individuals of the collection, use, dissemination, and maintenance of personally identifiable information (PII). PII is information that can be used to identify a specific person. This can be something used alone, such as a person’s name.

A closely related concept is nonpublic personal information (NPI). This is the term the Gramm-Leach-Bliley Act uses to refer to any personally identifiable financial information that a consumer provides to a financial institution.

TIP

Whenever customer data is involved, be sure to check with your compliance team on the legal requirements related to handling and use of such data.

Transparency with regard to handling of customer data should include the following elements:

• Individual participation—Organizations should involve the individual in the process of using PII and seek individual consent. This consent should include the collection, use, dissemination, and maintenance of PII. Organizations should also provide mechanisms for appropriate access, correction, and redress regarding use of PII.
• Purpose specification—Organizations should specifically describe the authority that permits the collection of PII and articulate the purpose or purposes for which they intend to use data.
• Data minimization—Organizations should collect only PII that is directly relevant and necessary to accomplish the specified purpose(s). Additionally, they should retain PII only for as long as is necessary to fulfill the specified purpose(s). Any excessive data collection or retention only increases the risk to the organization.
• Use limitation—Organizations should use PII solely for the purpose(s) specified. If PII is shared, it should be for a purpose for which it was collected. This is now enshrined in laws such as the General Data Protection Regulation (GDPR) in the European Union.

Types of Controls for Policies and Standards

With a shared sense of purpose and beliefs within the business and principles in hand, you can begin to map what you want to accomplish with the security controls. Security controls are measures taken to protect systems from attacks on the confidentiality, integrity, and availability (C-I-A triangle or triad) of the system. Sometimes, safeguards and countermeasures are used synonymously with the word control. Controls are chosen after the risk assessment of the assets is complete. Once you have identified and assessed the risks to your assets, you can select the appropriate control to counter the threat, mitigate it, or reduce the risks.

Security Control Types

Security controls can be described according to two different categorization schemes: one based upon what the control is and the other based upon what the control does.

The first category includes administrative, technical, and physical control categories. They describe what the control actually is, such as a named process, a standard, a firewall, or a locked door:

• Administrative controls—The policies, standards, and procedures that guide employees when conducting the organization’s business. Preemployment screening of personnel and a change management process are also examples of administrative controls.
• Technical security controls—The devices, protocols, and other technology used to protect assets. These include antivirus systems, cryptographic systems, firewalls, and more.
• Physical security controls—The devices used to control physical access. Examples here are fences, security guards, locked doors, motion detectors, and alarms.

To be effective, security must consider all three approaches. For example, if you wish to secure a server, it should be in a locked server room (physical controls). It should have strong authentication and an encrypted hard drive (technical controls). Finally, there must be effective security policies governing the server (administrative controls).

The second set of controls describes what controls do. These controls include the following:

• Preventive security controls—Prevent intentional or unintentional security threats. Examples include network access policies, firewall rules, and locks on wiring closets and server room doors.
• Detective or response controls—Act like alarms and warnings. These controls kick in after an incident begins. Examples include motion detectors, log files, and files that contain system audit information.
• Corrective controls—Help you respond to and fix a security incident. Corrective controls are also used to limit or stop further damage. Some examples include cleaning a virus off a system, closing a firewall port, and blocking an Internet Protocol (IP) address.
• Recovery controls—Help you put a system back into operation once an incident ends. Disaster recovery and tape backups fit into this category.

There is significant overlap between security control categories. Some controls can be administrative and preventive or technical and corrective, or any combination. This overlap occurs by design for the purpose of implementing the principle of defense in depth.

You can find catalogs of security controls for virtually every security topic. For example, Control Objectives for Information and related Technology (COBIT) is an IT governance framework developed by ISACA that includes supporting tools to help bridge the gaps between control requirements, technical issues, and business risks. You can visit the ISACA website at http://www.isaca.org for more information.