Information systems provide information to users. Without users, there would be no reason to invest in collecting, manipulating, and storing data. Information passes from the outside world to the information system through user actions. Keyboards, mice, and scanners are just a few of the common methods users employ to get information into the various systems. A secure system needs controls that limit the type of information users can provide and retrieve.

The User Domain is the initial domain in the IT infrastructure that formalizes how information flows in and out of computer systems. This domain defines components you need to control to ensure your environment is compliant with applicable requirements. Figure 8-1 shows the User Domain in the context of the seven domains in the IT infrastructure.

User Domain controls designed to help ensure compliance place limits on acceptable user actions. A User Domain "control" is any mechanism that interacts with a user and reacts when a user's actions meet certain conditions. The overall purpose of User Domain controls is to restrict user behavior to approved, or compliant, behavior. The control's reaction depends on what type of control it is. Controls generally fall into the following functional types:

Figure 8-1. The User Domain within the seven domains of a typical IT infrastructure.

Figure 8-2 gives an overview of preventive, detective, and corrective controls.

By limiting what users can do, compliance-related security controls restrict users to appropriate actions. These restrictions can include limits on what users can access and what actions they can perform. Although limiting users to meet compliance requirements might be desirable or even necessary, they can make it more difficult to complete required business functions. One of the difficulties of ensuring security in the User Domain is designing secure controls that still allow and promote necessary business functions.

Figure 8-2. Types of security controls.

It is important that you implement compliance requirements in a way that minimizes the impact on business drivers. Recall that business drivers are the components, including people, information, and conditions, that support business objectives. Any negative impact on business drivers can also have a negative impact on your organization's ability to satisfy business objectives. Carefully research the impact to business drivers before you implement any compliance controls.

Remember that compliance requirements dictate how your organization conducts its activities. Whether the compliance requirement comes from legislation, regulation, industry requirements, or even your organization's standards, the end result is the focus. In most cases, your organization can control activities to ensure compliance in multiple ways. Always consider alternative controls to achieve the end result compliance requires. You'll likely find that some controls are less costly and less intrusive than others. Don't just accept the first control that does the job. Many times, alternate controls are just as good but intrude less on your organization's activities.

You can meet many compliance requirements using one of several controls. If one control has a negative impact on business drivers, consider another control. You can often justify eliminating one control if another control will achieve the same goal.

For example, Payment Card Industry Data Security Standard (PCI DSS) requires that you store credit card information as encrypted data. Implementing data-level encryption in a legacy application can be expensive and require a substantial effort. If you run Windows Server 2008, one possible alternative is to use Microsoft BitLocker Drive Encryption. BitLocker could be a compensating control for application-level encryption. Figure 8-3 shows a comparison of alternate controls using PCI DSS as an example.

Figure 8-3. Alternate controls.

The User Domain contains several common items or components. You should consider each component when evaluating activities for compliance. People and documentation are the most common items in the User Domain. Each of the two broad categories includes several smaller types of items with unique characteristics. The following are different types of people in the User Domain:

Figure 8-4 illustrates items commonly found in the User Domain.

The User Domain contains more than just people. It is important that people who are resources to an organization have formal directions for how they carry out activities. These activities should support meeting business goals. You need a collection of documents that outlines activities that support business activities to determine whether an action is acceptable or unacceptable. The User Domain also needs documented policies to direct the actions of people. The following are different types of documentation in the User Domain that affect compliance:

A solid basis for compliant activity requires a well-organized User Domain with clear roles and expectations. In the following sections, you'll learn about important concepts to build a secure environment of compliant behavior.

A common theme in compliance requirements is to reduce the ability of any one element to compromise data security. In the User Domain, this means that no single person should have the ability to bypass security controls that protect data. Each computer user's role should limit the scope of permitted actions.

Most computer systems restrict access to deny unauthorized users. The first step in gaining access to data is to identify yourself to the information system and authenticate your identity. This process commonly involves providing a user ID and a password. Once you are identified and authenticated, the operating system grants authority in the form of permissions and rights. These permissions and rights are defined by your assigned roles. You can only accomplish what your assigned roles allow.

The concept of separation of duties requires that users from at least two distinct roles be required to accomplish any business-critical task. This means that users from at least two roles must collude to compromise data security. Although collusion is still possible, it is far less likely than if a single user could gain exclusive access to sensitive data without anyone else looking. Going further, separation of duties helps avoid conflicts of interest. For example, the role in charge of administering a system should not be the same role that audits that system for potential compliance violations.

Table 8-1 contains some examples of separation of duties in IT environments.

Figure 8-5 illustrates separation of duties in an IT environment.

Figure 8-5. Separation of duties.

The first step in implementing separation of duties is to remove unnecessary user privileges. Any unnecessary privilege provides an opportunity for a user to violate the AUP and perform unauthorized data access. It makes sense to use access controls to prevent unauthorized data access. The process of allowing only the level of access your users require might be tedious, but it is necessary to secure sensitive data.

The ultimate goal is to define access control where each user has the permissions to carry out assigned tasks and nothing else. This is the principle of least privilege. User permissions beyond what is required to carry out necessary tasks are excessive and potentially insecure.

