CISSP Security Management and Practices

Date: Dec 20, 2002 By Roberta Bragg. Sample Chapter is provided courtesy of Que.
This sample chapter covers Domain 3, Security Management Practices, 1 of 10 domains of the Common Body of Knowledge (CBK) covered in the Certified Information Systems Security Professional Examination.

Objectives

Understand the principles of security management.

. In understanding information security management, there are a number of principles you need to know to create a managed security program. These principles go beyond firewalls, encryptions, and access control. They are concerned with the various aspects of managing the organization's information assets in areas such as privacy, confidentiality, integrity, accountability, and the basics of the mechanisms used in their management.

Know what management's responsibility is in the information security environment.

. Management cannot just decree that the systems and networks will be secure. They must take an active role in setting and supporting the information security environment. Without management support, the users will not take information security seriously.

Understand risk management and how to use risk analysis to make information security management decisions.

. Managing security is the management of risk. Knowing how to assess and manage risk is key to an information security management program.

Know how to set policies and how to derive standards, guidelines, and implement procedures to meet policy goals.

. Policies are the blueprints of the information security program. From policies, you can set the standards and guidelines that will be used throughout your organization to maintain your security posture. Then, using those standards, you can create procedures that can implement the policies.

Set information security roles and responsibilities throughout your organization.

. From management to the users, everyone who has access to your organization's systems and networks is responsible for their role in maintaining security as set by the policies. Understanding these roles and responsibilities is key to creating and implementing security policies and procedures.

Understand how the various protection mechanisms are used in information security management.

. Protection mechanisms are the basis of the data architecture decision that will be made in your information security program. These are the basis for the way data is protected and provide a means for access.

Understand the considerations and criteria for classifying data.

. Protecting data is the objective of every information security program. Therefore, we look at how that data can be classified so it can be securely handled.

Determine how employment policies and practices are used to enhance information security in your organization.

. Even with the press concentrating on the effects of denial-of-service attacks and viruses, the biggest threats come from within. Improving on the employment policies and practices to perform better background checks and better handle hiring and termination, as well as other concerns to help minimize the internal threat, are important information security practices.

Use change control to maintain security.

. One of the jobs of a Trojan horse is to replace a program with one that can be used to attack the system. Change control is one defense against this type of attack. Using change control to maintain the configuration of programs, systems, and networks, you can prevent changes from being used to attack your systems.

Know what is required for Security Awareness Training.

. The best security policies and procedures are ineffectual if users do not understand their roles and responsibilities in the security environment. Training is the only way for users to understand their responsibilities.

Outline

Introduction

  • Defining Security Principles

    • CIA: Information Security's Fundamental Principles
      • Confidentiality
      • Integrity
      • Availability
    • Privacy
    • Identification and Authentication
      • Passwords
    • Nonrepudiation
    • Accountability and Auditing
      • Keystroke Monitoring
      • Protecting Audit Data
    • Documentation

  • Security Management Planning

  • Risk Management and Analysis

    • Risk Analysis
    • Identifying Threats and Vulnerabilities
    • Asset Valuation
    • Qualitative Risk Analysis
    • Countermeasure Selection and Evaluation
    • Tying It Together

  • Policies, Standards, Guidelines, and Procedures

    • Information Security Policies
      • How Policies Should Be Developed
      • Define What Policies Need to Be Written
      • Identify What Is to Be Protected
      • Identify from Whom It Is Being Protected
    • Setting Standards
    • Creating Baselines
    • Guidelines
    • Setting and Implementing Procedures

  • Examining Roles and Responsibility

  • Management Responsibility

    • User Information Security Responsibilities
    • IT Roles and Responsibilities
    • Other Roles and Responsibilities

  • Understanding Protection Mechanisms

    • Layering
    • Abstraction
    • Data Hiding
    • Encryption

  • Classifying Data

    • Commercial Classification
    • Government Classification
    • Criteria
    • Creating Procedures for Classifying Data

  • Employment Policies and Practices

    • Background Checks and Security Clearances
    • Employment Agreements, Hiring, and Termination
      • The Acceptable Usage Policy
      • Termination
    • Job Descriptions
    • Job Rotation

  • Managing Change Control

    • Hardware Change Control
    • Software Change Control

  • Security Awareness Training

  • Summary

  • Apply Your Knowledge

Study Strategies

Even if you are not part of your organization's management team, watch how management works in the information security environment. Take the practices and strategies written here and look at not only how your organization implements them, but how they can be improved. This type of lateral thinking will help on the exam and can make you a valuable contributor to your organization's security posture.

The notes throughout the chapter point out key definitions and concepts that could appear on the exam. They are also key components that all managers should understand.

This chapter covers Domain 3, Security Management Practices, 1 of 10 domains of the Common Body of Knowledge (CBK) covered in the Certified Information Systems Security Professional Examination. This domain is divided into several objectives for study.

    "Security management entails the identification of an organization's information assessment and the development, documentation, and implementation of policies, standards, procedures, and guidelines that ensure confidentiality, integrity, and availability. Management tools such as data classification, risk assessment, and risk analysis are used to identify the threats, classify assets, and to rate their vulnerabilities so that effective security controls can be implemented.

    Risk management is the identification, measurement, control, and minimization of loss associated with uncertain events or risks. It includes overall security review, risk analysis, selection and evaluation of safeguards, cost benefit analysis, management decision, safeguard implementation, and effectiveness review.

    The candidate will be expected to understand the planning, organization, and roles of the individual in identifying and securing an organization's information assets; the development and use of policies stating management's views and position on particular topics and the use of guidelines, standard, and procedures to support the policies; security awareness training to make employees aware of the importance of information security, its significance, and the specific security-related requirements relative to their position; the importance of confidentiality, proprietary, and private information; employment agreements; employee hiring and termination practices; and risk management practices and tools to identify, rate, and reduce the risk to specific resources."

    —Common Body of Knowledge study guide

 

Introduction

Security management can be difficult for most information security professionals to understand. It is the bridge between understanding what is to be protected and why those protections are necessary. Using basic principles and a risk analysis as building blocks, policies can be created to implement a successful information security program.

As part of creating that program, information security management should also understand how standards and guidelines also play a part in creating procedures. When doing this, every user's role and responsibilities should be accounted for by understanding how to protect the organization's information assets.

The role of data as a significant part of the organization's information assets cannot be minimized. Data provides the fuel that drives your organization, but it is the asset that is the most vulnerable. Protecting this asset means understanding the various classifying mechanisms and how they can be used to protect your critical assets.

This chapter covers all these issues and discusses security awareness and managing people in your information security environment.

Defining Security Principles

To understand how to manage an information security program, you must understand the basic principles. These principles are the building blocks, or primitives, to being able to determine why information assets need protection.

CIA: Information Security's Fundamental Principles

Remembering that information is the most important of your organization's assets (second to human lives, of course), the first principles ask what is being protected, why, and how do we control access? The fundamental goal of your information security program is to answer these questions by determining the confidentiality of the information, how can you maintain the data's integrity, and in what manner its availability is governed. These three principles make up the CIA triad (see Figure 3.1).

Figure 3.1 Security's fundamental principles are confidentiality, integrity, and availability.

The CIA triad comprises all the principles on which every security program is based. Depending on the nature of the information assets, some of the principles might have varying degrees of importance in your environment.

Confidentiality

Confidentiality determines the secrecy of the information asset. Determining confidentiality is not a matter of determining whether information is secret or not. When considering confidentiality, managers determine the level of access in terms of how and where the data can be accessed. For information to be useful to the organization, it can be classified by a degree of confidentiality.

To prevent attackers from gaining access to critical data, a user who might be allowed access to confidential data might not be allowed to access the service from an external access port. The level of confidentiality determines the level of availability that is controlled through various access control mechanisms.

Protections offered to confidential data are only as good as the security program itself. To maintain confidentiality, the security program must consider the consequences of an attacker monitoring the network to read the data. Although tools are available that can prevent the attacker from reading the data in this manner, safeguards should be in place at the points of transmission, such as by using encryption or physically safeguarding the network.

Another attack to confidentially is the use of social engineering to access the data or obtain access. Social engineering is difficult to defend because it requires a comprehensive and proactive security awareness program. Users should be educated about the problems and punishments that result when they intentionally or accidentally disclose information. This can include safeguarding usernames and passwords from being used by an attacker.

Cryptography is the study of how to scramble, or encrypt, information to prevent everyone but the intended recipient from being able to read it. Encryption implements cryptography by using mathematical formulas to scramble and unscramble the data. These formulas use an external piece of private data called a key to lock and unlock the data.

Cryptography can trace its roots back 4,000 years to ancient Egypt where funeral announcements were written using modified hieroglyphics to add to their mystery. Today, cryptography is used to keep data secret. For more information on cryptography, see Chapter 5, "Cryptography."

Integrity

With data being the primary information asset, integrity provides the assurance that the data is accurate and reliable. Without integrity, the cost of collecting and maintaining the data cannot be justified. Therefore, policies and procedures should support ensuring that data can be trusted.

Mechanisms put in place to ensure the integrity of information should prevent attacks on the storage of that data (contamination) and on its transmission (interference). Data that is altered on the network between the storage and the user's workstation can be as untrustworthy as the attacker altering or deleting the data on the storage media. Protecting data involves both storage and network mechanisms.

Attackers can use many methods to contaminate data. Viruses are the most frequently reported in the media. However, an internal user, such as a programmer, can install a back door into the system or a logic bomb that can be used attack the data. After an attack is launched, it might be difficult to stop and thus affect the integrity of the data. Some of the protections that can be used to prevent these attacks are intrusion detection, encryption, and strict access controls.

Not all integrity attacks are malicious. Users can inadvertently store inaccurate or invalid data by incorrect data entry, an incorrect decision made in running programs, or not following procedures. They can also affect integrity through system configuration errors at their workstations or even by using the wrong programs to access the data. To prevent this, users should be taught about data integrity during their information security awareness training. Additionally, programs should be configured to test the integrity of the data before storing it in the system. In network environments, data can be encrypted to prevent its alteration.

Availability

Availability is the ability of the users to access an information asset. Information is of no use if it cannot be accessed. Systems should have sufficient capacity to satisfy user requests for access, and network architects should consider capacity as part of availability. Policies can be written to enforce this by specifying that procedures be created to prevent denial-of-service (DoS) attacks.

More than just attackers can affect system and network availability. The environment, weather, fire, electrical problems, and other factors can prevent systems and networks from functioning. To prevent these problems, your organization's physical security policies should specify various controls and procedures to help maintain availability.

