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:

• 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.

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:

• 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.

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.

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.

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.