Putting least privilege into practice can be challenging. Organizations with many users often use roles, or groups, to define access permissions. Administrators define roles that represent small tasks, such as "accounts receivable user" and "accounts receivable manager," and grant specific permissions to each role. Individual user accounts can belong to one or more roles and inherit the permissions from each of the roles definitions.

Government organizations and some commercial organizations implement the principle of least privilege in a different way. They use a system not based on roles, but on data classification and user clearance. The operating system makes the decision to grant or deny access to any data object by matching the object's classification to the user's clearance. Because this method of access control is based on object and subject attributes and not on anyone's discretion, this is a mandatory access control (MAC). Table 8-2 shows the classification system the U.S. government uses for MAC.

Nongovernmental organizations that need to protect information at different sensitivity levels can also use MAC to secure information. The ISO 27002 standard contains suggestions for five basic classifications. These classification levels are just suggestions for organizations that do not already have a classification strategy in place. Table 8-3 shows the ISO 27002 suggested classification levels.

Whereas DAC does support the detailed control necessary for least privilege, simple data classification and user clearances do not. You need an additional control to ensure users only possess the privileges they need to do their jobs. For example, a project manager needs access to documents related to the current project only. If the documents for several unrelated projects are all labeled as "highly confidential" and the project manager holds a "highly confidential" clearance, all project documents would be available.

Although this situation might seem reasonable, it does allow a project manager to access documents that are unrelated to the current project. This capability violates the principle of least privilege. Most systems that use DAC also use the concept of need to know. In addition to possessing a clearance level that matches or exceeds the classification label of an object, a subject must have the need to know for the object as well. Simply put, need to know means that you have a need to access an object to do your job. Adding the concept of need to know to DAC does provide full support for the principle of least privilege.

Employees who work with sensitive information can be a great asset and a great risk. A person who understands the inner workings of your organization can protect sensitive information or defeat your security controls. Someone who knows your organization could make violations difficult to detect. Contractors who have access to sensitive information can be just as dangerous. How should your organization protect sensitive information from insiders? The answer is to implement a defense-in-depth strategy. Solid access controls and the principle of least privilege are both important, but neither is enough.

Some information leaks occur because of simple ignorance or carelessness. If workers don't know that information is sensitive, they might treat the information with less care. When hiring personnel, you should communicate your organization's security policy clearly. The employee or contractor confidentiality agreement is a common document that accomplishes this. Another name for this document is a "non-disclosure agreement" (NDA).

A confidentiality agreement is a legally binding document. By signing this document, each party agrees to keep certain types of information confidential. A confidentiality agreement is a necessary part of any relationship that involves sensitive information.

Confidentiality agreements allow organizations to disclose sensitive information to a small number of parties without concern that an information leak might cause harm. For example, these agreements allow organizations to share specifications of unreleased products to business partners. Sharing this type of information allows business partners to develop companion products before the release of original products. Most major software vendors, such as Microsoft and Apple, do this to allow their development partners to write software for new operating systems before the release date. The confidentiality agreement protects the operating system vendor by prohibiting partners from releasing information about the new product.

Another important feature of a confidentiality agreement is that it can protect patent rights. Publicly disclosing an invention can result in forfeiting any patent rights. An organization must keep information about the invention confidential until filing a patent application. Confidentiality agreements with anyone who has access to confidential information can protect your organization from a damaging public disclosure.

A confidentiality agreement defines the types of information parties can and cannot disclose. A confidentiality agreement also specifies how parties may use confidential information. The agreement defines expected behavior and the consequences of violating the agreement. A well-written confidentiality agreement lowers the risk of disclosing confidential information.

Many organizations perform a background check on prospective employees before hiring anyone. The purpose of a background check is to uncover any evidence of past behavior that might indicate a prospect is a security risk. In reality, all personnel are security risks because they must be trusted with sensitive information. A background check can uncover information that indicates a person might be an undue security risk.

Background checks can vary in depth, for example simply verifying a Social Security number as authentic and belonging to the applicant. Another example is conducting a police criminal check and reviewing a prospective employee's complete history. Each organization sets the scope of background checks. The job description and the organization's desire to use a prospect's history to indicate future actions affect the scope of the investigation. You can conduct background checks using internal resources or by engaging external specialists. External resources can reduce your ongoing expense and may provide higher-quality information by using specialists. However, external resources who conduct background checks operate under additional restrictions.

The Fair Credit Reporting Act (FCRA), which defines national standards for all consumer reports, also governs how you conduct background checks. FCRA governs background checks because they are labeled as consumer reports, even though a background check may consist of more than credit history information. FCRA sets time limits on negative information that investigators can include in their report. Although some states may lengthen FCRA time limits, investigators cannot include:

Background checks often include much more than just financial information. Most employers are more interested than ever in a prospective employee's general past and current behavior. In many cases, social networking sites, such as Facebook or MySpace, can provide information on a prospect's behavior. Fair or not, more and more employers are looking into past behavior to attempt to decide how trustworthy a prospect may be.