Yet access does not mean that data has to be available immediately. Availability of information should recognize that not all data has to be available upon request. Some data can be stored on media that might require user or operator intervention to access. For example, if your organization collects gigabytes of data daily, you might not have the resources to store it all online. This data can be stored on an offline storage unit, such as a CD jukebox, that does not offer immediate access.

Privacy

Privacy relates to all elements of the CIA triad. It considers which information can be shared with others (confidentiality), how that information can be accessed safely (integrity), and how it can be accessed (availability).

As an entity, privacy is probably the most watched and regulated area of information security. Laws, such as the U.S. Federal Privacy Act of 1974, provide statutes that limit the government's use of citizens' personal data. More recently, the Health Insurance Portability and Accountability Act (HIPAA) authorizes the Department of Health and Human Services to set the security and privacy standards to cover processing, storing, and transmitting individual's health information to prevent inadvertent or unauthorized use or disclosure.

Laws and regulations have been difficult to keep up-to-date as the technology moves forward. The federal government has been able to keep up by using directives and mandates within the executive branch. However, this has not helped private industry. Regulations, such as those mandated by the U.S. Federal Trade Commission (FTC), attempt to help, but the FTC lacks enforcement capabilities.

If not mandated by law or regulation, organizations should look at the privacy of their own information assets. Aside from having to be concerned about the privacy of employee information, an organization needs to be concerned about the disclosure of customer information that might not be regulated.

Information collected through contact, such as via the Internet, does not require a privacy statement, but the FTC does say organizations should have one. That privacy statement should reflect how the data is handled and available to the users whose information is being collected.

Monitoring privacy has other concerns. Preventing the unauthorized disclosure of data might require monitoring of data transmission between systems and users. One area of concern is the monitoring of email. Email monitoring can include content monitoring to watch for unauthorized disclosure of information. However, before doing so, an organization must ensure that policies are in place that state what might be monitored or disclosed.

Finally, security professionals introduce an additional problem to the privacy of information because of their nearly unlimited access to all resources. Although we would like to think that all professionals have integrity, some have other agendas or lack the knowledge to prevent accidental disclosure. Security professionals should be limited to the information that is necessary to perform their tasks. Policies can be created to have additional checks and balances to ensure integrity of the data.

Identification and Authentication

Information security is the process of managing the access to resources. To allow a user, a program, or any other entity to gain access to the organization's information resources, you must identify them and verify that the entity is who they claim to be. The most common way to do this is through the process of identification and authentication.

The process of identification and authentication is usually a two-step process, although it can involve more than two steps. Identification provides the resource with some type of identifier of who is trying to gain access. Identifiers can be any public or private information that is tied directly to the entity. To identify users, the common practice is to assign the user a username. Typically, organizations use the user's name or employee identification number as a system identifier. There is no magic formula for assigning usernames—it is a matter of your preference and what is considered the best way of tracking users when information appears in log files.

Understand the Principle of Authentication

Authentication is a matter of what the entity knows, what they might have, or who the entity is. For strong authentication, use at least two of these principles.

The second part of the process is to authenticate the claimed identity. The following are the three general types of authentication:

  • What the entities know, such as a personal identification number (PIN) or password

  • What the entities have, such as an access card, a smart card, or a token generator

  • Who or what the entity is, which is usually identified through biometrics

Out of these general types of authentication, if two or more are used, the authentication is called strong authentication. For physical security, a user with an access card commonly must enter a PIN. For authentication to a system or network, a common method is to use a PIN or pass code with a token generator. Although biometrics is a way to identify who the entity is, another step is still necessary to strengthen the authentication.

Passwords

Of these methods, passwords and PINs are the most common forms of authentication. Although passwords become the most important part of the process, they also represent the weakest link. As a security manager, you must manage the process in such a way to minimize the weakness in the process.

Users typically create passwords that are easily guessed. Common words or the names of spouses and children leave the password open to dictionary or social engineering attacks. To prevent these attacks, some organizations use a password generator to create passwords that cannot be cracked using typical attacks. The problem is that these passwords are usually not that memorable, which causes the users to write them down, leaving them open to another type of social engineering attack in which another user finds the documented password.

Password management involves trying to create a balance between creating passwords that cannot be guessed and passwords users don't need to write down. Policies can mandate several strategies that can be effective in mitigating some of these problems. Following are some of the methods management should use when mitigating these problems:

  • Password generators—These are usually third-party products that can be used to create passwords out of random characters. Some products can be used to create memorable passwords using permutations of random or chosen words or phrases.

  • Password checkers—These are tools that check the passwords for their probability of being guessed. They are designed to perform typical dictionary attacks, and they use information on the system in an attempt to guess the password using social engineering. These checkers also use common permutations of these attacks, anticipating what a user might try. For example, users commonly use 0s in the place of the letter o. The strength of the password is determined by how many attempts the tool makes to guess the password.

  • Limiting login attempts—These can prevent attackers from trying to log in to systems or prevent networks from using exhaustive attacks. By setting a threshold for login failures, the user account can be locked. Some systems can lock accounts for a period of time, whereas others require administrator intervention.

  • Challenge-Response—These are also called cognitive passwords. They use random questions that the user would provide the answer to in advance or use a shared secret. When the user logs in, the system picks a random question that must be answered successfully to gain access. This is commonly used on voice response systems (for example, social security number, account number, ZIP code, and so on) and requires the answer to more than one challenge.

  • Token devices—These are a form of one-time password authentication that satisfies the "what you have" scenario. Token devices come in two forms: synchronous and asynchronous. A synchronous token is time-based and generates a value that is used in authentication. The token value is valid for a set period of time before it changes and is based on a secret key held by both the token (usually a sealed device) and the server providing authentication services. An asynchronous token uses a challenge-response mechanism to determine whether the user is valid. After the user enters the identification value, the authentication server sends a challenge value. The user then enters that value into the token device, which then returns a value called a token. The user sends that value back to the server, which validates it to the username. Figure 3.2 demonstrates these steps.

  • Figure 3.2 Authentication using an asynchronous token device.

    PKI

    Using public key or asynchronous encryption technologies requires the use of a public key infrastructure (PKI) to manage the process.

  • Cryptographic keys—These combine the concepts of "something you have" and "something you know." Using public key cryptography, the user has a private key (or digital signature) that is used to sign a common hash value that is sent to the authentication server. The server can then use the known public key for the user to decrypt the hash. To strengthen the authentication process, the user is asked to enter a PIN or passphrase that is also added to the hash to strengthen the authentication process.

Nonrepudiation

Nonrepudiation is the ability to ensure that the originator of a communication or message is the true sender by guaranteeing authenticity of his digital signature. Digital signatures are used not only to ensure that a message has been electronically signed by the person who purported to sign the document, but also to ensure that a person cannot later deny that he furnished the signature.

Understanding Nonrepudiation

Nonrepudiation is the ability to ensure the authenticity of a message by verifying it using the message's digital signature. Remember, digital signatures require a certificate to generate the signature and a PKI to save the public key for when the message is verified.

One way to authenticate the digital signature is to verify it with the public key obtained from a trusted certification authority (CA). When used in PKI, the CA stores the public key that could be used to verify the signature. However, digital signatures might not always guarantee nonrepudiation. One concern is the trust of the signature and the CA. For example, some commercial CA products do not require verification of the person buying the signature but trusts that his credit card is valid. In pretty good privacy, you have to trust the signers of the user's certificate.

Regardless of how your organization tries to implement nonrepudiation, there will be some risk based on the trust of the information used for validation. Biometric verification can help in the process, but that means you must trust the certification process.

Accountability and Auditing

With the user authenticated to the system and network, most administrators use the various audit capabilities to track all system events. Systems and security administrators can use the audit records to

  • Produce usage reports

  • Detect intrusions or attacks

  • Keep a record of system activity for performance tuning

  • Create evidence for disciplinary actions or law enforcement

Accountability is created by logging the events with the information from the authenticated user, which might also include date, time, network address, and other information that could further identify the condition that caused the event. Events are audited through system and network facilities designed to help monitor from the lowest levels. These facilities also have Application Program Interfaces (APIs) that can allow applications to audit pertinent event information.

Administrators can set up auditing to capture systems events. However, if you set up auditing to capture everything, you will create logs that can take up all available disk space. Rather, you should set a parameter defining a threshold, or clipping level, of the event to be logged. Setting thresholds is typical in the configuration of intrusion detection systems (IDSs). An IDS has the tendency to log a lot of erroneous events called false positives. Setting thresholds can cut down on the number of errors logged.

The auditing of systems requires active monitoring and passive protections. Active monitoring requires administrators to watch the ongoing activities of the users. One way this can be done is via keystroke monitoring. Passive monitoring is done through the examining of audit data maintained by each system. Because the audit data is usually stored on the system, it should be protected from alteration and unauthorized access. These auditing principles are discussed in the following sections.

Keystroke Monitoring

Keystroke monitoring is a type of audit that monitors what a user types. It watches how the user types individual words, commands, or other common tasks and creates a profile of that user's characteristics. The keystroke monitor can then detect whether someone other than the profiled user tries to use the system.

Magic Lantern

The FBI has been looking at new ways of doing covert investigation of criminals on the Internet. One tool they use is called Magic Lantern. As a follow-up to the Carnivore program, the FBI covertly installs Magic Lantern on a targeted computer system to trap keystroke and mouse information. Magic Lantern has been used to break the encryption of a suspected criminal. As this is written, that case has yet to come to trial, but the constitutionality of the FBI using Magic Lantern will be a central question.

Another form of keystroke monitoring is the capture of what the user types. These types of keystroke monitors capture some of the basic user input events, allowing forensic analysis of what the user is doing. This is a more controversial form of auditing because it has been used by law enforcement in recent high-profile cases.

In either case, there are two problems with this type of auditing:

  • The generation of a lot of data

  • Privacy issues

Because of the nature of the data captured, no clipping level can be set. Therefore, you must ensure that there is enough storage for all the captured information to be stored.

Privacy issues are a concern in all types of monitoring, but especially with keyboard monitoring. Unless used by law enforcement with the proper authorization, you should ensure that your organization has the proper policies in place and users have been notified of those policies. Otherwise, you run the risk of being accused of violating a user's civil rights and liberties. Although this has not been resolved in the courts, you should not try this without the proper policies in place because you do not know what would happen if the monitored user tried to test this in court.

Protecting Audit Data

There will come a time when your organization has to handle an incident. This incident can come from within your organization's network or from the Internet. The only way you will have to figure out how the incident occurred is through log analysis. However, the analysis of the logs can be only as successful as the integrity of the data.

