Policies, Standards, Baselines, Guidelines, and Procedures

To tie these items together, let's walk through an example.

A corporation's security policy indicates that confidential information should be properly protected. It states the issue in very broad and general terms. A supporting standard mandates that all customer information held in databases must be encrypted with the Advanced Encryption Standard (AES) algorithm while it is stored and that it cannot be transmitted over the Internet unless IPSec encryption technology is used. The standard indicates what type of protection is required and provides another level of granularity and explanation. The supporting procedures explain exactly how to implement the AES and IPSec technologies, and the guidelines cover how to handle cases when data is accidentally corrupted or compromised during transmission. Once the software and devices are configured as outlined in the procedures, this is considered the baseline that must always be maintained. All of these work together to provide a company with a security structure.

Threat Modeling

A process for constructing scenarios of the types of threats that assets can face.

Guidelines

Guidelines are recommended actions and operational guides to users, IT staff, operations staff, and others when a specific standard does not apply. They can also be used as a recommended way to achieve specific standards when those do apply. Guidelines can deal with the methodologies of technology, personnel, or physical security. Life is full of gray areas, and guidelines can be used as a reference during those times. Whereas standards are specific mandatory rules, guidelines are general approaches that provide the necessary flexibility for unforeseen circumstances.

Attacks

If the vulnerability is on one end of a network and the threat source is on the other, it is the attack that ties them together.

Policy establishes the strategic plans, and the lower elements provide the tactical support

Policy establishes the strategic plans, and the lower elements provide the tactical support

Procedures

Procedures are detailed step-by-step tasks that should be performed to achieve a certain goal. The steps can apply to users, IT staff, operations staff, security members, and others who may need to carry out specific tasks. Many organizations have written procedures on how to install operating systems, configure security mechanisms, implement access control lists, set up new user accounts, assign computer privileges, audit activities, destroy material, report incidents, and much more. Procedures are considered the lowest level in the documentation chain because they are closest to the computers and users (compared to policies) and provide detailed steps for configuration and installation issues.

Risk Assessment and Analysis

Process of identifying the risks to an organization, assessing the critical functions, defining the controls in place to reduce organization exposure and evaluating the cost for such controls. A risk analysis has four main goals: • Identify assets and their value to the organization. • Identify vulnerabilities and threats. • Quantify the probability and business impact of these potential threats. • Provide an economic balance between the impact of the threat and the cost of the countermeasure.

Information Systems Risk Management Policy

Proper risk management requires a strong commitment from senior management, a documented process that supports the organization's mission, an information systems risk management (ISRM) policy, and a delegated ISRM team. The ISRM policy should be a subset of the organization's overall risk management policy (risks to a company include more than just information security issues) and should be mapped to the organizational security policies. The ISRM policy should address the following items: • The objectives of the ISRM team • The level of risk the organization will accept and what is considered an acceptable level of risk • Formal processes of risk identification • The connection between the ISRM policy and the organization's strategic planning processes • Responsibilities that fall under ISRM and the roles to fulfill them • The mapping of risk to internal controls • The approach toward changing staff behaviors and resource allocation in response to risk analysis • The mapping of risks to performance targets and budgets • Key indicators to monitor the effectiveness of controls

Risk Management

Risk in the context of security is the possibility of damage happening and the ramifications of such damage should it occur. Risk management (RM) is the process of identifying and assessing risk, reducing it to an acceptable level, and ensuring it remains at that level.

Vulnerabilities

Security risk factors. rmation In almost every case, the information at the core of our information systems is the most valuable asset to a potential adversary. Information within a computer information sys- tem (CIS) is represented as data. This information may be stored (data at rest), trans- ported between parts of our system (data in motion), or actively being used by the system (data in use). In each of its three states, the information exhibits different vulnerabilities, as listed in the following examples: • Data at rest Data is copied to a thumb drive and given to unauthorized parties by an insider, thus compromising its confidentiality. • Data in motion Data is modified by an external actor intercepting it on the network and then relaying the altered version (known as a man-in-the-middle or MitM attack), thus compromising its integrity. • Data in use Data is deleted by a malicious process exploiting a "time of check to time of use" (TOC/TOU) or "race condition" vulnerability, thus compromising its availability. We address this in detail in Chapter 3 (which covers domain 3, Security Engineering). Processes Processes are almost always instantiated in software as part of a CIS. Therefore, process vulnerabilities can be thought of as a specific kind of software vulnerability. People There are many who would consider the human the weakest link in the security chain. Whether or not you agree with this, it is important to consider the specific vulnerabilities that people present in a system. Though there are many ways to exploit the human in the loop, there are three that correspond to the bulk of the attacks, summarized briefly here: •Social engineering This is the process of getting a person to violate a security procedure or policy, and usually involves human interaction or e-mail/text messages. •Social networks The prevalence of social network use provides potential attackers with a wealth of information that can be leveraged directly (e.g., blackmail) or indirectly (e.g., crafting an e-mail with a link that is likely to be clicked) to exploit people. •Passwords Weak passwords can be cracked in milliseconds using rainbow tables (discussed in Chapter 5) and are very susceptible to dictionary or brute-force attacks. Even strong passwords are vulnerable if they are reused across sites and systems.