Although background checks are important and might provide interesting insight into a person's background, you must perform them with care. FCRA requires that you obtain permission from the subject of a background check before you begin the investigation. In addition, if you decide not to extend an offer due to information contained in the background check report, you must provide the reason and the contact information for the investigating organization. You must give the prospect the opportunity to dispute any negative information in the report. This safeguard helps prevent incorrect information from harming an unsuspecting individual.

Background checks can reveal quite a lot about a prospective employee. A prospect with prior criminal history might not be a good candidate for a role that allows access to very sensitive information. Knowing the background of prospective employees is an important step in granting authorization to sensitive information. Although a background check won't catch every potential attacker, it can help identify some of the most likely high-risk candidates.

As you've learned in previous chapters, auditing is the process of examining systems to verify they are in compliance with defined policies. In short, auditing ensures activities comply with policy. This process provides value only when it objectively reviews evidence of actions. An auditor who overlooks any evidence of noncompliance isn't very effective. Because of the potential of negative findings, it is important that all parties engaged in auditing activities understand responsibilities to the audit process.

Don't view auditing simply as a search for problems. Auditing is an opportunity to identify noncompliance issues before they escalate and possibly cause damage. This positive attitude toward auditing must start with upper management, who should share it with all affected parties. If upper management does not fully support the efforts of auditors, it is unlikely anyone else will.

Upper management can influence audit process quality by assigning responsibilities and accountabilities. Every employee bears some responsibility in the IT security audit process. Every agent of your organization must maintain the security of your information. Because the IT security auditing process verifies compliance with security policies, all employees bear responsibility for carrying out your policies.

Each task in the audit process has one or more people who are responsible or accountable for that task. Many organizations use a RACI matrix to document tasks and personnel responsible for the assignments. RACI stands for responsible, accountable, consulted, and informed. To create a RACI matrix:

The entries in the matrix will contain one of the following:

Table 8-4 shows a simple RACI matrix for an IT audit.

The RACI matrix clarifies the responsibilities and accountabilities for a set of tasks. A RACI matrix provides upper management a tool that communicates and conveys for tasks. Without the acceptance of audit responsibilities and accountabilities, the auditing process might encounter resistance. Management and other employees might view the audit process as punitive.

Employees often have the greatest access to an organization's critical resources. Your organization places substantial trust in its employees and takes on substantial risk in doing so. Many security incidents originate from internal personnel, including employees. Not all incidents are malicious attacks. Some are simply a failure to comply with the organization's stated security policy.

It is important to educate new employees on your organization's security policies and procedures. It is difficult for employees to comply with a policy if they are unaware of what the policy contains. Training employees on security matters can help avoid many security policy violations, including:

The HR department usually follows an established procedure when handling new employees. Security awareness and security procedures training should be a part of this process. You should provide training for each employee on security topics, including:

Security training should include justification. It is important that employees understand the value of security to the health of your organization. Employees should acknowledge they have received security training and agree to abide by your security policy and procedures. Many organizations make use of the employees' acknowledgment to uphold the security policy requiring it as a condition of employment. Because the security of sensitive resources is important to your organization, it should be important to your employees.

Security-related activities often have lower importance than activities that directly make money. Unless upper management clearly states the importance of security, security personnel might find it difficult to obtain funding and support to maintain secure systems. Most important, an organization's upper management is responsible for protecting the security of the organization's resources. Management is responsible to the stockholders, regulatory agencies, government entities, and the public.

In addition, management should assign accountability for each security-related activity. Creating and maintaining a secure environment requires acceptance of accountability.

User behavior is the focus of auditing for IT compliance in the User Domain. In the simplest sense, this consists of examining user actions and comparing those actions with security policies, standards, procedures, and guidelines. If you find any differences with organizational requirements, you should report the differences and analyze their impact.

It is important to train all internal and external users on acceptable behavior. Training should cover the contents of your organization's security statement documents and provide users with the knowledge to comply with the documents. Training that does not cover security expectations is insufficient. Users who hold a privileged role, such as system administrator, should receive additional, specialized training pertinent to their role.

Good security training should stress the importance of compliance and cover the important parts of these types of security documents:

Your access control policies should grant access to information systems depending on users upholding the organization's security policies, standards, procedures, and guidelines. Violation of any of these security elements should carry consequences ranging from a training refresher course to losing access.

Identifying and influencing user behaviors that affect security are important to ensuring compliance within the User Domain. Behaviors that support or violate compliance with your security goals get the most attention. The following best practices do not guarantee compliance with all goals. However, they will lay the foundation to develop and maintain a secure environment:

The User Domain defines information system users and the actions they carry out. A critical factor of maintaining secure systems is ensuring compliance of users to security goals. Because user actions result in accessing information, it is necessary to control and monitor user actions to maintain secure systems. Systems must uniquely identify users and allow access only to information for which they are authorized. Auditing activities should examine all access decisions and the rules that govern such decisions for compliance. Defining limits within the User Domain and validating user activities provide an important security layer in a defense-in-depth approach to system security.