Operating systems have many ways of maintaining the log data integrity, including the capability to store it across a network. Maintaining the integrity of the data is important for analysis. If the incident involves an attack, law enforcement can use the data gathered by the audits to investigate and prosecute the attacker. For the audit data to be used in legal proceedings, it must be proven that the integrity of the audit data has been maintained and there was no possibility for it to be altered. In the legal world, that is called proving the chain of custody. If the prosecutor cannot prove the chain of custody, the audit data cannot be used as evidence.

There are more reasons than law enforcement, but I put the emphasis on it because, if your protection procedures can pass that test, they will pass the others. It becomes important in any situation where legal proceedings might be involved, such as firing an employee for violating policies. Audit data used in the decision can be subpoenaed if the employee sues your organization, which requires the same chain of custody rules.

Documentation

When I talk to organizations about the condition of their security documentation, most admit that it is not up-to-date. Others say that it is too accessible because it details the controls and settings of various devices. In either case, documentation can become a weak link in the security chain. By not keeping up with documentation, there could be no explanation of how the controls are configured to satisfy policies, which would make their replacement in an emergency situation difficult.

Making the documentation accessible can be a controversial issue. Some believe that the more open security is, the better it can be reviewed and hardened. Review is one thing, but some people could use this information for unscrupulous purposes. If the user who has access to the full description of the security controls is also a disgruntled employee or even someone engaging in industrial espionage, it might be in your organization's best interest to restrict access to security documentation.

Security Management Planning

Understand the principles of security management.

Planning for information security includes preparation to create information security policies that will be the guidance for the entire information security program. To create the policy, management should plan to perform a risk analysis on the information assets to be protected. The risk analysis will identify the assets, determine risks to them, and assign a value to their potential loss. Using this, management can make decisions on the policies that best protect those assets by minimizing or mitigating the risks.

The final aspect of information security management is education. Management is responsible for supporting the policy not only with its backing, but also by including policies and the backing for educating users on those policies. Through security awareness training, users should know and understand their roles under the policies. This is discussed further in the "Security Awareness Training" section, later in this chapter.

Managing an information security program changes with the release of every new operating system and with every new communications enhancement. Over the years, network technology has changed how information assets are protected. In the past, data was stored and accessed through mainframes where all the controls were centralized. Networked systems change this paradigm by distributing data across the network.

It does not help that network protocols were invented to share information and not with security in mind. In the beginning, security was left up to each system's manager in a small society of network users. As technology grew, the information assets became less centralized and management had the problem of maintaining the integrity of the network and the information being used on the systems on the networks. Although there is a move to try to centralize management of servers and information security, information security management needs to take into account everywhere the information assets touch.

Network's Importance to Security Management

Network management is also important to security management. You should understand the roles of networks and some of the tools, such as virtual private networks (VPNs) and extranets.

Network computing has brought new paradigms to the sharing of information. Using technologies such as virtual private networks (VPNs) and extranets, organizations can forge new types of relationships based on sharing information assets. These partnerships have organizations connecting their networks to share information in a way that was unheard of as recently as 10 years ago. Managers planning these partnerships also should keep in mind how to maintain the security of other information assets not involved in those agreements. Both organizations should consider undergoing a risk analysis specific to the connectivity required for this partnership to provide appropriate protections.

Risk Management and Analysis

Understand risk management and how to use risk analysis to make information security management decisions.

Risk management is the process of assessing risk and applying mechanisms to reduce, mitigate, or manage risks to the information assets. Risk management is not about creating a totally secure environment. Its purpose is to identify where risks exist, the probability that the risks could occur, the damage that could be caused, and the costs of securing the environment. Even if there is a risk to information assets, risk management can determine that it would cost more to secure the asset than if it was damaged or disclosed.

Risk management is not as straightforward as finding the risk and quantifying the cost of loss. Because risks can come from varying sources, an information asset can have several risks. For example, sales data stored on a network disk has the risk of

  • Unauthorized access from internal or external users

  • Loss from a software or hardware failure

  • Inaccessibility because of a network failure

Risk management looks at the various possibilities of loss, determines what would cause the greatest loss, and applies controls appropriately. As the risk manager, you might want to reduce all the risk to zero. This is a natural emotional reaction to trying to solve risk. However, you might find that it is impossible to prevent unauthorized access from internal users while trying to ensure accessibility of the data. Here, you must look at the likelihood of the risk and either look for other mitigations or accept it as a potential loss to the organization.

Assessing risk for information security involves considering the types of loss (risk category) and how that loss might occur (risk factor).

Risk Category

  • Damage—Results in physical loss of an asset or the inability to access the asset, such as cutting a network cable.

  • Disclosure—Disclosing critical information regardless of where or how it was disclosed.

  • Losses—These might be permanent or temporary, including the altering of data or the inability to access data.

Risk Factor

  • Physical damage—Can result from natural disasters or other factors, such as power loss or vandalism.

  • Malfunctions—The failure of systems, networks, or peripherals.

  • Attacks—Purposeful acts whether from the inside or outside. Misuse of data, such as unauthorized disclosure, is an attack on that information asset.

  • Human errors—Usually considered accidental incidents, whereas attacks are purposeful incidents.

  • Application errors—Failures of the application, including the operating system. These are usually accidental errors, whereas exploits of buffer overflows or viruses are considered attacks.

Every analyzed information asset has at least one risk category associated with one risk factor. Not every asset has more than one risk category or more than one risk factor. The real work of the risk analysis is to properly identify these issues.

Risk Analysis

Risk analysis is a process that is used to identify risk and quantify the possible damages that can occur to the information assets to determine the most cost-effective way to mitigate the risks. A risk analysis also assesses the possibility that the risk will occur in order to weigh the cost of mitigation. As information security professionals, we would like to create a secure, risk-free environment. However, it might not be possible to do so without a significant cost. As a security manager, you will have to weigh the costs versus the potential costs of loss.

Risk Analysis

Identifies a risk, quantifies the impact, and assesses a cost for mitigating the risk.

Business Versus Government Risk Analysis

A risk analysis for a government agency is no different from one performed for a nongovernment organization. The difference is how the information is used. Nongovernment entities can use the costs of mitigating the risk and the expected gain to determine whether to add countermeasures and which ones would be the most cost-effective. Most nongovernment entities work like this, including nonprofit corporations.

Because of laws, regulations, and legislative oversight, government agencies (particularly on the federal levels) have to run in a risk adverse environment rather than a risk-managed environment. Thus, agencies provide security controls that minimize the risk to a zero-cost, regardless of the costs, to prevent them from being campaign fodder. It is why the government will spend more money to secure systems than a private corporation will.

On completion of the risk analysis, the information allows the risk manager to perform a cost-benefit analysis (CBA), comparing safeguards or the costs of not adding the safeguards. Costs are usually given as an annualized cost and can be weighed against the likelihood of occurrence. As a general rule, safeguards are not employed when the costs of the countermeasure outweighs the potential loss. For example, an information asset is worth $10,000 should it be lost. Table 3.1 shows a possible analysis of this asset.

Table 3.1 BASIC RISK ANALYSIS ON A $10,000 ASSET

Cost of Countermeasure

Gain/(Loss)

Analysis

$0

($10,000)

By doing nothing, if the asset is lost, there could be a complete loss that costs $10,000.

$5,000

$5,000

If the countermeasure costs $5,000, you will gain $5,000 in providing the protection by mitigating the loss.

$10,000

$0

The cost of the countermeasure equals the cost of the asset. Here, you might weigh the potential for the countermeasure to be needed before making a decision.

$15,000

($5,000)

With the countermeasure costing more than the asset, the benefit does not make sense in this case in terms of financial cost.

For information security planning, the risk analysis allows management to look at the requirements and balance them with business objectives and the costs. For an information security program to be successful, the merging of security processes and procedures with the business requirements is essential. A major part of that is the protection of the assets, and the risk assessment helps in that analysis.

Identifying Threats and Vulnerabilities

The previous section identified the various risk categories and factors that go into a risk analysis. For that analysis to weigh the potential for a risk to occur, the analysis should identify the threats and vulnerabilities that could occur.

There is no single way to identify whether a threat or vulnerability could occur in the environment being analyzed. Most environments are so complex that a vulnerability in one area could affect another area of the business. These cascading errors could be caused not only by a malicious attack, but also by errors in processing, which are called illogical processing.

Threat Agents

These are what cause the threats by exploiting vulnerabilities.

Identifying the threats to information assets is the process of identifying the threat agents that can cause a threat to the environment. Threat agents can be human, programmatic (such as an error or malware), or a natural disaster. The risk factors in the previous section provide a view into the number of possible threat agents an asset could have. Audits look at all the potential threat agents and determine which factors result in the risk to the asset.

After the threat agents, vulnerability, and risk have been identified, the risk analysis then concentrates on the loss potential, or what would be lost if the threat agent exploited the vulnerability. Whether the loss is from corruption or deletion of data to the physical destruction of computer and network equipment, there will be a cost to the loss of the asset. The loss is not limited to the cost of the asset. Risk analysis should also consider the loss of productivity, whether it be a delay or halt in work.

Loss Potential

This is what would be lost if the threat agent is successful in exploiting a vulnerability.

Delayed Loss

This is the amount of loss that can occur over time.

Not every loss will occur immediately. Take disclosure of critical data, for example. The loss from when the data is disclosed might not happen immediately. But if the disclosure was to a competitor involved in industrial espionage, the potential loss could occur over time in the form of lost clients and business. The loss potential for this type of delayed loss can attempt to estimate the costs to recover. Because the nature of the losses are unknown, making this type of estimate can be difficult.

Another delayed loss can be embedded in the cost of business. If data that is used to calculate fees, taxes, or other fiscal obligations is corrupted, a loss potential exists for interest and penalties that would have to be paid when the problems are discovered, which will be more than the costs to repair the damage. In more extreme cases, your organization could lose the confidence of its customers and investors, which could cause additional damage.

Asset Valuation

There are two ways to evaluate assets and the risk associated with their loss. The quantitative approach attempts to assign a dollar value to the risk for analyzing the cost of the potential effectiveness of the countermeasure. A qualitative approach uses a scoring system to rank threats and effectiveness of the countermeasures relative to the system and environment. Most commercial organizations prefer the quantitative approach because it allows for a way to plan budgets and for nontechnical management to understand the impact of their decisions.

Quantitative Versus Qualitative

A quantitative approach to risk analysis uses monetary values to assess risk. The qualitative approach uses a scoring system to determine risk relative to the environment.However, a qualitative analysis is good for understanding the severity of the risk analysis relative to the environment, which is easier for some to understand.

When using the quantitative approach, you should remember that it cannot quantify every asset and every threat. When looking at the values at the extremes, whether high or low, the numbers tend to not reflect the reality of the quantitative analysis. It is up to the team doing the risk analysis to determine which approach is best.

