ONCE THE AUDIT TEAM COMPLETES an approved auditing plan, they can begin auditing the IT infrastructure for compliance. Testing for compliance is centered on the presence of adequate controls or countermeasures within the planned scope of the IT infrastructure. This includes verifying policies are put in place and appropriately followed.
The actual execution of an audit can vary widely based on the scope and objectives of the plan. Several methods, frameworks, and automated tools are available to assist in the process. The choices made will depend on the areas being assessed and the depth and breadth to which controls need to be examined.
For an organization to develop security baselines, that organization must select proper controls. However, the decision to apply or not apply controls is based on risk. Specifically, the controls put in place manage the identified risks. As a result, the risk assessment discussed in Chapter 5 needs to be completed first.
It might seem easiest to apply a wide range of controls based on different recommendations. Remember, however, that costs are associated with these controls. For example, you can take many different steps to secure your home and minimize risks. Most people consider door locks as necessary. Beyond that, there is no universal rule of home security that everyone adheres to. Even door locks are available in varying strengths. Consider other measures a homeowner might take. Examples include bars on the windows, storm shutters, insurance, burglar alarms, smoke detectors, carbon monoxide detectors, cameras, safes, watchdogs, outdoor lighting, fences, and even weapons. These examples of home controls are similar to IT controls in that there is a cost associated with each of them. Depending on the type or mission of the business, the cost justifications vary. The controls are based on the level of risk the organization faces.
Warning
Effectively managing risks is a complex task. Be careful not to focus only on risk management and lose sight of the organizational goals. If organizations focus more on risk management, they are likely to underperform. You can apply this same principle personally as well.
Payment Card Industry Data Security Standard (PCI DSS) provides an example of a concise set of baseline controls required for those organizations that process or transmit payment card information. Refer back to Chapter 2 for a listing of the PCI DSS high-level standards and associated controls. The requirements of PCI consider the general risks to payment card data and provide the baseline approach to safeguarding the sensitive data. The challenge for many organizations is the need to identify and deal with many different types of risks. This is compounded by a constant shift in threats, vulnerabilities, and technology change. The following questions are helpful in determining an appropriate set of baseline controls:
Does the organization have a program for IT governance and security management?
Do IT policies exist?
Are there tools and processes for assessing risk in place?
Is the IT environment physically secured?
Are authentication and access control mechanisms in place?
Is software to prevent, detect, and respond to malicious code in place?
Are firewalls used?
Has a program for configuration and change management been put in place?
Are systems automatically monitored and reviewed by IT staff?
Do personnel have the appropriate skills to perform their job, and is an ongoing training and awareness program in place?
Remember that IT is not completely independent. IT exists to enable the business. Understanding the minimum level of acceptable risks and implementing baseline controls depend on IT being aligned with the objectives of the business.
Establishing a baseline based on a control framework needs to be relative to the risk appetite of the organization. The Committee of Sponsoring Organizations (COSO) defines risk appetite as "the degree of risk, on a broad based level, that a company or other organization is willing to accept in pursuit of its goals. Management considers the organization's risk appetite first in evaluating strategic alternatives, then in setting objectives aligned with the selected strategy, and in developing mechanisms to manage the related risks."1 Risk appetite is a broad-based look at the amount of risk an organization is willing to take to achieve its objectives. This should not be confused with risk tolerance. Risk tolerance is about the ranges of acceptance for specific risks. Identifying levels of risk tolerance allows the organization to stay within its defined appetite for risk.
IT supports the enterprise risk management (ERM) strategy in a few ways:
ERM depends on accurate and timely information. Information systems process and store this information. Maintaining the integrity and availability of the data is needed. As a result, adequate controls need to be placed around systems.
The IT environment supports not only the ERM function, but it also supports all other operations of the business. As a result, the IT environment and associated controls need to be aligned with the organization.
Aside from looking at individual controls, an auditor will ensure the IT environment is aligned with the organization's risk appetite. Additionally, the auditor assesses the framework of internal controls to ensure it is appropriate to allow the organization to remain within its risk tolerances.
After considering the organization's risk appetite and tolerance, further consideration of the following is needed:
The value and importance of data
Risks to the IT infrastructure
The level of expected quality of service
The seven domains of a typical IT infrastructure are composed of people, processes, and technology. This includes employees, partners, and customers interacting with data and using software and applications across a hardware infrastructure. Looking across the seven domains of a typical IT infrastructure can reveal immediate vulnerabilities. For example, domains consisting of remote access, WANs, and cloud computing environments all reveal potential rogue Internet connectivity. Gathering the appropriate documents as discussed in Chapter 5 can provide an immediate view into the domains and inventory of the IT infrastructure.
Note
Most businesses today rely on the Internet as a facilitator for accomplishing their goals. The Internet is a prime example of an IT component that has a clear benefit for the organization, but introduces risk. As a result, basic security controls are applied to protect the organization from numerous threats.
Mitigating risk within the IT infrastructure includes the application of controls. Again, the risks organizations want to minimize are based on the value of the assets coupled with how a vulnerability being exploited by a threat would impact the confidentiality, integrity, and availability of the data and associated systems. Reducing the risk depends on what controls are available, how much they cost, and if they are cost efficient. As a result of this analysis, organizations typically take the approach to managing risk introduced in Chapter 5. A more detailed look at these strategies includes the following:
Accept the risk—Do nothing and manage the consequences if the risk is realized.
Avoid the risk—Seek alternatives or don't participate in the risky activity.
Share the risk—Transfer or divide the risk with other parties.
Control the risk—Apply mechanisms or countermeasures to minimize the effects of the risk.
Warning
Do not confuse risk acceptance with risk arrogance. Accepting a risk should be a result of careful planning and attention to an assessment of the risks and possible controls or other strategies for managing risk. "Risk arrogance" or "risk blindness" occurs when an organization does adequately plan and assess risks.
Figure 6-1 provides a simple illustration of components or risk and how the preceding strategies might be applied. The approach an organization takes needs to consider the risk appetite of the organization. The risk might be so great, for example, that avoidance might be the best solution.
In the wake of the attacks on the World Trade Centers in 2001, a reporter asked Bruce Schneier, a security technologist, "How can we prevent this from ever happening again?" He replied, "That's easy. Simply ground all the aircraft."2 This example of avoiding the risk might seem far fetched, but as Schneier points out, this is exactly what occurred in the hours following the attacks. Though few would argue with the enormous benefits of air travel, the situation at the time merited an extreme measure be taken.
Consider a simple example of the risk of worms and viruses from the Internet. Consider each of the previous strategies to determine how you might apply each of them to your use of the Internet at home:
Accept—Browse the Web without applying any controls, and hope you don't get infected with malicious software. If you do, you will have to deal with the consequences, which might include losing all your data and having to pay expensive repair costs.
Avoid—Disconnect your computer from the Internet. You will have certainly eliminated the possibility of being infected with malicious software from the Internet. On the other hand, you no longer receive the benefits of what the connection can provide. If you used the Internet primarily for research, for example, you can instead use other sources of information, such as books and encyclopedias.
Share—Use the Internet from publicly available Internet kiosks or libraries. Although this might not be as convenient, this does provide a compromise between acceptance and avoidance.
Control—Purchase antivirus software. This option, however, introduces costs. The costs might involve money and degradation of system performance, for example.
Although the preceding example is relatively simple, the decisions are not always so clear. Two additional concepts in selecting an approach include the introduction of new risks and compensating controls. The introduction of new risks is always a possibility when seeking to mitigate risks. Consider the third example from the preceding list. Do you incur a risk that might have otherwise not existed? Does driving daily to the library introduce the likelihood of being involved in an accident?
"Compensating controls" are alternative measures put in place to mitigate a risk in lieu of implementing a control requirement or best practice. Using the preceding example, suppose you don't want to spend the money on antivirus software and choose to accept the risks. You might take a compensating measure, such as not opening file attachments or only visiting reputable Web sites. Often, layering compensating controls is necessary. In addition to changing your habits, you might also back up your data regularly.
Armed with an understanding of risks within the IT infrastructure, the risk-mitigation strategies will be factored into the appropriate security baseline. An audit of the baseline controls will determine the following:
Are the controls effective at reducing the targeted risk?
Do the controls incorporate a mix of preventive, detective, and corrective controls?
How are the controls monitored and audited in case of failure or breach?
Baseline controls are those countermeasures that apply broadly to the entire IT infrastructure. An exterior door lock on a home is an analogy of a common baseline control. Antivirus software is an example of a baseline control within the Workstation Domain. A firewall, which controls access between the organizational network and the public network, is a baseline control for the LAN-to-WAN Domain. In these examples, the controls are configurable depending on the level of risk. Depending on the sensitivity of the data or services, the organization can make further adjustments. For example, does the antivirus software perform periodic scans or does it scan files continuously? A firewall is flexible regarding the level and extent of services it controls. A firewall can place tight restrictions on point-to-point communications or limit what services or applications are able to traverse.
A gap analysis is an examination of the current state of controls against the desired state of controls, as illustrated in Figure 6-2. The difference between the two indicates the required action. The ongoing risk assessment process determines the desired state. Thus, once a gap is closed, it does not necessarily stay that way. The results of a gap analysis determine the absence of baseline controls. Moreover, a gap analysis is ideally used once a baseline is established. It further defines the need for additional controls or enhancements to existing controls.
Analyzing gaps requires attention to the type of system and its value or criticality. Depending on the criticality of the system, different baselines may apply. The National Institute of Standards and Technology (NIST) provides baseline control recommendations across three different types of information systems: low impact, moderate impact, and high impact. NIST provides different baseline controls for different classifications.
For example, users accessing low-impact systems might be required to identify themselves with a unique user name and authenticate with a password. This would meet a baseline requirement of an information system uniquely identifying and authenticating users.
Consider an example from NIST 800-53 for monitoring physical access in an information system environment. The control states that the organization should:
Monitor physical access to the information system to detect and respond to physical security incidents.
Review physical access logs.
Coordinate results of review and investigations with the organization's incident response capability.
The previous points represent the baseline control for all systems regardless of the impact level. NIST further provides two more control enhancements for monitoring physical access. These include:
The organization monitors real-time physical intrusion alarms and surveillance equipment.
The organization employs automated mechanisms to recognize potential intrusions and initiate designated response actions.
Systems designated as being of a moderate impact would require not only the original baseline control, but also the first control from the previous two items. The high-impact system baseline control would require the original baseline control and both controls from the previous list. If an organization had broadly implemented the original baseline controls, but not the others, a gap analysis would reveal if the control enhancements are necessary. As a result, the organization would clearly understand where they currently stand with regard to monitoring physical access. They would also understand where they need to be and have clear guidance on what they need to do to fill the gap.
The organizational security policy framework is the foundation for the direction of information security management. This foundation provides direction and support internally and also provides direction for assessments and audits. The quality of the entire information security program is dependent upon policy. Fortunately, policies can be one of the least expensive controls. Unfortunately, they are often the most difficult to implement effectively. In fact, the first control objective within the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27002 standard states that management should set a clear policy direction by implementing and reviewing the security policy document. The policies provide reference documents for auditors and provide the statement of management intent throughout the organization. As a result, the policy framework, which also includes the standards, procedures, and guidelines, will help guide the organization and audits.
Although frameworks such as ISO/IEC 27002 provide guidance for policy development, the scope and maturity of policies vary widely across organizations. It is still not uncommon to find companies that lack any type of policy framework. Only slightly better are the organizations that have only a basic or boilerplate policy in place. In these situations, audit and compliance groups are valuable resources to help review the proposed policies, making sure they are realistic, in line with business objectives, and enforceable.
During the audit discovery, the governing policy document should have already been reviewed. During the course of the audit, however, this policy will help identify the standards, procedures, and guidelines needed to effectively understand and assess the IT environment. Although explicit audits against the documented policies and supporting documents are common, the existence and extent of such documentation should always be considered regardless of the type of audit. In other words, the auditor should always be identifying and evaluating policies, standards, and procedures. Even though ISO/IEC 27002 has a control objective dedicated to security policies, it references individual policies, standards, and procedures throughout all the other controls as well.
The IT infrastructure audit requires the auditor to rely heavily upon the documented policy framework. This helps identify the gaps for improvements to the policy as well as fulfill the responsibilities to evaluate adequate controls. Ultimately, the goal is to gain assurance around the strategic view and use of IT controls. Realizing this goal is built upon the security policy framework.
The auditor should conduct the audit according to the scope of the plan. This includes auditing the systems included in the plan within the specified time frame. Categorizing the audit into recognizable chunks by domains helps keep the audit focused with minimal reference to other systems. Although the scope may be defined to a specific domain, the auditor needs to recognize the various system inputs, processes, and outputs. This ensures that other domains necessary for an effective audit are covered as needed.
A layered audit approach across the domains of the IT infrastructure will be necessary when systems span the domains. This is especially evident in audits of a particular process. An external audit over financial reporting controls is a perfect example. A company's financial system can span across multiple domains and even include third-party providers such as payroll service providers. This means the auditor has to verify the controls considering the process and the infrastructure that the process uses.
A variety of tools is used to perform a security assessment. The assessment may target the entire IT infrastructure, a single domain of the IT infrastructure, or anywhere in between. All assessments should follow a plan and be performed with a disciplined approach. There are different approaches to identify security weaknesses within an organization. Some of the approaches include the following:
Network scan—Provides an automated method for discovering host systems on a network. Although it doesn't necessarily discover all vulnerabilities, it does determine which systems are active on the network and what services they offer or what ports are available. A network scan provides valuable information pertaining to the environment. A network scan can also provide an adversary with a footprint from which he or she can later conduct a more targeted attack. For this reason, network scans are an important part of defining the assessment process and understanding what an attacker might discover and target.
Vulnerability scan—Provides the fundamental process for managing vulnerabilities. A vulnerability scan is an automated method for testing a system's services and applications for known security holes. Most vulnerability assessment scans also provide reports on the identified holes along with additional information for improving security. Unlike a network scan, which looks more broadly for available systems, a vulnerability scan is targeted to specific systems. Vulnerability scans can be conducted across the entire infrastructure or specific components within the individual domains, such as:
Operating systems
Web servers
Mail servers
Databases
File Transfer Protocol (FTP) servers
Firewalls
Load-balancing servers
Switches and hubs
Wireless access points
Penetration test—This is most often associated with a security assessment. A penetration test, also known as a pen test, is an active hands-on assessment that uses methods similar to what a real-world attacker might use. A penetration test goes beyond simply looking for vulnerabilities. Once vulnerabilities are identified, attempts to actually exploit the vulnerability are attempted. The test helps determine how practical or viable specific attacks might be. This includes understanding what the impact might be of a successful attack.
The technical skill set required to conduct a security assessment depends upon the scope of the assessment and the types of tools or techniques used. Knowledge of basic security principles and technical fundamentals such as understanding Transmission Control Protocol/Internet Protocol (TCP/IP) is helpful.
All three of the preceding methods may be used independently or may be used together as part of the overall plan. It is common, for example, for a network scan to precede a penetration test. Both network scans and vulnerability scans are more easily automated on a regular basis than a penetration test. Penetration tests require more planning and coordination.
There are several popular frameworks for conducting comprehensive security assessments. Three examples include:
Open Source Security Testing Methodology Manual (OSSTMM)—A method that takes a scientific approach to security testing. It is made up of five sections called channels, and each channel includes various modules.
Information Systems Security Assessment Framework (ISSAF)—A method for evaluating networks, systems, and applications. It is divided into a three-phase approach, which includes a nine-step assessment process.
NIST 800-15—A guide to the basic technical testing and examination functions of conducting an information security assessment. This NIST guide is composed of seven major sections and several appendixes.
Table 6-1. Summary of major capabilities of review techniques.
CAPABILITIES | SKILL SET | |
|---|---|---|
Examines policies and procedures for accuracy and completeness | General knowledge of information security and information policies | |
Log review | Provides data on system use, changes, and configuration Might reveal potential problems and deviations from policies and standards | Knowledge of log events and ability to interpret log data Ability to use automated logging and log correlation tools |
Exposes holes in security controls based upon rulesets | Knowledge of ruleset formats Ability to correlate and analyze rulesets from different devices and different vendors | |
Monitors network traffic to capture information such as active systems, operating systems, communication protocols, and services Exposes unencrypted communications | Knowledge of TCP/IP and networking Ability to interpret and analyze network traffic Ability to deploy and use network-sniffing tools | |
Identifies changes to important files and can also identify unwanted files that might be malicious | General file system knowledge Ability to use file integrity checking tools and interpret the results |
Regardless of the method chosen, each uses similar techniques for conducting a security assessment. The remainder of this section uses the NIST methodology as a guide. NIST breaks the assessment down across three different types of primary techniques. These include:
Review techniques are composed of examining the components across the domains of IT infrastructure. Reviewing is a passive process, using noninvasive techniques, which has minimal impact to the systems. Table 6-1 provides examples of specific review techniques, along with the capabilities of the technique and the specific skill set required to use the technique.
After performing a document review, the next step involves the use of target identification and analysis techniques. The goal is to identify active devices along with their available ports and services and look for possible vulnerabilities. The information collected sets the stage for the next step of trying to exploit and validate the vulnerabilities. Table 6-2 provides examples of the techniques involved, along with the capabilities of the technique and the specific skill set required to use the technique.
Table 6-2. Summary of major capabilities of target identification and analysis techniques.
TECHNIQUE | CAPABILITIES | SKILL SET |
|---|---|---|
Discovers active devices on the network Identifies communication paths and facilitates determination of network architectures | General TCP/IP and networking knowledge Ability to use both passive and active network discovery tools | |
Discovers active devices on the network Discovers open ports and associated service/applications | General TCP/IP and networking knowledge Knowledge of ports and protocols Ability to use port-scanning tools Ability to interpret results from tools | |
Identifies hosts and open ports Identifies known vulnerabilities Provides advice on mitigating discovered vulnerabilities | General TCP/IP and networking knowledge Knowledge of ports, protocols, services, and vulnerabilities Ability to use automated vulnerability-scanning tools and interpret the results | |
Identifies unauthorized wireless devices on the network Discovers wireless signals outside of an organization Detects potential backdoors and other security violations | General knowledge of computing and wireless transmissions, protocols, services, and architecture Ability to use automated wireless scanning and sniffing tools |
Table 6-3. Summary of major capabilities of target vulnerability validation techniques.
CAPABILITIES | SKILL SET | |
|---|---|---|
Identifies weak passwords and password settings | Knowledge of secure password composition and how operating systems maintain passwords Ability to use automated cracking tools | |
Penetration testing | Tests security using the same methods and tools that attackers use Verifies vulnerabilities Demonstrates how vulnerabilities can be exploited iteratively to gain access to internal systems | Extensive knowledge of TCP/IP, networking, and operating systems knowledge Advanced knowledge of network and system vulnerabilities and exploits Knowledge of techniques to evade security detection |
Allows testing user awareness and if proper procedures are followed | Ability to influence and persuade people Ability to remain calm under pressure |
Finally, with the information from the previous phase, potential vulnerabilities are probed further. The techniques shown in Table 6-3 are used to exploit the vulnerability.
An organization may use all of the preceding techniques as part of an overall security assessment or selected parts. Additionally, the techniques can be used across the IT infrastructure or they may focus on only specific domains. This is dependent upon the objectives of the assessment, which must consider available time and resources.
Warning
The techniques listed in Table 6-3 pose a greater risk during the assessment process than review and target identification and analysis techniques. Although there are benefits to testing out and exploiting vulnerabilities in an assessment, it is possible that these methods could impact the targeted systems negatively. Because of the likelihood and potential impact, you should never conduct these techniques without the expressed consent of senior management or risk owners.
Some security assessment techniques were listed earlier in the section "Performing a Security Assessment for the Entire IT Infrastructure and Individual Domains." These techniques help determine the feasibility of successful attack against organizational resources. A security assessment is a component of a full IT security audit. Despite the technically focused nature of security assessment methods such as penetration testing and vulnerability assessments, they are not substitutes for an internal audit of IT security. An audit should also include a risk assessment and pay particular focus to internal controls.
The overall process of validating compliance should take a more holistic view. A penetration test, for example, might only reveal a limited number of vulnerabilities that are actually exploited, thus ignoring other vulnerabilities. As a result, these tools and methods should complement the overall audit process.
ISACA produces a series of auditing standards, guidelines, and procedures for information systems auditors. Its standard titled "Performance of Audit Work" states, "IS audit staff should be supervised to provide reasonable assurance that audit objectives are accomplished and applicable professional auditing standards are met."3 The standard further states, "During the course of the audit, the IS auditor should obtain sufficient, reliable and relevant evidence to achieve the audit objectives." These statements justify the use of security assessment techniques such as penetration testing and vulnerability analysis. The security assessment should support the findings within the final audit report.
In fact, the ISACA procedural document "Security Assessment—Penetration Testing and Vulnerability Analysis" provides information system auditors with guidance. ISACA's suggested penetration test and vulnerability analysis procedures include:
Planning—Defines the scope of the evaluation to include objectives, timing, and tools required
Skills required—Identifies the skills and knowledge required
Agreements—Provides guidance on the types of records to keep and contractual recommendations if external consultants are involved
Scope questions—Offers guiding questions regarding the technical scope of the tests to be performed
Internet penetration testing—Provides recommendations for system enumeration, vulnerability analysis, and vulnerability exploitation from outside the organization
Dial-in penetration testing—Provides guidance for conducting assessments against dial-in technologies
Internal penetration testing—Provides recommendations for system enumeration, vulnerability analysis, and vulnerability exploitation from within the organization
Physical access controls—Provides recommendations to gain physical access to the network and procedures to perform once physical access is obtained
Social engineering testing—Provides guidance for preparing and conducting social engineering attacks
Wireless—Provides procedures for discovering and exploiting wireless networks
Web application—Provides procedures for analyzing and attacking Web-based vulnerabilities
Report—Recommends preparing the final report in accordance with auditing standards and conducting appropriate follow-up activities
In many situations, an information systems auditor might not have the required skills necessary to perform a security assessment. Additionally, there might be other limitations or constraints that prevent the auditor from performing such a technical analysis. In such situations, the auditor might consider using the work of other experts. The expert can be internal or external to the organization as long as independence and objectivity is preserved. Examples of experts provided by ISACA include:
An information system auditor from an external accounting firm
A management consultant
An IT expert or expert in the area of audit who has been appointed by top management or by the information systems audit team
The auditor should determine that the expert's work is relevant to the audit objectives. The auditor should also obtain a letter indicating that he or she has the right to access the results from the work of others. Prior to incorporating the results of an assessment into the audit, the auditor should review all supporting documents and reports. This includes determining that the assessment supports the audit objectives. If necessary, the auditor might need to conduct additional testing for supporting audit evidence, if not covered in the assessment.
Auditors are able to increase their productivity through the use of computer assisted audit tools and techniques (CAATT). These tools and techniques are simply computer applications auditors use to assist them in their job functions. Auditors are able to perform tests that otherwise might be difficult or even impossible to do manually. This includes doing an analysis of large amounts of data or being able to increase the coverage of the audit.
Note
Publications and documents may use the acronym CAAT rather than CAATT. In general, the term can describe both tools and techniques. In addition, it is not uncommon to see the acronym use the term "aided" rather than "assisted."
Although there are many specialized audit-specific tools available, even an office spreadsheet application is considered a CAATT. The tools and techniques include general audit software, audit expert systems, utility software, and even simple queries and scripts. CAATTs are used for many different functions, including the following:
Testing transactions within applications
Reviewing procedures
Testing system and application controls for compliance
Conducting automated vulnerability assessments
Performing penetration testing
During the course of an audit, one of the objectives of the auditor is to produce evidence. Much of the process will still be manual. The use of CAATTs, however, is able to produce much more evidence than what would be possible manually. Prior to using an automated or computer-based tool, the auditor should first be familiar with the tool and have the necessary knowledge and skills required. The auditor should also take necessary steps to be successful and to limit the risk of using such tools during the process. Examples include:
Establish any related resource requirements. This includes making sure the needed IT facilities, equipment, data, and personnel are available and accessible.
Understand the type of data to be examined. This includes how much data, what type of data, and the format of the data.
Many organizations use automated audit reporting tools. Most systems, for example, are capable of producing many different types of audit logs. These logs detail various types of activity throughout the system, including security data. Examples include:
Failed authentication attempts
Technical policy changes
Account changes
Privileged use
Traditionally, the challenge is managing the voluminous amount of data generated by these systems. This problem is further compounded considering the number and different types of systems across an organization. The components within the seven domains of typical IT infrastructure, for example, are all capable of producing audit trails or log data. Making matters more difficult is that an event generated in one domain may likely contribute to other events being generated in the other domains. Yet by maintaining a silo approach to storing and managing this data, correlation of events is not easy and might be impossible.
Fortunately, automated solutions are available and in use by many organizations. These solutions aggregate all of this data centrally and provide mechanisms to correlate, alert, and report upon this data. These solutions can provide meaningful data from otherwise huge amounts of raw log data. From an organizational perspective, automated audit reporting tools or information and event management help simplify compliance, improve security, and optimize IT operations. Specific examples include:
Meeting compliance regulations requiring the retention and review of audit records
Identifying security incidents, such as policy violations and fraudulent activity
Diagnosing and preventing operational problems
Conducting forensic analysis
Establishing operational, security, and performance baselines and being able to identify new trends and problems
Reporting upon historical data
Table 6-4 provides a sample set of taxonomy for data collected and associated sample events. Security operations should regularly review the data, from which meaningful information can be abstracted. Additionally, operations should leverage programmatic alerts and correlation rules to help identify suspicious activity.
Table 6-4. Types of log data and information the data might reveal.
DATA CATEGORY | COMMON EVENTS | SUSPICIOUS ACTIVITIES REVEALED |
|---|---|---|
Computer performance | Resource usage, errors, availability, shutdowns, and restarts | Unauthorized use, compromised systems, denial of service (DoS) attacks |
Network performance | Traffic load, errors, network interface status, network scans | DoS and distributed denial of service (DDoS) attacks, information-gathering activities as a precursor to actual attack |
Users | Logon and logoff data, privilege use and modifications, failed system access attempts | Brute force attacks on passwords, compromised accounts, privilege abuse |
Applications | Application-specific events depending upon type, such as Web servers, firewalls, databases, remote access servers, and Domain Name System (DNS) | Attempts to exploit vulnerabilities, brute force attacks, information-gathering activities as a precursor to actual attack, DoS attacks |
File system | Access to data, changes to access control lists, changes to file properties, file additions, and file deletions | System compromise, privilege abuse |
Audit and logging systems need to be maintained to perform an efficient analysis of events. Whereas a single failed logon, for example, might not be a cause of concern, many rapid failed logon attempts should be. Maintaining and managing audit logs through the use of these systems also provides the organization with a great mechanism to respond to audit requests. This, of course, provides an auditor with a trove of available data to support the evidence-gathering process. Auditors can take, for example, a representative sampling of logs from the various systems across the IT infrastructure to ensure that automatically audited events comply with the stated policies and procedures.
Managing the configuration of information systems is traditionally a function of IT operations. Configuration management, however, has a direct impact on information security and compliance. As a result, security configuration management (SCM) pertains more specifically to the configuration items that are directly related to controls or settings that represent significant risk if not managed properly. This includes the controllable parameters for hardware and software. Configuration management as a program is made up of several pieces, such as:
Configuration change control board—A group of personnel with responsibility for governing configurations and configuration changes
Baseline configuration management—The plan for establishing the basic standard of system configurations and the management of configuration items
Configuration change control—A process for managing changes to the configuration standards defined for information systems
Configuration monitoring and auditing—A process for identifying current configurations and testing configurations against established baselines
The configuration includes the specifics on a system's settings. Auditors can review the implementation of configuration items to ensure that prescriptive controls are put in place. The configuration can then be compared with standards and procedures. This task is difficult, however, in the absence of the previously mentioned components of a configuration management program. Even with a change control process in place, systems undergo unauthorized and untracked changes. These changes can directly impact the security of the systems. In addition to unauthorized changes, monitoring helps identify:
Misconfigurations—Identifies authorized changes are correctly put in place and remain in place
Vulnerabilities—Identifies missing system patches as well as configuration items related to a missing patch to determine and prioritize risk
Unauthorized systems and software—Identifies systems not managed by a configuration monitoring solution as well as identify software not authorized for use on the managed system
What makes configuration management especially useful for auditors is that most of the data about the systems is contained with a configuration management database (CMDB). The CMDB provides a central repository from which reports can be run. Thus, everything about all the systems at a particular point in time is stored in a database. Examples of configuration items include:
Operating system type
Service pack level
Security patches
Software installed
Users
Device drivers
Hardware configuration
Service and port status
Access permissions
Authentication controls
Audit settings
Protocols
Many configuration monitoring and auditing solutions are capable of providing predefined templates, from which the configuration items can be assessed. Many of these templates are based on industry-recommended practices such as those from NIST. In addition, organizations can configure auditing templates to align with their own internal policies and standards. The following are sample templates that can be programmatically run to assess parameters specific to the template:
Operating system—Can include audit templates for each version of the operating system across UNIX, Linux, Macintosh, and Windows, for example
Database—Can include audit templates for different types of databases that verify the database security and configuration parameters
Application—Can include audit templates to assess applications for expected configurations
Network device—Can include templates to verify appropriate settings across the network infrastructure, such as routers, switches, and firewalls
Best practice documents—Can include templates to be run across different parts of the infrastructure to test for compliance based upon recommended practices from organizations such as NIST or the Center for Internet Security (CIS)
Regulations and standards—Can include templates specifically targeted to assess against regulations such as the Health Insurance Portability and Accountability Act (HIPAA) or industry standards like PCI DSS
When systems aren't compared against acceptable baselines, the systems could be configured inconsistently a number of different ways. Configuration management and the use of monitoring tools ensure that systems stay configured as originally intended. This makes systems easier to troubleshoot and maintain and makes them more secure.
Auditing the security controls across the IT infrastructure involves testing the controls or countermeasures using available documents, interviews, and personal observation.
This section provides an overview of testing and validating controls based upon NIST SP800-53A, which provides an approach to assessing security controls. Regardless of the exact methods used, however, the principles are the same.
Each control to be tested should have an accompanying assessment objective. The objective provides the foundation or high-level statement to determine the effectiveness of the control. Based upon this, one or more assessment objectives are validated using a specific method. These methods, discussed in Chapter 1, include examination, interviews, and testing. The results of using these methods against particular assessment objects will produce the results, which are the determination as to the effectiveness of the controls. The assessment objects vary and include different types of elements. Three broad categories of objects include the following:
The effort required to assess controls will vary not just across the objectives. The auditor should also consider impact levels, or the sensitivity and importance of the information systems. The effort is directly related to the depth and breadth of the particular assessment. NIST's assessment framework uses the terms depth and coverage and also defines their associated values. A summary of these definitions includes:
Depth—Addresses the thoroughness and level of detail in the examination, interview, and testing process
Coverage—Addresses the breadth of the examination, interview, and testing process of objects
Depth and coverage each have three different values. The values that address depth include generalized, focused, or detailed. The values that address coverage include representative, specific, and comprehensive. Representative coverage makes use of a limited sample of assessment objects. Further, the goal is to determine that a security control is put in place and that there aren't obvious faults. More specific coverage builds upon this by increasing the scope to achieve greater confidence that the control is not only put in place correctly with no obvious faults, but also operating as intended. Finally, comprehensive coverage uses a much larger sample of assessment objects to achieve the results of representative and specific coverage. It also ensures the control is operating on an ongoing basis that is continually improved.
The varying levels of depth have the same relative expectations. This includes making sure controls are put in place and free of obvious errors. It also includes making sure that the controls are consistently operating as intended and are supported by continual improvement. Interviews and document reviews at a general level include high-level discussions and examination. A more focused assessment asks questions in greater depth and requires a more detailed analysis of documents. Finally, a detailed assessment includes asking deep, probing questions and performing thorough analysis of documents across a greater body of evidence.
In addition to interviews and document review, testing depth requires methodologies of varying degrees of knowledge about the environment being tested. This includes having no knowledge of the infrastructure or implementation of a control to having considerable and extensive knowledge of both the infrastructure and details about the control.
Based upon the tests of each control, an unbiased and factual determination is made as to the effectiveness of the control. The control should either satisfy or not satisfy the expected state. In some situations, the auditor will not be able to determine how effective a control is because of lack of information or other inability to test. In situations where the objectives of the control are not fulfilled, the auditor needs to understand and document how the control differs from what is expected. In addition, the auditor should note how these findings affect confidentiality, integrity, and availability.
An audit of an IT infrastructure should address the objectives stated within the plan. It should also comply with laws and professional standards of auditing. The audit seeks to discover evidence from which a conclusion can be made. This conclusion is based upon the analysis and interpretation of the evidence. Despite the best plans and intentions, however, issues can occur and things can go wrong.
To prevent problems from occurring, the auditors must start with the plan. Clear expectations are a common problem with many audits but are easily addressable. The appropriate parties should clearly understand three key points. First, they should understand why the audit is being conducted. Second, they should understand what the scope and objectives are. Finally, they should understand what happens upon completion of the audit.
In addition, interviews and interactions with IT staff are critical throughout the entire audit. Auditors should be careful not to neglect the concerns of the people within the organization. This occurs when auditors are focused entirely on the technology and the gathering of quantifiable data.
NIST defines several areas of potential challenges when conducting security testing and assessments. All of these areas could potentially apply to an audit as well. These areas include:
Time and resources—The importance of a solid plan is critical to maximizing the use of available time and resources. Both are sometimes underestimated for many different reasons. For example, systems might not be able to be tested during normal business hours. Often, there is only a small window of opportunity each day. Because technology evolves so quickly, assessors and auditors might find that they don't have the requisite skill set to adequately perform specific actions.
Resistance—IT personnel might be resistant to an assessment or an audit for many reasons. Operationally, IT personnel might have concerns about outages. On a personal level, individuals might be defensive and fearful for their jobs or fearful of being reprimanded.
Temporary behavior—Users and operators might adjust their processes and systems they are responsible for prior to an audit or an assessment to comply with policies. Upon completion of the audit, however, systems and behaviors often return to the state prior to the audit or assessment.
Immediate response—As weaknesses or audit deficiencies are uncovered, there might be a desire to immediately address the issue. Although generally acceptable and encouraged, changes need to adhere to the organization's policies and change management procedures.
Changing technology—Technology and the tools used to assess technology are constantly evolving. As a result, auditors need to be committed to ongoing information technology education, including the use of new tools and techniques.
Operational impact—There is always the possibility that tests might inadvertently disrupt the systems being tested. To limit any negative impact, the assessor or auditor should always maintain proper documentation, including a detailed list of actions being performed.
There are many different roles for security operations and administration across the IT infrastructure. Security operations and administration are responsible for implementing the policy framework to protect the confidentiality, integrity, and availability of the company's information and supporting technologies. The foundation of these operations is first based upon assigning, identifying, and classifying the information and information systems, and then implementing and maintaining the appropriate controls to protect the information and infrastructure.
The tasks include managing authentication and access controls, security hardware, and security software. Security operations and administration personnel are directly involved in the implementation and administration of controls designed to allow access only to those authorized. They also maintain the systems that prevent fraud, violations, and other malicious and even unintentional breaches of confidentiality, integrity, and availability. Security operations and administration personnel need to be held accountable over their responsibilities. Because of the important responsibilities of the security and administration staff, additional safeguards need to be in place to prevent inappropriate use and misconduct.
Those assigned to protect the assets are not above committing irregular or illegal acts. In fact, without the proper controls in place, such activities are easier to perform. This includes fraud, theft, suppression of information, and other legal violations. Examples of safeguards that need to be verified include:
Security operation policies—Policies form the foundation for holding staff accountable. The policies define the expected behaviors that need to be complied with by security and administration personnel. Periodically testing the staff on the organization's policies helps increase accountability.
Assignment of responsibilities—Those assigned with security and administration roles need to have clear expectations and responsibilities. This helps foster and enforce accountability within the individual roles.
Maintenance procedures—These provide clear guidance for the security operations and administration staff in the performance of their duties to prevent misconfigurations and errors.
Segregation of duties—Segregation of duties divides roles and responsibilities so a single individual or group can't undermine a critical process. From an IT perspective, this includes, for example, separating testing, development, and production environments to prevent unauthorized changes. Another example includes preventing the person who approves configuration changes from being the person who implements them. Segregation of duties is also referred to as "separation of duties" or "separation of responsibilities."
Rotation of duties—Rotation of duties rotates employees into different functions, and helps mitigate collusion to circumvent what segregation of duties helps prevent.
Least privilege—Least privilege involves users only having access to what they need to perform their duties.
Mandatory vacation—For sensitive positions, a contiguous one-week vacation should be required. This reduces the opportunity for an employee to commit unethical or illegal acts. It allows others to fill in to support the position and verify the work being performed.
Screening—Employees responsible for managing security and sensitive data within an organization should be carefully screened prior to employment. This includes background checks, for example, to ensure the individuals are appropriately suited for the position.
Training and awareness—A continuous program of training is necessary to ensure employees understand their responsibilities associated with their duties and are adequately prepared to perform them effectively.
Security operations and administration personnel need to be held accountable. Strong accountability also serves the goal of preventing fraud and inappropriate use.
Conducting an IT infrastructure audit for compliance first depends upon an adequate plan. Establishing baselines and identifying an acceptable level of risk across the environment provides a starting point for the actual audit. From there, the audit can follow common methodologies, while being flexible based upon the expanse of the audit. In addition to the documents gathered during the discovery phase, the auditor should continue to gather and use available resources during the audit. This includes continued interaction with the organization, the use of computerized audit tools, and available configuration information and audit logs. Upon completion of the audit testing, a final report should be prepared.
Baseline controls
Computer assisted audit tools and techniques (CAATT)
Configuration management database (CMDB)
Information Systems Security Assessment Framework (ISSAF)
Internet Protocol (IP) address
Network scan
NIST 800-15
Open Source Security Testing Methodology Manual (OSSTMM)
Risk appetite
Risk tolerance
Rotation of duties
Security configuration management (SCM)
Transmission Control Protocol/Internet Protocol (TCP/IP)
Vulnerability scan
The decision to apply or not apply controls is based upon risk.
True
False
Which one of the following is the best example of avoiding risk?
The IT department decides to install an antivirus device at its network border.
The IT department outsources its vulnerability management program to a third party.
The IT department disables the ability for end users to use portable storage devices.
The IT department installs data loss prevention software on all end users' workstations.
Which of the following is an examination of the current state of controls against the desired state of controls?
Control objective
Gap analysis
Baseline analysis
Log review
The purpose of a network scan is to identify as many vulnerabilities as possible.
True
False
A ________ is an assessment method that uses methods similar to what a real-world attacker might use.
Which one of the following is not an example of a review technique?
Password cracking
File integrity checking
Log review
Network sniffing
If required, an auditor is justified in the use of security assessment techniques, such as penetration testing and vulnerability analysis, and may consider using the work of other experts.
True
False
What does CAATT stand for?
Which of the following are examples of information provided by audit logs?
Failed authentication attempts
Account changes
Privileged use
All of the above
Which of the following benefits does an automated security information and event management log solution provide?
Diagnosing and preventing operational problems
Assigning appropriate responsibilities to security operations
Management of a configuration change control board
All of the above
A configuration ________ database provides a central repository of configuration items.
Which one of the following best describes an assessment objective for a control?
A high-level statement to determine the effectiveness of a control
A detailed statement on what activities need to occur to implement a control
A definition of responsibilities to be assigned to security operations for the management of a control
A statement to the required depth or coverage required to test a control
Which one of the following is not an example of a level of depth required to assess a control?
Comprehensive
Generalized
Focused
Detailed
Which of the following best describes documents such as policies, procedures, plans, and architectural designs?
Specification objects
Mechanism objects
Activity objects
Configuration objects
Preventing a user who approves a configuration change from being the person who implements the change is an example of which of the following?
Rotation of duties
Least privilege
Segregation of duties
Dual control
1. "IIA Information Controls." (The Institute of Internal Auditors, 2005). http://www.scribd.com/doc/8340647/IIA-information-controls (accessed April 19, 2010).
2. Schneier, Bruce. "The Psychology of Security." http://www.schneier.com/essay-155.html (accessed April 19, 2010).
3. "IS Auditing Standard, Performance of Audit Work, Document #S6." (ISACA, 2004). http://www.isaca.org/AMTemplate.cfm?Section=Standards,_Guidelmes,_Procedures_for_IS_Auditmg&Template=/ContentManagement/ContentDisplay.cfm&ContentID=15388 (accessed April 19, 2010).