Existing IT Security Policy Framework Definition

The results of an audit will reflect how well an organization is adhering to its security policy. However, risk management must be considered. How well an organization adheres to its own policy when combined with an assessment risk helps to identify any gaps.

Security controls are essential to measuring policy compliance. Every control must include one or more security policies. However, security policies will not contain security controls. This is because as technology changes, security controls often change. However, often the related security policy itself will not change. Policies are effective when they are well understood by employees and are clearly enforced. If policies change too frequently, they become confusing and difficult to understand.

By separating security controls from security policy, the business can focus on achieving goals independent of the technology. The result is that the business can focus on employee behavior from a business perspective. The security control can focus on system behavior from a technology perspective. Auditing security policies can ensure requirements are not overly prescriptive and become not achievable.

Frameworks exist to help with risk-management programs, security programs, and policy creation. International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27002, for example, provides a structured way for organizations to determine their IT security policy. Accounting and audit firms traditionally had their own interpretations of security standards. They, however, have been increasing the use of existing frameworks for benchmarks. It is important for the auditor to know upon what framework an organization has based its policy. This knowledge allows better alignment between the organization’s policy and the audit. Most internal audits, to ensure compliance across the IT infrastructure, will align with the comparable framework.

Many organizations now have taken steps to implement a security policy framework. However, there are still many instances in which the policy is not actually being enforced. Additionally, information security policies are living documents. Business environments change. Technologies change. Risks change. As a result, companies with existing policy frameworks might discover that their policies are outdated. The IT security policy must be managed as an ongoing program to evolve with changing requirements and ensure adherence.

Configuration Documentation for IT Infrastructure

The auditor will gather documents related to the configuration of the systems being audited. Although a single system component is possibly made up of thousands of configuration elements, the following are examples of items the auditor should gather from documentation:

• Host name

• Internet Protocol (IP) addresses

• Operating system

• Patch level

• Hardware specifications

• Installed software

• Protocols

• Service configuration

• User accounts

• Password settings

• Audit log settings

Applications that reside on the computer systems might also have their own configuration documents. These should be gathered as well. Finally, network documentation is required for the network segments pertaining to the applications and systems being audited.

Many organizations will have standard configuration documents for role-specific systems. Examples include the configurations for the following:

• Firewalls

• Web servers

• Mail servers

• Domain Name System (DNS) servers

• File Transfer Protocol (FTP) servers

Interviews with Key IT Support and Management Personnel: Identifying and Planning

Interviews play an important role in both the information-gathering process and during the audit. Interviews with IT management, for example, can reveal expectations about the organization to the auditor. Interviewing IT support personnel can reveal pertinent information that might not otherwise be discovered. These interviews can also provide greater focus in areas that need it. For example, personnel doing the daily work can help identify weak controls and broken processes.

Properly conducted interviews might even reveal more serious violations, such as fraud. Effective interviews often result in employees offering information about fraud and other serious activities, even when hotlines and other reporting processes exist. These conversations should be an interview, however, and not an interrogation. A friendly and nonthreatening environment fosters openness and honesty with those being questioned. The Institute of Internal Auditors (IIA) defines the audit interview as “a specialized form of communication used to gain information and assist in evaluation.”

Although interviews play a key role throughout the audit, they help to further define the scope during the planning phase. Individual interviews alone might be reason enough to expand the scope. Interviews looked at collectively can provide the auditor with more information. Taken together, these interviews might reveal patterns. Interviews can aggregate enough data to reveal new information. Reasons to expand the scope from the initial interviews can vary, but common examples include the following:

• Lack of controls

• Override of controls

• Fraudulent activity

Some of the most valuable information for audits will be a result of the interview. Therefore, the interview and how well it is performed can make a difference in the outcome of the audit. A simple framework for conducting effective interviews is composed of the following six steps:

• Preparing

• Scheduling

• Opening

• Conducting

• Closing

• Recording

Preparing for the interview is essential. It is important to be cognizant of others’ time and of the job functions they must continue to accomplish even during an ongoing audit. The auditor should prepare a list of questions or at least go into the meeting knowing exactly what it is he or she hopes to achieve or learn. Additionally, an auditor should think like a psychologist. Be aware of the positions and the personalities of those being interviewed. Preparation and scheduling can happen in parallel. It is important, however, to ensure that enough time is given for preparation. When scheduling, the auditor should try to remain as flexible as possible.

The next two steps constitute the actual interview. The opening sets the tone for the remainder of the interview. Opening with a positive tone and clear expectations, combined with thorough preparation, makes conducting the interview much easier. This leads us into the next step, which is asking the questions. At this point, however, it is not enough to have well-thought-out questions. The auditor must be adept at listening as well. The auditor should understand the reporting hierarchy and how management might influence the interviewee’s responses. Closing the interview occurs after the auditor has asked all the required questions or when time is up. The interview should ideally end politely and on an upbeat note. The auditor should thank the interviewee for his or her time and suggest an agreed-upon protocol should the auditor require anything else. This leads into the final step of recording. Taking notes is certainly acceptable during the interview process, but it can be disruptive to the interview flow. Even if notes are taken, after the interview, the auditor should immediately review the notes and organize them as needed.

NIST Standards and Methodologies

NIST 800-53 provides a catalog of security controls and a framework to assess the controls. As with the ISO/IEC frameworks, many organizations base their policies on NIST. NIST provides many more standards, including low-level documentation that has proven useful for internal auditing and assessments.

The Computer Security Division (CSD) of NIST provides several popular publications. All of their publications reflect their research on IT security issues. The publications they provide include the following:

• Special Publications—The 800 series publications, sometimes called Special Publications, provide general-interest documents for the IT security community. NIST also publishes the 500 series of Special Publications, which covers IT.

• NIST Internal Reports (NISTIR)—The NIST Internal Reports (NISTIR) are publications that describe niche technical research.

• Information Technology Laboratory (ITL) Bulletins—The Information Technology Laboratory (ITL) Bulletins are publications that provide an in-depth look at timely topics of importance.

• Federal Information Processing Standards (FIPS)—The Federal Information Processing Standards (FIPS) are standards documents published by NIST and approved by the secretary of commerce.

Of these four different document types, the Special Publications from NIST are more likely to be used for audits and assessments. The publications are known for their depth and prescriptive stance. In addition to the two standards listed at the beginning of this section, the following are examples of other NIST Special Publications:

• SP 800-50, “Building an Information Technology Security Awareness and Training Program”

• SP 800-57, “Recommendation for Key Management”

• SP 800-58, “Security Considerations for Voice Over IP Systems”

• SP 800-61, “Computer Security Incident Handling Guide”

• SP 800-68, “Guide to Securing Microsoft Windows XP Systems for IT Professionals”

• SP 800-70, “National Checklist Program for IT Products—Guidelines for Checklist Users and Developers”

• SP 800-95, “Guide to Secure Web Services”

• SP 800-115, “Technical Guide to Information Security Testing and Assessment”

• SP 800-123, “Guide to General Server Security”

The preceding list provides several examples of the many different publications from NIST. SP 800-70 defines the National Checklist Program (NCP). The NCP is a government repository of available security checklists or baseline configurations for operating systems and applications.