An Internal Risk Analysis Versus Using Outside Consultants

Some might feel that their own systems and security professionals could perform the risk assessment. They do know the systems and understand the processing that occurs. However, although the people your company employs might be very competent, they might be too intimate with operations to be able to tell a technical risk from a process risk. Outsiders do not have the same ties, so they are not prejudiced by "what has been."

When selecting an outside company to do a risk assessment, make sure it has the resources to understand the latest security information and industry best practices so it can provide a complete risk assessment. It must understand all the risks involved in all aspects of information technology. Because these companies do this on a daily basis, they have more insights into what to expect as they perform their tests.

Risk analysis is an investigation into the various assets, assigning risk and determining mitigations. To do this, the risk assessment team must investigate all the assets, taking into account all the variables that can affect the costs. The steps that are followed in a risk analysis are

  1. Identify the assets.

  2. Assign value to the assets.

  3. Identify the risks and threats corresponding to each asset.

  4. Estimate the potential loss from that risk or threat.

  5. Estimate the possible frequency of the threat occurring.

  6. Calculate the cost of the risk.

  7. Recommend countermeasures or other remedial activities.

Each step is explained in Step By Step 3.1.

STEP BY STEP

3.1 Risk Analysis Steps

  1. Identify the assets. When you identify your information assets, you must consider more than the systems and network components. Information assets can also be the organization's data. A company's sales data that contains customer information and buying habits is as much of an asset as the disk and systems that store the information. Risk analysts will look at the organization's business process and ask which information is important to the business processes. In this process, more emphasis can be put on the information that is important, such as sales data, rather than the company phone book.

  2. This is where maintaining documentation and having a solid configuration management system can help. Rather than forcing a full discovery of all assets, including programs and databases, the documentation and configuration management systems can point to the bulk of the assets and provide a basis to begin the analysis. This is not to say that a risk assessment cannot be performed without this help. Some risk assessments are performed to gather this information, which is perfectly reasonable when establishing a new or more stringent information security program.

  3. Next, you must assign value to the assets. Assigning value is not a simple task. For hardware or software, the value can be the purchase or the replacement costs. Setting the value to information assets is where the process becomes difficult. To determine value, you would answer the following questions:

    • How much revenue does this data generate?

    • How much does it cost to maintain?

    • How much would it cost if the data were lost?

    • How much would it cost to recover or re-create?

    • How much would it be worth to the competition?

  4. After all the assets are identified, the analysis then identifies all the threats and risks. The various risk categories are examined, and the various factors are applied until a list of possible threats is created. There is no scientific way to determine which risk categories apply to an asset—it is a subjective determination. However, some common sense should prevail. For example, data cannot be damaged by fire, but the disks on which it resides can be. The risk for the data could be damage or unavailability because of hardware failure, which reduces a number of risk factors and potential countermeasures.

  5. The next step is to go through the various assets and the threats to estimate how much would be lost if the threat occurs. Obviously, this is easy for hardware and software because costs can be taken from invoices or actual replacement costs. But what happens when the asset is data? How much would it cost if access to critical data were lost? How much would it cost to be recovered or regenerated? What if it was improperly disclosed?

  6. When estimating the costs for the loss, all factors should be considered. For example, if workstations are infected with a virus, the cost of recovery should be counted, and so should the loss of productivity. Estimating productivity loss is not easy because the salaries and benefits for each employee affected should be considered, as well as the duration of the loss. Although a number of employees at different salary levels might work on the recovery effort, many times an estimate is based on an average salary. The numbers produced are appropriate for a risk analysis.

    The estimated cost of the potential loss is used to calculate the single-loss expectancy (SLE) for the asset. SLE uses the asset value and the exposure factor (see step 5) to give the dollar amount of the potential loss if the threat came to pass. These calculations are discussed in step 6.

    Single-Loss Expectancy (SLE)

    This is the amount of the potential loss for a specific threat.

  7. The frequency of occurrence is used to estimate the percentage of loss on a particular asset because of a threat. Also called the exposure factor (EF), this value recognizes that a threat does not result in a total loss. For example, a fiber-optic cable running between two buildings being cut by a maintenance worker affects only the cable and the productivity for its cut, which might be only 20% of the organization's infrastructure. For this asset, the EF would be 0.20 for calculations.

  8. Risk analysis is based on the loss over the course of a year. The annualized rate of occurrence (ARO) is the ratio of the estimated possibility that the threat will take place in a 1-year time frame. The ARO can be expressed as 0.0 if the threat will never occur, through 1.0 if the threat will always occur. For example, the ARO for a workstation virus might be set to 1.0, whereas a power outage to the network operations center that might occur once every 4 years would have an ARO of 0.25.

    Risk Analysis Variables

    Variables of risk analysis are annualized loss expectancy, annualized rate of occurrence, exposure factor, and single loss expectancy.

  9. Now that the collection of facts and figures has been completed, the next step is to plug in the various calculations to determine the annualized loss expectancy (ALE), which tells the analyst the maximum amount that should be spent on the countermeasure to prevent the threat from occurring. If the countermeasure costs more than the ALE, it can indicate a risk that the organization might take. This is discussed later in this chapter.

  10. To determine the ALE, each threat undergoes the following calculation:

    6.1. The SLE is calculated by multiplying the value of the asset by the EF:

    SLE = asset value x EF

    6.2. The ALE is calculated by multiplying the SLE by the ARO:

    ALE = SLE x ARO

    To illustrate these calculations, Table 3.2 has a short example with a few assets using a mythical Web server system.

    This sample organization uses a network operations center (NOC) that cost $500,000 to set up where the major threat is a fire. Should there be a fire, a 45% total loss is estimated. However, according to the fire department, the area where the NOC is located has a fire every 5 years, resulting in an ARO of 0.20. Using these values, the ALE for the NOC is $45,000.

    Similar calculations were made on the other assets. The asset values and EF were discovered as part of the audit; the ARO was also determined as part of the investigation. For example, when worried about power failure on the Web servers, the utility company was asked about the average length of outage in the area. In this example, the utility company predicted a major outage once every 2 years, thus resulting in a 0.50 ARO.

    Using the ALE, the organization has an overview of the risks, their likelihood of happening, and what would be lost if the threat occurred. It is also known how much can be spent to protect the asset against the threats. For example, protecting against a power failure on the Web servers should cost no more than $3,125. After some investigation, the cost of an uninterruptible power supply that works in the NOC is revealed to cost $4,500. A business decision could be made to not employ the counter- measure because it would cost more than the loss.

  11. The final step is to recommend countermeasures or other activities to mitigate the risk. This is the topic of the following sections.

Table 3.2 A SAMPLE CALCULATION FOR ALE

Asset

Threat

Asset Value

EF

SLE

ARO

ALE

Network operations center

Fire

$500,000

0.45

$225,000

0.20

$45,000

Web servers

Power failure

$25,000

0.25

$6,250

0.50

$3,125

Web data

Virus

$150,000

0.33

$50,000

1.00

$50,000

Customer data

Disclosure

$250,000

0.75

$187,500

0.66

$123,750

Qualitative Risk Analysis

A qualitative risk analysis is a more subjective analysis that ranks threats, countermeasures, and their effectiveness on a scoring system rather than by assigning dollar values. There are various ways of doing this from group decisions such as the Delphi method to using surveys and interviews for their ranking system.

Doing a qualitative risk analysis is a bit different from a quantitative analysis. In a quantitative analysis, the analyst does not have to be an expert in the business of the organization or have an extensive knowledge of the systems. Using her basic knowledge, she can analyze the basic business processes and use formulas to assess value to the asset and threats. Qualitative analysts are experts in the systems and the risks being investigated. They are able to use their expertise, along with the users of the system, to give the threats appropriate ranks.

To do a qualitative risk analysis, the major threats are identified and the scenarios for the possible sources of the threat are analyzed. The scores generated in this analysis show the likelihood of the threat occurring, the potential for the severity, and the degree of loss. Additionally, the potential countermeasures are analyzed by ranking them for their effectiveness.

When the analysis is completed, the scores for the threat are compared to the countermeasures. If the scores for the countermeasure are greater than the threat, it usually means that the countermeasure will be more effective in protecting the asset. However, remember that this is a subjective analysis, so the meanings of the rankings are also open to interpretation.

Countermeasure Selection and Evaluation

Organizations employ countermeasures, or safeguards, to protect information assets. In selecting the proper countermeasures, it makes good business sense to find a countermeasure that is also the most cost-effective. Determining the most cost-effective countermeasure is called a cost/benefit analysis.

A cost/benefit analysis looks at the ALE, the annual cost of the safeguard, and the ALE after the countermeasure is installed to determine whether the costs show a benefit for the organization. The calculation can be written as follows:

Value of Countermeasure = ALE (without countermeasure) – Cost (safeguard) – ALE (with countermeasure)

Using the Web server example from Table 3.2, let's say that the cost of a universal power supply (UPS)—to purchase and operate—is $1,000 per year. Even with the UPS, the exposure factor (EF) is reduced to 5% (0.05) because a power outage that lasts longer than the UPS can supply power is possible. The utility reports that an outage that will last longer than the UPS occurs once every 5 years, reducing the annual rate of occurrence (ARO) to 20% (0.20). Thus, the following calculation should be used:

    ALE (with UPS) = Cost (Web server) x EF x ARO

    ALE (with UPS) = $25,000 x $1,250 x 0.20

    ALE (with UPS) = $250

With the UPS, the ALE is now $250. Using that for the cost/benefit analysis, you can calculate the following:

    Value of countermeasure = $3,125 – $1,000 – $250

    Value of countermeasure = $1,875

With the value of the countermeasure at $1,875 and the cost at $1,000, the benefit of $875 per year for the countermeasure makes it a benefit for the organization.

One area skipped over was the operation cost of the UPS. The cost of operating the UPS can be a combination of power usage, modifications that might have been necessary to install the device, maintenance, and so on. When looking at the actual cost of the countermeasure during a cost/benefit analysis, all the costs need to be considered. If the countermeasure affects productivity, the loss must be accounted for. Should there be additional testing, those costs also must go into the cost of the countermeasure to get its true cost.

This is also not a straightforward analysis. Some threats might occur once over a period of 10 years or more. Even for expensive assets, an ARO of less than 0.10 can cause the analyst to consider whether the countermeasure is worth the cost over the entire time to prevent the threat. For example, the likelihood of an earthquake destroying the network operations center in the New York City area is very low, even in an area that has seen some earthquakes. Seismologists might think that an earthquake causing some damage would occur once every 15 years (an ARO of 6.67%). But is this enough of a threat to provide countermeasures for?

Effectiveness and Functionality of Countermeasures