Standards

Standards refer to mandatory activities, actions, or rules. Standards can give a policy its support and reinforcement in direction. Organizational security standards may specify how hardware and software products are to be used. They can also be used to indicate expected user behavior. They provide a means to ensure that specific technologies, applications, parameters, and procedures are implemented in a uniform (standardized) manner across the organization. An organizational standard may require that all employees wear their company identification badges at all times, that they challenge unknown individuals about their identity and purpose for being in a specific area, or that they encrypt confidential information. These rules are compulsory within a company, and if they are going to be effective, they must be enforced.

TIP A policy needs to be technology and solution independent. It must outline the goals and missions, but not tie the organization to specific ways of accomplishing them.

TIP A policy needs to be technology and solution independent. It must outline the goals and missions, but not tie the organization to specific ways of accomplishing them.

Threats

The International Organization for Standardization and the International Electrotechnical Commission in their ISO/IEC standard 27000 define a threat as a "potential cause of an unwanted incident, which may result in harm to a system or organization."

Baselines

The term baseline refers to a point in time that is used as a comparison for future changes. Once risks have been mitigated and security put in place, a baseline is formally reviewed and agreed upon, after which all further comparisons and development are measured against it. A baseline results in a consistent reference point. Baselines are also used to define the minimum level of protection required. In security, specific baselines can be defined per system type, which indicates the necessary settings and the level of protection being provided.

EXAM TIP

The term standard has more than one meaning in our industry. Internal documentation that lays out rules that must be followed is a standard. But sometimes, best practices, as in the ISO/IEC 27000 series, are referred to as standards because they were developed by a standards body. And as we will see later, we have specific technologic standards, as in IEEE 802.11. You need to understand the context of how this term is used. The CISSP exam will not try and trick you on this word; just know that the industry uses it in several different ways.

Reduction Analysis

There are two aspects of reduction analysis in the context of threat modeling: one aspect is to reduce the number of attacks we have to consider, and the other is to reduce the threat posed by the attacks.

An issue-specific policy, also called a functional policy

addresses specific security issues that management feels need more detailed explanation and attention to make sure a comprehensive structure is built and all employees understand how they are to comply with these security issues.

security policy

an overall general statement produced by senior management (or a selected policy board or committee) that dictates what role security plays within the organization. A security policy can be an organizational policy, an issue-specific policy, or a system-specific policy. In an organizational security policy, management establishes how a security program will be set up, lays out the program's goals, assigns responsibilities, shows the strategic and tactical value of security, and outlines how enforcement should be carried out. This policy must address relative laws, regulations, and liability issues and how they are to be satisfied. The organizational security policy provides scope and direction for all future security activities within the organization. It also describes the amount of risk senior management is willing to accept.

Policies are written in

broad terms to cover many subjects in a general fashion.Much more granularity is needed to actually support the policy, and this happens with the use of procedures, standards, guidelines, and baselines. The policy provides the foundation. The procedures, standards, guidelines, and baselines provide the security framework. And the necessary security controls (administrative, technical, and physical) are used to fill in the framework to provide a full security program.

Implementation

the process by which a law or policy is put into operation

Risk analysis provides a cost/benefit comparison

which compares the annualized cost of controls to the potential cost of loss. A control, in most cases, should not be implemented unless the annualized cost of loss exceeds the annualized cost of the control itself. This means that if a facility is worth $100,000, it does not make sense to spend $150,000 trying to protect it. A risk analysis helps integrate the security program objectives with the company's business objectives and requirements.

The organizational security policy has several important characteristics that must be understood and implemented:

• Business objectives should drive the policy's creation, implementation, and enforcement. The policy should not dictate business objectives. • It should be an easily understood document that is used as a reference point for all employees and management. • It should be developed and used to integrate security into all business functions and processes. • It should be derived from and support all legislation and regulations applicable to the company. • It should be reviewed and modified as a company changes, such as through adoption of a new business model, a merger with another company, or change of ownership. • Each iteration of the policy should be dated and under version control. • The units and individuals who are governed by the policy must have easy access to it. Policies are commonly posted on portals on an intranet. • It should be created with the intention of having the policies in place for several years at a time. This will help ensure policies are forward-thinking enough to deal with potential changes that may arise. • The level of professionalism in the presentation of the policies reinforces their importance as well as the need to adhere to them. • It should not contain language that isn't readily understood by everyone. Use clear and declarative statements that are easy to understand and adopt. • It should be reviewed on a regular basis and adapted to correct incidents that have occurred since the last review and revision of the policies. Organizational policies are also referred to as master security policies. An organization will have many policies, and they should be set up in a hierarchical manner. The organizational (master) policy is at the highest level, and then there are policies underneath it that address security issues specifically. These are referred to as issue-specific policies.

Risk Management Process

• Frame risk Risk framing defines the context within which all other risk activities take place. What are our assumptions and constraints? What are the organizational priorities? What is the risk tolerance of senior management? • Assess risk Before we can take any action to mitigate risk, we have to assess it. This is perhaps the most critical aspect of the process, and one that we will discuss at length. If your risk assessment is spot-on, then the rest of the process becomes pretty straightforward. • Respond to risk By now, we've done our homework. We know what we should, must, and can't do (from the framing component), and we know what we're up against in terms of threats, vulnerabilities, and attacks (from the assess component). Responding to the risk becomes a matter of matching our limited resources with our prioritized set of controls. Not only are we mitigating significant risk, but, more importantly, we can tell our bosses what risk we can't do anything about because we're out of resources. • Monitor risk No matter how diligent we've been so far, we probably missed something. If not, then the environment likely changed (perhaps a new threat source emerged or a new system brought new vulnerabilities). In order to stay one step ahead of the bad guys, we need to continuously monitor the effectiveness of our controls against the risks for which we designed them.

NIST SP 800-39 defines three tiers to risk management:

• Organizational tier Concerned with risk to the business as a whole, which means it frames the rest of the conversation and sets important parameters such as the risk tolerance level. • Business process tier Deals with the risk to the major functions of the organization, such as defining the criticality of the information flows between the organization and its partners or customers. The bottom tier. • Information systems tier Addresses risk from an information systems perspective. Though this is where we will focus our discussion, it is important to understand that it exists within the context of (and must be consistent with) other, more encompassing risk management efforts.

When we look at information security, note that an organization needs to be aware of several types of risk and address them properly. The following items touch on the major categories:

• Physical damage Fire, water, vandalism, power loss, and natural disasters • Human interaction Accidental or intentional action or inaction that can disrupt productivity • Equipment malfunction Failure of systems and peripheral devices • Inside and outside attacks Hacking, cracking, and attacking • Misuse of data Sharing trade secrets, fraud, espionage, and theft • Loss of data Intentional or unintentional loss of information to unauthorized receivers • Application error Computation errors, input errors, and buffer overflows Threats must be identified, classified by category, and evaluated to calculate their damage potential to the organization. Real risk is hard to measure, but prioritizing the potential risks in order of which ones must be addressed first is obtainable.

Types of Policies

• Regulatory This type of policy ensures that the organization is following standards set by specific industry regulations (HIPAA, GLBA, SOX, PCI DSS, etc.). It is very detailed and specific to a type of industry. It is used in financial institutions, healthcare facilities, public utilities, and other government-regulated industries. • Advisory This type of policy strongly advises employees as to which types of behaviors and activities should and should not take place within the organization. It also outlines possible ramifications if employees do not comply with the established behaviors and activities. This policy type can be used, for example, to describe how to handle medical or financial information. • Informative This type of policy informs employees of certain topics. It is not an enforceable policy, but rather one that teaches individuals about specific issues relevant to the company. It could explain how the company interacts with partners, the company's goals and mission, and a general reporting structure in different situations.

A common hierarchy of security policies is outlined here, which illustrates the relationship between the master policy and the issue-specific policies that support it:

•Organizational policy • Acceptable use policy • Risk management policy • Vulnerability management policy • Data protection policy • Access control policy • Business continuity policy • Log aggregation and auditing policy • Personnel security policy • Physical security policy • Secure application development policy • Change control policy • E-mail policy •Incident response policy