Choosing a countermeasure for the amount of cost is a pure business way of analyzing risk. However, as security professionals, we understand that regardless of the cost, the countermeasure is not worth using unless it protects the asset. Information security professionals should work with business people to select the most effective counter- measure that will function to properly protect the asset.

Another consideration is countermeasures that can protect against multiple threats. That potential earthquake in New York might be mitigated by the rigorous building construction guidelines that keep buildings from toppling in high winds. In an information security context, a firewall can be used as a filter to prevent various network-based attacks and as a content filter to stop malicious mobile code.

Tying It Together

Risk assessment tells the organization what the risks are; it is up to the organization to determine how to manage the risks. Risk management is the trade-off an organization makes regarding that risk. You should remember that not every risk could be mitigated. It is the job of management to decide how that risk is handled. In basic terms, the choices are

  • Do nothing—If you do this, you must accept the risk and the potential loss if the threat occurs.

  • Reduce the risk—You do this by implementing a countermeasure and accepting the residual risk.

  • Transfer the risk—You do this by purchasing insurance against the damage.

These decisions can be made only after identifying the assets, analyzing the risk, and determining countermeasures. Management uses these steps to make the proper decisions based on the risks found during this process. Figure 3.3 illustrates these steps.

Figure 3.3 The three steps of a risk analysis.

Residual Risk

This is the value of the risk after implementing the countermeasure.

Policies, Standards, Guidelines, and Procedures

Know how to set policies and how to derive standards, guidelines, and implement procedures to meet policy goals.

Part of information security management is determining how security will be maintained in the organization. Management defines information security policies to describe how the organization wants to protect its information assets. After policies are outlined, standards are defined to set the mandatory rules that will be used to implement the policies. Some policies can have multiple guidelines, which are recommendations as to how the policies can be implemented. Finally, information security management, administrators, and engineers create procedures from the standards and guidelines that follow the policies. Figure 3.4 shows the relationships between these processes. The rest of this section discusses how to create these processes.

Figure 3.4 The relationships of the security processes.

Information Security Policies

Information security policies are high-level plans that describe the goals of the procedures. Policies are not guidelines or standards, nor are they procedures or controls. Policies describe security in general terms, not specifics. They provide the blueprints for an overall security program just as a specification defines your next product.

Questions always arise when people are told that procedures are not part of policies. Procedures are implementation details; a policy is a statement of the goals to be achieved by procedures. General terms are used to describe security policies so that the policy does not get in the way of the implementation. For example, if the policy specifies a single vendor's solution for a single sign-on, it will limit the company's ability to use an upgrade or a new product. Although your policy documents might require the documentation of your implementation, these implementation notes should not be part of your policy.

Specifications

Information security policies are the blueprints, or specifications, for a security program.

Although policies do not discuss how to implement information security, properly defining what is being protected ensures that proper control is implemented. Policies tell you what is being protected and what restrictions should be put on those controls. Although product selection and development cycles are not discussed, policies should help guide you in product selection and best practices during deployment. Implementing these guidelines should lead to a more secure environment.

How Policies Should Be Developed

Before policy documents can be written, the overall goal of the policies must be determined. Is the goal to protect the company and its interactions with its customers? Or will you protect the flow of data for the system? In any case, the first step is to determine what is being protected and why it is being protected.

Policies can be written to affect hardware, software, access, people, connections, networks, telecommunications, enforcement, and so on. Before you begin the writing process, determine which systems and processes are important to your company's mission. This will help you determine what and how many policies are necessary to complete your mission. After all, the goal here is to ensure that you consider all the possible areas in which a policy will be required.

Define What Policies Need to Be Written

Information security policies do not have to be a single document. To make it easier, policies can be made up of many documents—just like the organization of this book (rather than streams of statements, it is divided into chapters of relevant topics). So, rather than trying to write one policy document, write individual documents and call them chapters of your information security policy. By doing so, they are easier to understand, easier to distribute, and easier to provide individual training with because each policy has its own section. Smaller sections are also easier to modify and update.

How many policies should you write? I hate to answer a question with a question, but how many areas can you identify in your scope and objectives? For each system within your business scope and each subsystem within your objectives, you should define one policy document. It is okay to have a policy for email that is separate from one for Internet usage. It is not a problem to have a policy for antivirus protection and a separate policy for Internet usage. A common mistake is trying to write a policy as a single document using an outline format. Unfortunately, the result is a long, unmanageable document that might never be read, let alone gain anyone's support. Table 3.3 has a small list of the policies your organization can have.

Table 3.3 SAMPLE LIST OF POTENTIAL POLICIES

User and Physical Policies

Access Control Policies

External Access Policies

Acceptable Use

Authentication and Access Controls Encryption

Internet Security

Network Architecture

Public Key Infrastructures

VPN Access

Physical Security

 

Web and Internet Email

Identify What Is to Be Protected

If you remember that computers are the tools for processing the company's intellectual property, that the disks are for storing that property, and that the networks are for allowing that information to flow through the various business processes, you are well on your way to writing coherent, enforceable security policies.

The following is an example of what can be inventoried:

  • Hardware

  • Software

  • Network equipment

  • Diagnostic equipment

  • Documentation

  • Information assets

  • Preprinted forms

  • Human resource assets

It is important to have a complete inventory of the information assets supporting the business processes. The best way to create this list is to perform a risk assessment inventory. However, other methods, such as using purchase information, are available Regardless of the methods used, you should ensure that everything is documented. Inventories, like policies, must go beyond the hardware and software. There should be a list of documentation on programs, hardware, systems, local administrative processes, and other documentation that describes any aspect of the technical business process. These documents can contain information regarding how the business works and can show areas that can be attacked. Remember, the business processes can be affected by industrial espionage as well as hackers and disgruntled employees.

Similarly, the inventory should include all preprinted forms, paper with the organization's letterhead, and other material with the organization's name used in an "official" manner. Using blank invoices and letterhead paper allows someone to impersonate a company official and use the information to steal money or even discredit the organization. So, include those supplies in the inventory so policies can be written to protect them as assets.

The most important and expensive of all resources are the human resources who operate and maintain the items inventoried. Performing an inventory of the people involved with the operations and use of the systems, data, and noncomputer resources provides insight into which policies are necessary.

Creating an inventory of people can be as simple as creating a typical organizational chart of the company. This can be cumbersome, however, if you are including a thousand, or even a few hundred, people in one document. Moreover, organizational charts are notoriously rigid and do not assume change or growth. The inventory, then, could include the type of job performed by a department, along with the level of those employees' access to the enterprise's data.

Identify from Whom It Is Being Protected

Defining access is an exercise in understanding how each system and network component is accessed. Your network might have a system to support network-based authentication and another supporting intranet-like services, but are all the systems accessed like this? How is data accessed amongst systems? By understanding how information resources are accessed, you should be able to identify on whom your policies should concentrate. Some considerations for data access are

  • Authorized and unauthorized access to resources and information

  • Unintended or unauthorized disclosure of information

  • Enforcement procedures

  • Bugs and user errors

Primarily, the focus should be on who can access resources and under what conditions. This is the type of information that can be provided during a risk analysis of the assets. The risk analysis then determines which considerations are possible for each asset. From that list, policies can then be written to justify their use.

Setting Standards

When creating policies for an established organization, there is an existing process for maintaining the security of the assets. These policies are used as drivers for the policies. For other policies in which there are no technology drivers, standards can be used to establish the analysts' mandatory mechanisms for implementing the policy.

Regardless of how the standards are established, by setting standards, policies that are difficult to implement or that affect the entire organization are guaranteed to work in your environment. Even for small organizations, if the access policies require one-time-use passwords, the standard for using a particular token device can make interoperability a relative certainty.

Creating Baselines

Baselines are used to create a minimum level of security necessary to meet policy requirements. Baselines can be configurations, architectures, or procedures that might or might not reflect the business process but that can be adapted to meet those requirements. You can use these baselines as an abstraction to develop standards.

Most baselines are specific to the system or configuration they represent, such as a configuration that allows only Web services through a firewall. However, like most baselines, this represents a minimum standard that can be changed if the business process requires it. One example is to change the configuration to allow a VPN client to access network resources.

Guidelines

Standards and baselines describe specific products, configurations, or other mechanisms to secure the systems. Sometimes security cannot be described as a standard or set as a baseline, but some guidance is necessary. These are areas where recommendations are created as guidelines to the user community as a reference to proper security. For example, your policy might require a risk analysis every year. Rather than require specific procedures to perform this audit, a guideline can specify the methodology that is to be used, leaving the audit team to work with management to fill in the details.

Setting and Implementing Procedures

The last step before implementation is creating the procedures. Procedures describe exactly how to use the standards and guide- lines to implement the countermeasures that support the policy. These procedures can be used to describe everything from the configuration of operating systems, databases, and network hardware to how to add new users, systems, and software. As was illustrated in Figure 3.4, procedures should be the last part of creating an information security program.

Procedures are written to support the implementation of the policies. Because policies change between organizations, defining which procedures must be written is impossible. For example, if your organization does not perform software development, procedures for testing and quality assurance are unnecessary. However, some types of procedures might be common amongst networked systems, including

  • Auditing—These procedures can include what to audit, how to maintain audit logs, and the goals of what is being audited.

  • Administrative—These procedures can be used to have a separation of duties among the people charged with operating and monitoring the systems. These procedures are where you can show that database administrators should not be watching the firewall logs.

  • Access control—These procedures are an extension of administrative procedures that tell administrators how to configure authentication and other access control features of the various components.

  • Configuration—These procedures cover the firewalls, routers, switches, and operating systems.

  • Incident response—These procedures cover everything from detection to how to respond to the incident. These procedures should discuss how to involve management in the response as well as when to involve law enforcement.

  • Physical and environmental—These procedures cover not only the air conditioning and other environmental controls in rooms where servers and other equipment are stored, but also the shielding of Ethernet cables to prevent them from being tapped.

Implementation of these procedures is the process of showing due diligence in maintaining the principles of the policy. Showing due diligence is important to demonstrate commitment to the policies, especially when enforcement can lead to legal proceedings. Demonstrating commitment also shows management support for the policies. When management does not show this type of commitment, the users tend to look upon the policies as unimportant. When this happens, a disaster will eventually follow.

When enforcing the policies can lead to legal proceedings, an air of noncompliance with the policies can be used against your organization as a pattern showing selective enforcement and can question accountability. This can destroy the credibility of a case or a defense that can be far reaching—it can affect the credibility of your organization as well.

Showing due diligence can have a pervasive effect. Management supporting the administrators showing the commitment to the policies leads to the users taking information security seriously. When everyone is involved, the security posture of your organization is more secure. This does require the users to be trained in the policies and procedures, however. Therefore, training is part of the overall due diligence of maintaining the policies and should never be overlooked. To be successful, resources must be assigned to maintain a regular training program.

Examining Roles and Responsibility

Set information security roles and responsibilities throughout your organization.

Everyone has a role and is responsible for maintaining security in the information security process. The most important role belongs to management, who must set the tone for the entire information security program. This is not to diminish the roles of administrators and users, but without the appropriate management support, users will not take these efforts seriously.

Although information security professionals will have a more difficult time convincing users to participate in the security process, it does not absolve their responsibilities. Those whose role it is to be responsible for maintaining the information security environment should understand the roles of everyone in the organization and balance security of the information assets with the requirements of the business processes.

Management Responsibility

Know what management's responsibility is in the information security environment.

Management's responsibility goes beyond the basics of support. It is not enough just to bless the information security program; management must own up to the program by becoming a part of the process. Becoming part of the process involves showing leadership in the same manner that managers show leadership in other aspects of the organization.

Management has specific goals for the organization, and most security and information system professionals are not in the position to understand or appreciate these nuances. Because security is not something that can be wrapped into a package and bought off the shelf, management must drive the attitudes for creating a good security program. This can only come after the analysis of risks, costs, and the requirements to ensure that information is not too secure to access. Management is responsible for doing the analysis and conveying this to the technical people responsible for implementing these policies.

User Information Security Responsibilities

One way to ensure that every current and future employee or user knows that security is part of his job function is to make it part of each job description. Spelling out the security function or expectations within the job description demonstrates the commitment to information security, as well as emphasizes that it is part of the job. After it is made part of the job description, it becomes something that can be considered in performance evaluations.

Outside contractors, vendors, or other people who provide external services directly on the company's network should include similar language within their statements of work. As with employees, this reinforces the company's commitment as well as makes the contractors' or vendors' adherence to the organization's security requirements a factor in their quality-of-service evaluations.

Socializing the Acceptable Usage Policy

One common method to ensure compliance is to have anyone who accesses the network read and sign the Acceptable Usage Policy before being given access to the systems and networks. This way, users are given the opportunity to understand the policies and ask questions so they know what their expectations are.

IT Roles and Responsibilities

The information technology (IT) staff is responsible for implementing and maintaining organization-wide information security policies, standards, guidelines, and procedures. They should provide input into security awareness education programs and ensure that everyone knows her role in maintaining security. Simply, IT provides the mechanisms that support the security program outlined by the policy.

This department must be able to strike a balance between education and enforcement, although that can be difficult. They should be viewed as a partner in the business process. If implemented as an enforcement-only group, the IT group will be feared. Fear can elicit adverse reactions to their real purpose, which can undermine the purpose of these policies. Additional training can help the technology people understand their place in the environment.

Other Roles and Responsibilities

For any information security program to be successful, it must be integrated into every aspect of the environment. Integration must include statements of work and responsibilities within the business environment, job descriptions, and how these will be audited and monitored.

A primary task in assigning roles in the information security process is how information security integrates into the business environment. As part of that integration, jobs that support security through the processes should be defined. For example, one way to do this is to define a separation of duties and control over company assets by coordinating efforts with everyone, including owners of data and facilities. By having these defined as part of the business process, there is no ambiguity as to who is responsible and when.

Another role to consider is how security is administered throughout the organization. A typical environment should have a central information security management group. The central group is in charge of the monitoring and enforcement of the policy and procedures whose membership would come from the organization's stakeholders. The closer placement of security enforcement with the stakeholders can help with the control of real-time connections with third parties. These liaisons can be responsible for educating these outsiders as well as monitoring and providing enforcement.

This, however, is not a perfect solution. Some people who work in this environment for an extended period might find ways to abuse the system and exploit it, for whatever reason. One way to combat this is to not allow a person to be the security liaison for more than a short period of time—one or two years, for example. At the end of the term, they pass the job to someone else.

The final area that should have a role in the information security process is the software development cycle. Whether software is developed internally or by contractors, or if the organization purchases commercial off-the-shelf (COTS) products, the goal should be to build secure systems wherein errors or manipulations can be trapped. Policy for coding and testing standards also can assist in the quality assurance process.

Understanding Protection Mechanisms

Understand how the various protection mechanisms are used in information security management.

Protection mechanisms are used to enforce layers of trust between security levels of a system. Particular to operating systems, trust levels are used to provide a structured way to compartmentalize data access and create a hierarchical order. These protection mechanisms are used to protect processes and data and are discussed in the following sections:

  • Layering

  • Abstraction

  • Data Hiding

  • Encryption

Layering

Most systems use a form of layering as a way to protect system resources. A traditional kernel-based operating system, such as Unix, uses a two-layer approach in which the system resources are managed in a protected kernel and everything else runs in an outer layer known as the user's space. If a process running in the user's space wants to access a protected resource, such as the disk, it makes a request to the kernel layer to perform the action.

Layering is specific to protecting operating system resources and to setting security zones. Systems used for military applications are designed to allow access to classified information based on the protection zone within which they are allowed to run. To do this, the Bell-LaPadula protection model was developed. Using this multilayer system, the different zones are used to keep data classified within a particular zone (see Figure 3.5). Users must have access to the zone to use the data, and the data cannot be moved between zones without special permission. This lattice of rights is also called "no write down" and "no read up." See Chapter 1, "Access Control Systems and Methodology," for more information on the Bell-LaPadula protection mode.

Figure 3.5 The layered zones of the Bell-LaPadula protection module.

Layering is not as common in newer operating systems. Most current operating systems rely on a set of roles and responsibilities that can simulate the layered approach. However, some specialized layered operating systems are still in use in military applications.

Abstraction

Abstraction is a common term in the world of object-oriented design. It is when data is managed as a collection called an object. Objects are usually defined as classes that define the data and the methods that can be used to access the object. Methods provide a predictable way to access the object's data, which allows the entire data within the class to be managed as a unit that can enforce access controls and integrity of the data.

Data Hiding

Sometimes access to data should not be provided—for example, data values within an application module that are used for internal calculations. In this case, no access methods are provided as an interface to this data. This is called data hiding because the data is hidden and inaccessible from the other layers.

Encryption

Cryptography is the science of creating algorithms used to encrypt data for the storage or transmission of data. Encryption uses those algorithms to convert data into an unintelligible form. In basic terms, encryption uses a secret key, a private value, to perform a mathematical function on the data to make it unusable by the casual observer. Traditionally, the same key is required to encrypt and decrypt the data. This is called symmetric encryption.

Public key cryptography is similar except that the mathematical functions can use two different but mathematically related keys. The functions generate two keys: One is kept private, and one can be given out publicly. If someone wants to send you an encrypted file, she encrypts it with your public key. Once encrypted, you can only use the private key to decrypt the message. This is called asymmetric encryption.

Encryption

Encryption is used in many areas. VPN communications are usually secured using symmetric encryption algorithms, such as the Data Encryption Standard (DES) or Triple-DES. Symmetric algorithms are used in these areas because the connections are well-defined and the exposures to the secret keys are limited.

Asymmetric encryption is used for mechanisms such as secure HTTP and email because of the multiple exposures to the keys. The public keys used in algorithms such as Secure Socket Layer (SSL) and Pretty Good Privacy (PGP) can be passed at will without worrying about compromising the encrypted channels. That can happen only if the secret key is disclosed or stolen.

Creating protection mechanisms using encryption requires several policy issues, including legal, management, and usability issues. If your organization is doing its work for the federal government, you have to consider federal standards mandated for using encryption. Encryption can be a good choice for keeping data secret, a lot of considerations must be made. For more on encryption and other cryptography issues, see Chapter 5.

Classifying Data

Understand the considerations and criteria for classifying data.

Throughout this chapter, we have discussed various aspects of protecting information assets. When we talk about risk analysis and management, we talk about the most cost-effective way of protecting the information asset. Part of setting the level of risk associated with data is placing it in a classification. After data is classified, a risk analysis can be used to set the most cost-effective ways of protecting that data from various attacks.

Classifying data is supposed to tell you how the data is to be protected. More sensitive data, such as human resources or customer information, can be classified in a way that shows that disclosure has a higher risk. Information data, such as those used for marketing, would be classified at a lower risk. Data classified at a higher risk can create security and access requirements that do not exist for lower risks, which might not require much protection altogether.

Commercial Classification

Classification of commercial or nongovernment organizations does not have a set standard. The classification used is dependent on the overall sensitivity of the data and the levels of confidentiality desired. Additionally, a nongovernment organization might consider the integrity and availability of the data in its classification model.

There is no formula in creating the classification system—the system used is dependent on the data. Some organizations use two types of classification: confidential and public. For others, a higher granularity might be necessary. Table 3.4 contains a typical list of classifications that can be used for commercial organizations, from highest to lowest.

Table 3.4 COMMERCIAL DATA CLASSIFICATIONS FROM HIGHEST TO LOWEST

Classification

Description

Sensitive

Data that is to have the most limited access and requires a high degree of integrity. This is typically data that will do the most damage to the organization should it be disclosed.

Confidential

Data that might be less restrictive within the company but might cause damage if disclosed.

Private

Private data is usually compartmental data that might not do the company damage but must be keep private for other reasons. Human resources data is one example of data that can be classified as private.

Proprietary

Proprietary data is data that is disclosed outside the company on a limited basis or contains information that could reduce the company's competitive advantage, such as the technical specifications of a new product.

Public

Public data is the least sensitive data used by the company and would cause the least harm if disclosed. This could be anything from data used for marketing to the number of employees in the company.

Government Classification

Government classification of data is something created out of policy for maintaining national security or the privacy of citizen data. Military and intelligence organizations set their classifications on the ramifications of disclosure of the data. Civilian agencies also look to prevent unauthorized disclosure, but they also have to consider the integrity of the data.

Classifications for Sensitive Data

The classifications for the sensitivity of data used in government and military applications are top secret, secret, confidential, sensitive but unclassified, and unclassified.

The implementation of the classification is based on laws, policies, and executive directives that can be in conflict with each other. Agencies do their best to resolve these conflicts by altering the meaning of the standard classifications. Table 3.5 explains the types of classifications used by government civilian and military organizations.

Table 3.5 GOVERNMENT DATA CLASSIFICATIONS FROM HIGHEST TO LOWEST

Classification

Description

Top Secret

Disclosure of top secret data would cause severe damage to national security.

Secret

Disclosure of secret data would cause serious damage to national security. This data is considered less sensitive than data classified as top secret.

Confidential

Confidential data is usually data that is exempt from disclosure under laws such as the Freedom of Information Act but is not classified as national security data.

Sensitive But Unclassified (SBU)

SBU data is data that is not considered vital to national security, but its disclosure would do some harm. Many agencies classify data they collect from citizens as SBU. In Canada, the SBU classification is referred to as protected (A, B, C).

Unclassified

Unclassified is data that has no classification or is not sensitive.

Criteria

After the classification scheme is identified, the organization must create the criteria for setting the classification. No set guidelines exist for setting the criteria, but some considerations are as follows:

  • Who should be able to access or maintain the data?

  • Which laws, regulations, directives, or liability might be required in protecting the data?

  • For government organizations, what would the effect on national security be if the data were disclosed?

  • For nongovernment organizations, what would the level of damage be if the data was disclosed or corrupted?

  • Where is the data to be stored?

  • What is the value or usefulness of the data?

Creating Procedures for Classifying Data

Using this information, your organization can create a procedure for classifying data. Government organizations already have this procedure defined. Nongovernment organizations have a lot of flexibility in setting the procedures that best suit their needs. Step By Step 3.2 is an example of a procedure your organization can use.

STEP BY STEP

3.2 Creating Data Classification Procedures

  1. Set the criteria for classifying the data.

  2. Determine the security controls that will be associated with the classification.

  3. Identify the data owner who will set the classification of the data.

  4. Document any exceptions that might be required for the security of this data.

  5. Determine how the custody of the data can be transferred.

  6. Create criteria for declassifying information.

  7. Add this information to the security awareness and training programs so users can understand their responsibilities in handling data at various classifications.

Employment Policies and Practices

Determine how employment policies and practices are used to enhance information security in your organization.

Although the first concern of management might be employees and employment policies, these seem to be the last concerns of information security management. Although various research groups say that most of the threats to information assets are from internal users, employment policies can be used to protect information security assets by setting guidelines for the following:

  • Background checks and security clearances

  • Employment agreements and hiring and termination practices

  • Setting and monitoring of job descriptions

  • Enforcement of job rotation

Background Checks and Security Clearances

Those who work for the federal government, whether as an employee or a contractor, know the rigors that go into background checks and security clearances. If you work for an agency or the military where a national security clearance is required, you probably had to fill out an extensive questionnaire that could have been verified through interviews and polygraphs. Despite some high-profile cases of personnel security lapses, the federal government does try to check everyone with access to sensitive information.

Many nongovernment organizations do not need the same type of background checks as the federal government does. However, having some type of background check should be part of the application process. Minimally, the organization should verify previous employment and other basic information provided as part of the application. For those in more sensitive positions, such as administrators and information security professionals, a further check into someone's background might be a consideration. As long as the checks are disclosed, an organization can request access to credit and criminal records to verify the applicant's suitability for her position. Organizations can even hire an outside firm that performs these checks as well as those that examine other public records to determine whether the potential for a problem or a conflict of interest exists.

Regardless of the checks your organization performs, the policies and guidelines must be disclosed to the applicant and employee. Although the government has policies for recertification security clearances, if your organization wants to do the same, that has to be disclosed to the employee. Many aspects of this are covered by federal, state, and local statues and civil rights laws and should be cleared with an attorney before implementing.

Employment Agreements, Hiring, and Termination

In nearly every job I have had, there has been at least one employment agreement that says I will not violate policies and will maintain the integrity of the information for which I am being trusted. Other policies have included nondisclosure and intellectual property agreements. Whatever makes sense for your organization, these agreements should be presented to the new employee when he first arrives for work.

Employment agreements are used to protect the organization from something the employee can do. It is a protection from the insider threat. Agreements can also provide the organization a means by which to discipline employees if an enforcement action is necessary. By having the employee sign the agreements, the organization has the ability to enforce the policies behind them by showing that the employee was notified of what was expected from him.

The Acceptable Usage Policy

The acceptable usage policy (AUP) is a document that summarizes the overall information security policy for the users. The AUP can contain parts of the organization's policies outlining the user's security responsibilities. Most of the time, they are highlighted components and written in plain language. A successful AUP is short and to the point. Ideally, the AUP should be only a few pages long.

Usually, the AUP is a signed document that acts as an agreement to abide by the information security policies it represents. It can be given to the new employee, contractor, or vendor with access to the network to ensure he knows his responsibilities. The purpose is to draw attention to the policy documents without requiring the new user to read them. The AUP should say that the users will abide by the policies, but the AUP can be seen as a "quick start" document to allow users to read the full policy later.

Termination

There will come a time when an employee or a contractor is no longer associated with the organization. Regardless of whether the termination is from voluntary or involuntary means, administrators must have procedures in place to revoke access to the organization's resources. Keeping a user's identification active might leave the network open for attack, and just deleting the user's information can destroy potential information assets.

Regardless of the procedures used, they should consider immediate revocation of access to the networks. Additionally, personnel policies should be adjusted to ensure employees do not have the type of access to the systems, network, and physical facilities to do damage. Even for contractors whose contracts have expired or been terminated, it might be a good idea to have a manager or security guard escort the former employee out of the building. During the process, someone should collect the employee's identification badges, keys, and other access control devices; disconnect his phone; turn off his email; lock his intranet account; and so on.

As part of the procedures, everyone must work together. If those responsible for terminating network access are not told that an employee was terminated, the network can be left open to attack by a disgruntled former employee. An improperly executed procedure makes everyone responsible for an adverse reaction.

Job Descriptions

Job descriptions are usually associated with requisitions and advertisements used to fill jobs within the organization. In the information security context, job descriptions define the roles and responsibilities for each employee. Within those roles and responsibilities, procedures are used to set the various access controls to ensure that the user can get access only to the resources he is allowed to access.

During periodic audits and monitoring, a user who might be accessing information beyond his job description might be an indication of a problem. For example, a contractor working on the development of the new Web system should not be able to access accounting data. The danger to this is when the job descriptions are not properly maintained. If a job description is informally changed without changing the official job description, there can be problems trying to enforce policies. It would help if there were a policy to change job descriptions before changing access control lists.

Job Rotation

Job rotation is the concept of not having one person in one position for a long period of time. The purpose is to prevent a single individual from having too much control. Allowing someone to have total control over certain assets can result in the misuse of information, the possible modification of data, and fraud. By enforcing job rotation, one person might not have the time to build the control that could place information assets at risk.

Another part of job rotation should be to require those working in sensitive areas to take their vacations. By having some of the employees leave the work place, others can step in and provide another measure of oversight. Some companies, such as financial organizations, require their employees to take their vacations during the calendar or fiscal year.

Managing Change Control

Use change control to maintain security.

The security impact of change control and configuration management is to know the present configuration of the system and it components. By knowing what is supposed to be in the system and network, administrators can identify whether security has been violated and rogue programs have been installed on the system.

Change Control, Configuration Management, and Revision Control

These are all similar phrases that describe the maintenance and tracking of changes to hardware and software.

One of the key security aspects of revision control and configuration management is the capability to track changes. If problems occur, administrators can examine the system in the context of the software and other installed components to see what might have caused the problem. The first step in creating these traces is to have a policy that mandates a formal change control procedure for all hardware and software systems. This policy should provide for written requests to perform system changes that can include a review for security. Using the policy as the base, the standards and procedures can be written to support the processes that log every change to any information component.

Hardware Change Control

Ideally, every time new hardware and configurations are added to the network, an entry is made to a change control system to track what has occurred. Considering that this is rarely the case, the best way to start this process is to use the risk analysis to determine the hardware inventory. With the hardware inventory, an effort should be made to place the configurations under change management control. Many organizations use the same procedures as software change management to track the changes of the configuration of the various systems. They realize that it is critical to maintain the configuration of firewalls, switches, and intrusion detection systems to ensure that someone does not change them to cover up her bad intentions.

Hardware change control does not just keeping track of system and network components. Documentation should also be kept up-to-date on the network configuration, including information on where the network and telephone cables are located. Undocumented network segments might not be protected or can be used to support insider hacking capabilities. Additionally, you might want to document the various telecommunication access points into the network. Unknown and unprotected modems can be used by anyone with access to a telephone to gain access using the software on the user's desktop, which might not be properly configured to protect the network.

Software Change Control

Software change control can have a few components. The most common topic of change control is what is used to track software development. In this case, the change management system can be used to re-create software to a certain revision to roll back from changes that might have caused security concerns or bugs.

Importance of Change Control

Change control on software systems can prevent unauthorized changes to those products. Untested patches can introduce bugs and other vulnerabilities that can be exploited.

Change control can be used to track vendor software changes. It can be considered inevitable that installed software will have bugs. Some of these bugs can be an inconvenience in operations, whereas others have security implications. It has been a source of debate among security and systems administration professionals as to how to handle fixing the software that has security problems. On one hand there is the need to fix the problem immediately to prevent problems. However, installing patches, even from a vendor, can lead to unpredicted results.

Large organizations have the capability to create test systems to test these changes before installing them into the production environment. Smaller organizations, though, might not have this luxury and might have to patch production systems. Whatever the size of your organization, having policies and procedures in place to track these changes will help you maintain the configuration of your software systems.

Security Awareness Training

Know what is required for Security Awareness Training.

The importance of security awareness training and education cannot be overstated. By taking the policy, standards, and procedures and teaching all the stakeholders about their roles in maintaining the security environment, they will embrace the policy as an integral part of their jobs. This is not easy. One problem is that over the last decade, the commitment to security by industry-leading companies has been viewed as lacking. The results are products that have insufficient security measures being installed into environments that further weaken the information security program. The dichotomy can be confusing.

Security awareness training requires clear communication. One thing you might consider for your organization is hiring a technically competent communicator for the security department. This person would do the training, educate the department to the concerns of its users, and act as a liaison between users and the department. Having someone who can communicate helps raise the confidence level users should have for the department.

Mandating that training be required for anyone with access to an organization's information assets is reasonable. Human resources should have complete records, including information on training courses required and taken as well as all signed documents showing acceptance of defined corporate policies.

Management should not only set aside time for training, but also encourage it. One company I was involved with mandated training during specific time periods, and unless employees were involved with a client or were ill, they were required to attend. This policy allowed the employee to be suspended without pay until she attended the course or watched it on videotape. You might not want to go to this extreme, but it is a good way to get 100% compliance.

Understanding the management role of information security means understanding how the information security process interfaces with the rest of the organization. It is not enough to just set policies—security is a process that must be molded into the business process to support its functions. Management must support these processes with commitment and training.

Understanding what is to be protected is an important beginning of the management process. A risk analysis is used to determine the information assets that need to be protected and how they can be best protected. The risk analysis takes into consideration the costs of the assets to determine not only the countermeasures, but also whether the assets are worth protecting.

Using this information, policies, guidelines, standards, and procedures can be created to reach the security goals. Policies can be described as the goals of the information security program. Guidelines are suggestions, and standards are the specific security mechanisms that can be used. Procedures use the guidelines and standards to implement the policies.

Access methods and protection mechanisms are used to manage the access and movement of data. A typical access method paradigm is to set the roles and responsibilities for access to the data. Protection mechanisms are used to compartmentalize access to data and processes. Layers are used to prevent unauthorized access to protected resources and data, whereas abstraction and data hiding are used to protect data.

Knowing who your users are is as important as setting their access rights to information assets. Employment policies enforce background checks during the hiring process to prevent hiring those who might be security risks. They can also set termination procedures to prevent the terminated user from destroying systems and data out of malice.

Change control and configuration management can be used to prevent unauthorized changes to the network. Change control policies can be used to maintain the configuration of all information assets to prevent them from being used to attack your organization.

The only way to really demonstrate management support of the policies and procedures is to require and support security awareness training. Through training, users come to understand their roles and responsibilities in the security environment. Training is the only way for the users to understand their responsibilities.

Chapter Summary

KEY TERMS

  • Abstraction

  • Access control

  • Accountability

  • Annualized loss expectancy

  • Annualized rate of occurrence

  • Asset valuation

  • Audit

  • Authentication

  • Authorization

  • Availability

  • Awareness training

  • Baselines

  • Change control

  • Confidentiality

  • Configuration management

  • Countermeasures

  • Cryptographic keys

  • Data classification

  • Data hiding

  • Encryption

  • Exposure factor

  • Guidelines

  • Identification

  • Incident response

  • Integrity

  • Layering

  • Nonrepudiation

  • Password

  • Policies

  • Procedures

  • Responsibilities

  • Revision control

  • Risk analysis

  • Risk management

  • Roles

  • Single loss expectancy

  • Tokens

Apply Your KnowledgeExercises

3.1 Making Information Security Management Decisions

A good way to understand the management responsibilities of information security is to look at an aspect of a risk assessment and determine the best course of action. The following questions are designed to lead you down the decision path.

Estimated Time: 30–45 minutes

  1. Your organization uses a dial-in terminal service to support customer service. The system consists of 21 inbound telephone lines and 3 outgoing lines. When calculating the risk because of an outage, the annualized loss expectancy (ALE) is $350,000. As a countermeasure, it has been decided to look into installing another telephone circuit and modem bank. The cost for this new installation is estimated to be $350,000, but it will lower the ALE to $25,000. Is this a cost-effective countermeasure? Why?

  2. For the previous question, which policy statement(s) should be written to support your decision?

  3. Which policy statement(s) could be written that would cover the usage of the outbound modems?

  4. How would you ensure that everyone knows and follows these policies, aside from awareness training?

Review Questions

  1. What are information security's fundamental principles?

  2. What is the method for a system to know who is accessing its resources?

  3. What is nonrepudiation?

  4. What is the purpose of performing a risk analysis?

  5. What are the categories of risks that are looked at during a risk analysis?

  6. How are information security procedures formed?

  7. The Bell-LaPadula security model uses what mechanism to protect system resources?

  8. What is the difference between synchronous and asynchronous encryption technologies?

  9. What is the purpose of classifying data?

  10. In the context of information security, why would an organization do a background check and have an employee sign an employment agreement?

Exam Questions

  1. How do you calculate the annualized loss expectancy of a particular risk?

    1. SLE x ARO

    2. Cost of asset – Cost of Safeguard

    3. Asset value x EF

    4. EF x ARO

  2. What is an information security policy?

    1. Guidelines used to define a security program

    2. Procedures for configuring firewalls

    3. Management's statements outlining its security goals

    4. Risk management procedures

  3. A security program is a balance of what?

    1. Risks and countermeasures

    2. Access controls and physical controls

    3. Firewalls and intrusion detection

    4. Technical and nontechnical roles

  4. Which statement is true when considering the information security objectives that the military would use versus the objectives used for commercial systems?

    1. A military system requires higher security because the risks are greater.

    2. Military systems base their controls on confidentiality, whereas commercial systems are based on availability and data integrity.

    3. Only the military can make systems really secure.

    4. Military systems base their controls on availability and data integrity, whereas commercial systems are based on confidentiality.

  5. What does a risk analysis show management?

    1. The amount of money that could be lost if security measures are not implemented

    2. How much a countermeasure will cost

    3. The cost benefit of implementing a countermeasure

    4. The amount of money that can be saved if security is implemented

  6. Who has the responsibility to determine the classification level for information?

    1. Users

    2. Management

    3. Data owners

    4. Security administrators

  7. Why should the team performing a risk analysis be formed with representatives from all departments?

    1. To ensure everyone is involved.

    2. To ensure that all the risk used in the analysis is as representative as possible.

    3. The risk analysis should be performed by an outside group and not by biased insiders.

    4. To hold those accountable for causing the risk.

  8. Which of the following is not a basic principle of authentication?

    1. What the entity knows

    2. Where the entity is

    3. Who the entity is

    4. What the entity may have

  9. What is the purpose of designing a system using the Bell-LaPadula model?

    1. To hide data from other layers

    2. To manage data and methods as objects

    3. To convert data to something that cannot be read

    4. To separate resources of a system into security zones

  10. Managing an information security program is a matter of using the following principles except which one?

    1. Accountability

    2. Integrity

    3. Confidentiality

    4. Availability

Answers to Review Questions

  1. Confidentiality, integrity, and accountability. For more information, see the section "CIA: Information Security's Fundamental Principles."

  2. Identification and authentication is the method that associates that the object (user, process, and so on) is the entity it claims to be. See the section "Identification and Authentication" for more information.

  3. Nonrepudiation is the ability to ensure that the originator of a communication or message is the true sender by guaranteeing authenticity of its digital signature. For more information, see the section "Nonrepudiation."

  4. The purpose of a risk analysis is to assess and quantify damage to information assets and to help justify appropriate safeguards. This was described in the section "Risk Management and Analysis."

  5. The risk categories are damage resulting in physical loss of an asset or the inability to access the asset, disclosure of critical information, and losses that may be permanent or temporary. This was discussed in the section "Risk Management and Analysis."

  6. Procedures are formed from guidelines and standards to implement the stated policies. For more information, see the "Policies, Standards, Guidelines, and Procedures" section.

  7. The Bell-LaPadula model uses layering to separate resources into security zones. This was discussed in the "Layering" section.

  8. Synchronous encryption uses the same key to encrypt and decrypt a message. Asynchronous, or public key, encryption uses two keys: The public key of the user who is to read the message is used to encrypt that message, and the private key is used by the recipient to decrypt the message. More information can be found in the "Encryption" section.

  9. Classifying data is supposed to tell you how the data is to be protected. The section "Classifying Data" explains this further.

  10. Background checks and employee agreements are tools used to prevent insider attacks. This was discussed in the "Employment Policies and Practices" section.

Answers to Exam Questions

  1. A. Answer A is the correct answer because the calculation for the annualized loss expectancy (ALE) is the single loss expectancy (SLE) times the annual rate of occurrence (ARO). Answers B and D are not correct and do not calculate anything worthwhile for a risk analysis. Answer C calculates the SLE value. See the "Asset Valuation" section for more information.

  2. C. Answer C is the correct answer because policies are used to describe how an organization wants to protect information assets. Answer A is wrong because guidelines are derived from the policies. Answer B is a procedure that would support a policy. Answer D is wrong because risk management is a component in creating the policy and does not define them. See the "Policies, Standards, Guidelines, and Procedures" section for more information.

  3. D. Answer D is correct because, as the entire chapter shows, security has both components, including physical and personnel security. Answer A is incorrect because it describes only the risk analysis process. Answer B is incorrect because it is focused on two areas of a security program. Answer C is wrong because it concentrates only on network controls.

  4. B. Answer A is wrong because the risks can be similar and even greater for some commercial systems. Answer C is wrong because there are plenty of commercial systems that are secure, and answer D is the reverse of the correct answer. See the "Classifying Data" section for more information.

  5. A. Answers B and C are wrong because they are parts of the risk analysis. Answer D is wrong because it is what the analysis demonstrates, which is only part of the story. See the "Risk Analysis" section for more information.

  6. C. Answer A is wrong because the users are the ones for which the protections are being instituted. Answers B and D are wrong because they do not have the custodial responsibility to understand how data should be accessed. See the "Classifying Data" section for more information.

  7. B. Answer A is a nice idea but not the reason to include all departments. Answer C is wrong because, even if outsiders were used, which was discussed as an option, the insiders would have to provide input into their departments' risks. Answer D is an interesting concept, but not everyone is involved in risks. See the "Risk Analysis" section for more information.

  8. B. Answers A, C, and D are all principles of authentication. Identifying the location can be helpful but is not one of the basic principles. See "Identification and Authentication" section for more information.

  9. D. Answer A is wrong because it is the purpose of data hiding. Answer B is wrong because it is a principle of abstraction, and answer C is wrong because it is the principle of encryption. See "Understanding Protection Mechanisms" section for more information.

  10. A. Answers B, C, and, D are the basic C.I.A. principles. See the "Defining Security Principles" section for more information.

Suggested Readings and Resources

  1. Barman, Scott. Writing Information Security Policies. New Riders Publishing, 2001.

  2. Nichols, Randall K., and Julie J. Ryan. Defending Your Digital Assets Against Hackers, Crackers, Spies, and Thieves. McGraw-Hill Professional Publishing, 2000.

  3. Peltier, Thomas R. Information Security Risk Analysis. Auerbach Publications, 2001.

  4. ftp://ftp.isi.edu/in-notes/rfc2196.txt (RFC 2196, "Site Security Handbook").

  5. ftp://ftp.isi.edu/in-notes/rfc2504.txt (RFC 2504, "Users' Security Handbook").

  6. ftp://ftp.isi.edu/in-notes/rfc2828.txt (RFC 2828, "Internet Security Glossary").

  7. ftp://ftp.isi.edu/in-notes/rfc3013.txt (RFC 3013, "Recommended Internet Service Provider Security Services and Procedures").

  8. http://csrc.nist.gov/publications/nistpubs/800-18/Planguide.PDF (NIST SP 800-18 is a security standard used by civilian agencies).

  9. http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf (NIST SP 800-30, "Risk Management Guide for Information Technology Systems").

  10. http://rr.sans.org (The SANS Institute Reading Room has several individual articles that focus on many areas of information security management).

  11. http://www.rfceditor.org (The Internet Engineering Task Force's relevant requests for comments [RFCs] are available from the RFC Editor).

  12. http://www.whitehouse.gov/omb/circulars/a130/a130appendix_iii.html (OMB Circular A-130 Appendix III).