Understanding Auditing and Accountability

Chapter 1 introduced the AAAs of security: authentication, authorization, and accounting. When used together, they ensure that only authorized entities (such as users and applications) can access systems or data and that a record of such activities exists. Chapter 2 presented access controls, including the three primary authentication factors, and different access control models. Auditing provides the accounting component, which tracks and records individual actions.

There are two primary methods used to perform auditing. They are different processes, but both methods are part of an overall auditing strategy:

•  Auditing activity through logs   Audit logs record activity and can be inspected by auditors at any time to reconstruct events. Logs may be on servers, firewalls, routers, or any other type of device.

•  Auditing activity through an inspection process   Periodic security audits inspect an organization to determine whether the organization is following required policies and procedures. For example, a security policy may state that inactive accounts should be disabled immediately and deleted within 60 days after an employee leaves. An inspection can detect if this policy is being followed.

Holding Users Accountable with Audit Logs

If the organization uses strong authentication practices, administrators, security personnel, and auditors can use the audit logs for accountability. As an example, Figure 10-1 shows a Security log entry from Windows 10. The entry shows that a user named Darril Gibson read a file named PayrollData.rtf in the C:Payroll folder using the WINWORD application.

Figure 10-1   Windows 10 Security log entry

It could be that Darril is a hiring manager and needs access to that file on a regular basis. It could also be that Darril is an administrator completely uninvolved in the accounting or payroll department and abused his administrative privileges by accessing the file.

It’s worth repeating that strong authentication is an important element here. If weak passwords are used, Darril could claim that he never looked at the file and suggest that someone guessed his password and impersonated him. On the other hand, if the organization implemented multifactor authentication and Darril was required to log on with a smart card and personal identification number (PIN), he won’t be able to deny that he accessed the file. In this case, the audit logs provide nonrepudiation.

Other access control methods, such as video cameras and badge reader logs that record when someone enters or exits a secure area, provide added accountability. If these other methods documented that Darril was in the general location, they provide additional evidence for accountability.

Sometimes, a higher authority mandates specific accounting practices. For example, the Federal Information Processing Standards Publication 200 (FIPS Pub 200) published by the National Institute of Standards and Technology (NIST) specifies that federal agencies must meet at least the following minimum requirements:

(i) create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; and

(ii) ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions.

Although this squeezes many words and phrases into a single long sentence, it does provide a good summary of the requirements of audit logs for federal agencies. It’s also a good summary of the requirements any organization can use when implementing auditing and accountability.

Auditing with Logs

Audit logs record details such as who, what, when, and where for any events of interest. For example, Figure 10-1 (shown earlier) allows you to identify who took an action, what action the user took, when, and where:

•  Who   The local user account Darril Gibson on the computer named DarrilLaptop (DarrilLaptopDarril Gibson).

•  What   Darril read the ParyrollData.rtf file using the WINWORD application.

•  When   The entry was logged on March 19, 2018 at 12:00 P.M.

•  Where   The file was in the C:Payroll folder on the Windows computer.

This example shows Darril read the file. If Darril modified or deleted the file, the audit log could also show those actions, depending on how administrators configured logging.

The primary purpose of auditing is to be able to reconstruct events leading up to and occurring during an incident. A secondary purpose is to serve as a deterrent. In other words, if users are aware that logs record their activities, they may be less likely to engage in unauthorized activities.

As an example, imagine an organization has an acceptable use policy (AUP) that states that users should only use computers and networking resources for work purposes. The AUP specifically prohibits accessing specific categories of websites, such as gambling sites. Non–work-related sites could easily be malicious and attempt to infect user systems with malware. However, if users know they shouldn’t be visiting these sites and that logs are recording their activity, they may be less likely to visit these sites. The net effect is a reduction of incidents.

Proxy servers can block user access to unauthorized sites. Many organizations configure the proxy server to display a warning page when users attempt to visit unauthorized sites. These warnings often repeat the relevant information from the AUP. They also show the user information that the proxy server has logged, such as the username, the URL of the blocked site, and the date and time when the user attempted to access the site.

Clipping Levels

Many automated accounting systems generate alerts after the system detects a preset number of events. The system accepts or ignores these events until they reach a predetermined threshold, or clipping level. A classic example is a report based on failed logon attempts. Instead of reporting every single failed logon attempt, a system uses a clipping level to generate a report only if an account has exceeded a set number of failed logon attempts in a given period.

For example, administrators can configure an accounting system to generate a report if a log records three failed logon attempts in a 30-minute period for a single user account. If a user enters the wrong password once or twice, the system ignores those attempts as acceptable, normal user errors, and doesn’t generate a report. However, if a user enters the wrong password three times within 30 minutes, it exceeds the clipping level, and the accounting system generates an alert.

Some automated auditing tools such as security information and event management (SIEM) tools, discussed in Chapter 8, perform audit-reduction tasks. In other words, they can examine a log and retrieve relevant data from the log while ignoring the irrelevant data. These audit-reduction tools use clipping levels to identify events of interest based on predetermined thresholds.

Understanding Audit Trails

An audit trail includes one or more logs that track events occurring on a system or network. When auditors have access to all the logs, they can re-create the events that occurred leading up to the incident and determine what actually occurred during the incident. In other words, the audit logs allow auditors and administrators to re-create all the activity, or the trail of activity, created by an individual or process.

For example, if an attacker launched an attack on a web server in a demilitarized zone (DMZ), you could use firewall logs on the external firewall to identify the path the attacker used to get into the DMZ. You could then use the logs on the web server itself to track what the attacker did once he reached the web server. Logs on the web server could include host-based firewall logs, system logs, and security logs.

In some cases, the “who” identifies a specific account, such as a user account. In other situations, the “who” identifies the source of activity, such as an IP address. It’s worth noting that many attackers launch attacks through other locations or spoof the source IP address. In other words, the logged IP address doesn’t always provide the actual IP address of the attacker.

An audit trail is a technical detective control. However, when configuring or evaluating an audit trail, you should consider the following items to ensure it is effective as a detective control:

•  Does the audit trail provide a full accounting of user activity?   For example, does the audit trail record who, what, when, and where?

•  Is access to the logs controlled?   If anyone can access the logs, it makes it easy for attackers to erase the logs after an attack.

•  Are copies of logs stored on remote servers?   This ensures that even if an attacker erases or corrupts a log file after an attack, the remote server still holds a copy of the original logs.

Exploring Audit Logs

There are many different types of audit logs on computing and networking systems. Operating systems include regular logs that record activity on the computer; applications frequently record information in application logs based on the needs of the application; and network devices (such as routers and firewalls) regularly record different types of data to document network activity.

This section describes many of these logs. It also describes how administrators and auditors use these logs to track activity. Together, these logs can help an organization create a comprehensive audit trail documenting activity on individual systems and networks.

Operating System Logs

Operating systems include logs that track activity on individual computers and servers. Operating systems also provide the means to review these logs, such as the Event Viewer in Windows systems. Older Microsoft operating systems included at least the System, Application, and Security logs, but newer Windows operating systems include additional logs that record information on specific applications and services installed or running on the system.

Security logs can record activity from any auditable activity and can record both success and failure events. In other words, if a user tries to open a file and successfully opens it, it is a success event. However, if the user doesn’t have appropriate permissions, the system blocks the user’s access and can record it as a failure event. Security logs don’t record all activity by default, but instead require administrators to configure logging based on the organization’s needs. For example, an administrator can configure object access logging for objects such as folders, files, or printers, and then when a user accesses one of these objects, the security log records the event. Other auditable security events include deleting or modifying files or folders, modifying system settings such as the system time, modifying permissions, and more.

Some of the logs used in Windows systems include

•  Security log   Records security-related events such as when an account logs on or off or any auditable event. Administrators often configure specific items to audit based on the needs of the organization.

•  System log   Records events from the operating system, such as when the system boots or is shut down, and when a driver or service stops or starts.

•  Application log   Records events from applications. These events can be from end-user applications, such as a web browser, or server-based applications, which include database server applications and networking services, such as a server running the Domain Name System (DNS) service. Applications can log data in the generic Application log or create an application-specific log and log events in the application-specific log.

•  Setup log   Records events related to the setup of certain applications.

Microsoft has included additional features with logs in Event Viewer. For example, Figure 10-2 shows the Event Viewer in Windows 8 displaying some of the information from a successful logon event. Event Viewer allows you to view details from any of the captured events. You can also see Forwarded Events and Subscriptions in the left pane of this figure. Administrators create subscriptions on a central system that collects forwarded events from other systems. This allows administrators to monitor events from multiple systems in the network from a centralized computer.

Figure 10-2   Microsoft Event Viewer

If you manage 10 servers hosting Microsoft SQL Server databases, you can forward relevant events to an 11th system to monitor all of these servers. The original servers will still hold the original logs. However, the monitoring server hosts a copy of the logs in a remote location. Even if an attacker modifies the logs on one of the servers after an attack, the remote server still holds all the log entries within the Forwarded Events log.

Storing Logs on Remote Systems

Chapter 8 mentioned that attackers could modify logs stored on a local system (rather than a remote system). Administrators and investigators should view these local logs with suspicion after an attack.

However, if you can store the logs on remote systems, it is much less likely that an attacker will be able to modify these remote logs. In other words, by storing logs on remote systems, you can help retain their integrity. A common way to store logs on remote systems is to forward them to a SIEM application.

*Nix Logs

UNIX and UNIX derivatives (such as Linux) are often referred to as *nix systems, and these systems have their own types of logs. The log file locations sometimes vary from one version to another, but there are some similarities. For example, system and accounting log files are usually in one of the following directories: /var/log, /var/adm, and /usr/adm.

Syslogd is a service that typically receives all the log entries and then moves them to a log based on how it is configured. The syslog.conf file specifies the configuration. If the configuration file is not available or is blank, syslogd will move the log entries to the syslog (/var/log/syslog). If the file is available, syslogd can specify any log for log entries. As an example, the following line will ensure all mail messages are sent to one log:

mail.* /var/log/maillog

Some of the common *nix log files and their contents include the following:

•  syslog   Many security processes and other utilities write to syslog. It’s often a good place to view overall system activity.

•  sulog   This log records all attempts to use the su command. The su command (sometimes called the super user command) grants the user elevated privileges. Attackers often attempt to use su in various attacks, and uneducated users can misuse it.

•  auth   This log records authentication events on a Secure Shell (SSH) server. You can use it to determine whether a system intrusion has occurred. For example, a brute-force attempt to log in to the system will show multiple failed SSH login attempts, usually from multiple usernames.

•  maillog   The system records inbound and outbound mail activity in this log.

Proxy Server Logs

Most proxy servers can log all activity through the proxy server. This allows an organization to track websites that users access with their web browsers, how much time they spend on the sites, and all attempts to visit unauthorized sites. Chapter 4 presented proxy servers. As a reminder, an organization typically uses a proxy server for caching and URL filtering.

You may recall that an organization can use a proxy server to retrieve web pages from the Internet on behalf of internal clients. The proxy server uses Network Address Translation (NAT) to translate private addresses from internal clients to public addresses used by Internet-based websites. The proxy server caches web pages. If a user requests a cached web page, the proxy server sends the page to the user without retrieving it from the web server again. This reduces Internet bandwidth usage.

URL filtering prevents users from accessing unauthorized websites. If a user attempts to go to an unauthorized website, the proxy server blocks the request. As mentioned earlier in this chapter, proxy servers can also log these unauthorized attempts. When a user visits an unauthorized site, some organizations display a warning similar to that shown in Figure 10-3. When users see that the proxy server is logging their activity, they may be less inclined to circumvent the policy.

Figure 10-3   Proxy server warning

Of course, it’s possible that a user has a legitimate need to access unauthorized websites. Organizations typically include a process allowing users to ask for an exception to the policy.

Firewall Logs

Most firewalls include the ability to log all activity sent in and out of a firewall. This includes traffic that the firewall blocks, traffic that it passes, or both. These logs can be very useful when trying to reconstruct the events from an attack. For example, after discovering an attack on an internal system, you can use the logs from firewalls at the edge of your network to determine whether the attack came from an external attacker on the Internet or from an internal source.

SIEM applications commonly use firewall logs to detect attacks such as port scans or TCP flood attacks. The SIEM application regularly monitors the firewall logs, and when it detects a potential attack, it can log and report the event. Some active intrusion detection and prevention systems (IDPSs) can also take action to block an attack. For example, an IDS can modify the configuration of the firewall to block an attack in progress.

Firewall logs can also provide details on botnet activity. If you suspect that one or more of your internal systems has become a zombie within a botnet, you can check the host-based firewall logs of the system and the network-based firewall logs for suspicious activity. For example, if 20 of your systems are regularly connecting with a system that has an IP address from another country and you don’t recognize that address, it could be an indication of botnet-related activity. The foreign IP address might be the address of a command-and-control server used to provide instructions for zombies within the botnet, or another server that attackers hijacked to provide instructions to the zombies.

Reviewing Logs

One of the most important steps of auditing is reviewing audit logs. Reviewers should look for any types of anomalies in the logs. For example, a long string of failed attempts to log on to the administrator account indicates a potential brute-force attack. If the logs then show a successful logon event for the administrator account, it indicates an attacker probably guessed the password for the account and is now accessing the system with administrative privileges. In this situation, it would be important to examine all the activity by this administrator account.

Admittedly, reviewing logs for anomalies isn’t easy to do. If you’re reviewing thousands of log entries and the log includes one or two abnormal entries, it’s easy to overlook the abnormal entries. However, many automated systems, such as SIEMs, are available that can look for and issue alerts for specific events. Most SIEMs include filters that allow administrators to filter out unwanted log entries.

In some organizations, administrators get overwhelmed with day-to-day activities and skip the reviewing step. However, at the very least, administrators should archive the logs so that they can review them later, if necessary. For example, Figure 10-4 shows how you can right-click any log in Microsoft’s Event Viewer to save the contents of a log. Administrators and auditors can open saved logs in Event Viewer by selecting Open Saved Log and browsing to the location of the saved file.

Figure 10-4   Archiving a log

When you archive logs like this, you can review them later. In other words, even if you don’t notice an incident until much later, you can still re-create the events by reviewing the archived logs.

Managing Audit Logs

In addition to storing logs on remote systems to maintain their integrity, you can take several other steps to improve the security related to logs. A primary step is to protect the logs with permissions.

Access to logs should be restricted to personnel (such as administrators) who have a need to view or maintain the logs. If anyone can clear the logs, users might erase logs accidentally. Similarly, if anyone can clear the logs, attackers will be able to do so to erase their activity after an attack.

Many organizations mandate the retention of logs for a specific period such as three years or longer. This allows an investigator to go back in time to reconstruct events even if several months or years have passed. Log retention policies require someone to archive the logs periodically. In smaller organizations, administrators do this manually. Larger organizations use automated processes to archive logs. In some scenarios, organizations write the archived log data to a write once, read many (WORM) drive to prevent someone from rewriting the archived logs.

Performing Security Audits

A security audit examines an organization’s practices and operations to determine whether they conform to the organization’s policies or applicable laws. An organization can perform an internal audit to examine its practices, or external auditors can come in to examine the organization’s practices. The audit documents the organization’s policies, processes, controls, testing, and results. The following sections discuss various audit practices.

Periodic Audit and Review

Audits can be performed on a periodic basis, such as once a year, after an event such as a security incident, or when required by laws or guidelines. Audits are detective controls because they detect events after they’ve occurred.

As an example, an organization can perform monthly vulnerability scans to check for unused accounts. Many policies mandate disabling accounts when an employee leaves, or even if the employee takes an extended leave of absence. These scans can detect accounts that are enabled but unused. Similarly, an organization can perform an annual audit of processes within the organization to determine if these processes comply with the organization’s security policy. Organizations also perform these types of audits after an incident to determine if personnel are complying with existing policies. For example, after a successful malware attack, an audit can help determine if the infection was due to personnel not following existing policies.

Organizations that must follow certain laws and guidelines often use compliance audits to ensure that personnel are complying with the relevant laws and guidelines. Internal compliance audits provide proof to outside entities that the organization is taking steps to ensure compliance. For example, if a U.S. organization handles any type of health- or medical-related data, it must comply with the Health Insurance Portability and Accountability Act (HIPAA). If an incident occurs showing a violation of the law, the organization can show documentation from past audits as proof that the organization is taking active steps to be compliant with the law. However, if no past audits exist, the organization may find itself incurring significantly higher fines and penalties after a security incident.

In other situations, organizations hire external auditors, but typically only when they are required to do so. For example, the Payment Card Industry Data Security Standard (PCI DSS) requires some organizations that handle credit card data to hire an external auditor after the organization has suffered a data breach.

Auditing Passwords

A password audit checks to see whether users are following the policies related to passwords. For example, a password policy may dictate that regular users use strong passwords with at least three of the four character types (uppercase, lowercase, numbers, and symbols) and be at least eight characters long. A password audit could use a password-cracking tool to determine whether any passwords fail to meet these requirements. The password audit could also check to see if users are regularly changing their passwords in compliance with a written password policy.

I know from experience that just asking users to use strong passwords and expecting that they will, or just asking them to change their passwords regularly and expecting that they will, works about as well as getting a cat to come to you when you call. In general, you can’t expect most users to take secure actions on their own.

Instead, organizations use technical controls to implement written password policies. For example, Microsoft operating systems use a technical password policy within Group Policy to force users to create strong passwords and change them regularly. Third-party tools are also available that can enforce the use of strong passwords, but they do cost money. However, if a password audit shows that users are using weak passwords and not following the written policy, the cost of a password enforcement tool is justified.

Auditing Security Policies

Many organizations require an annual review of a written security policy to ensure that the policy still meets the needs of the organization. Auditors can examine historical data from the past year to see whether users are following the security policy. They can also examine details of security incidents to help them determine if the policy is helping the organization prevent security incidents.

For example, some security policies look great on paper, but employees never hear about them. This often results in users repeating the same mistakes year after year. Social engineers may continue to trick users, or employees might not follow specific procedures simply because they are unaware of the policies. In this case, the audit may discover a lack of security awareness and recommend specific actions such as security training to improve employee awareness.

ISACA

ISACA is an international organization that provides standardization for IT professionals involved in auditing. It includes more than 110,000 members from more than 180 countries working in various IT-related positions, such as IS auditor, internal auditor, consultant, educator, IS security professional, and chief information officer (CIO).

Two of ISACA’s top auditing certifications are the Certified Information Systems Auditor (CISA) and the Certified Information Security Manager (CISM) certifications.

•  CISA   The CISA certification identifies individuals who audit, control, monitor, and assess an organization’s information technology and business systems.

•  CISM   The CISM certification is management-focused and identifies individuals who design, build, and manage enterprise information security programs.

ISACA developed the Control Objectives for Information and Related Technology (COBIT) framework. COBIT is a robust framework that helps managers identify processes to manage IT systems and it is one of the popular management frameworks. COBIT 5 is based on five principles and seven enablers, which are generic enough that organizations of any size can apply them.

Exploring PCI DSS Requirements

The Payment Card Industry (PCI) Security Standards Council created and regularly updates the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS requires that organizations that process credit card payments comply with specific steps to protect customer account data, and it includes a strong focus on protecting credit card data. The goal of PCI DSS is to reduce overall credit card fraud, and toward that goal it specifies 6 control objectives with 12 supporting requirements related to security management, policies, procedures, network architecture, software design, and more.

Table 10-1 provides an overview of the PCI DSS (Version 3.2) objectives along with the specific requirements associated with these objectives.

Table 10-1   PCI DSS Control Objectives

Compliance Reports

Organizations that fall under the PCI DSS must submit regular compliance reports. These reports identify the business and its use of credit cards. They also document the business’s network, including its hardware, software, and connectivity, and how the business complies with each of the 12 requirements. However, organizations do not send the reports to the PCI Security Standards Council. Instead, organizations send the reports to the acquiring bank (the bank handling the credit card transactions) and the global payment brand (such as Visa, MasterCard, and American Express).

Compliance Audits

Businesses are also required to perform periodic audits to verify their compliance with the PCI DSS requirements. Businesses that don’t have a high volume of credit card use can perform the compliance audits internally. These organizations can often just answer a Self-Assessment Questionnaire (SAQ) and submit it to the acquiring bank. However, businesses that have a high volume of credit card use must hire an independent expert to perform an audit. The PCI Security Standards Council certifies Quality Security Assessors (QSAs) and Approved Scanning Vendors (ASVs) to perform these audits. A QSA is an external data security firm that is qualified to perform an onsite audit. An ASV is an external data security firm using an authorized vulnerability scanner. An Internal Security Assessor (ISA) is an employee of the organization who has obtained the ISA certification after attending training at PCI DSS. An ISA can perform some onsite audits.

The PCI Security Standards Council can fine businesses that don’t comply with the PCI DSS requirements, or revoke the businesses’ authorization to process credit card payments. This provides a high level of motivation for businesses to ensure they comply with the PCI DSS requirements.

PCI DSS Merchant Levels

Organizations have different requirements based on their merchant level. It’s easier for an organization identified as Merchant Level 4 to verify compliance with PCI DSS requirements than it is for an organization identified as Merchant Level 1. The details that classify what level a merchant falls under vary for different credit cards. The following list summarizes the general guidelines for PCI merchant levels:

•  Merchant Level: 1   The merchant processes over 6 million transactions annually. The merchant must submit an annual Report on Compliance (ROC) completed by a QSA, along with quarterly network scans completed by an ASV.

•  Merchant Level: 2 The merchant processes between 1 million and 6 million transactions annually. The merchant must submit an annual SAQ or submit an annual Report on Compliance (ROC) completed by a QSA (depending on specific credit card requirements). The merchant must also ensure quarterly network scans are completed by an ASV.

•  Merchant Level: 3   The merchant processes between 20,000 and 1 million transactions annually. The merchant must submit an annual SAQ and ensure quarterly network scans are completed by an ASV.

•  Merchant Level: 4   The merchant processes less than 20,000 transactions annually. The merchant must submit an annual SAQ and ensure quarterly network scans are completed by an ASV.

Auditing Physical Access Controls

If an organization has physical access controls, it can periodically perform an audit to determine whether these controls are effective. Physical access control audits can also verify if personnel are using the controls or attempting to bypass them.

As an example, many proximity card badge readers have the capability of recording the date and time when an individual enters or exits a secure area. If personnel consistently use their badges to enter and exit the area during the day, the logs would show this. However, if users frequently tailgate each other without using their badges, the logs would show inconsistencies. Each entry showing a user entered the area should have a matching entry for the user when they exit the area.

Chapter 5 covers tailgating in more depth. As a reminder, tailgating occurs when someone passes through a controlled entry point without providing credentials. Instead, the person follows closely behind someone else who has provided credentials. In this scenario, the first person opens the door with a proximity badge and the second person tailgates the first person, bypassing the physical security control.

Physical access logs can also identify whether users are entering secure areas outside of normal work hours. For example, if an employee normally works from 9 to 5 during the week but a log shows the employee entering at 10 P.M. one evening, it might indicate a problem. However, if the logs don’t exist, or there isn’t a method of reviewing the logs, the organization may not detect this potentially malicious activity.

Understanding Configuration Management

Configuration management is the practice of ensuring that systems are configured with security in mind and that configuration is tightly controlled. Many organizations use configuration management to configure systems with a secure baseline and to ensure the system remains secure with the same configuration.

As an example, administrators ensure that servers start with similar system configurations that make them more secure from the default configuration. Administrators use various hardening techniques such as removing or disabling unnecessary services and protocols, and changing default passwords for all the servers. They then tweak the configuration of different groups of servers to meet the needs for these groups. For example, they configure web servers differently than they configure file servers.

The “Holding Users Accountable with Audit Logs” section earlier in this chapter mentioned FIPS Pub 200, which mandates minimum accounting requirements for IT systems. It also lists the following minimum requirements for configuration control:

(i) establish and maintain baseline configurations and inventories of organizational information systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles; and

(ii) establish and enforce security configuration settings for information technology products employed in organizational information systems.

In addition to taking steps to ensure that systems begin with specific configuration settings, an active configuration control plan will mandate that systems be checked periodically. This ensures that the systems maintain the secure settings from the baseline configuration. This process works hand in hand with a strong change management program that attempts to prevent unauthorized changes and the unintended outages caused by unauthorized changes.

Using Imaging for Configuration Management

A common configuration management practice is to use imaging technologies. For example, an organization can deploy each desktop system with a common image that includes the operating system, basic applications, and specific settings needed for usability and security. Images help ensure that every deployed system starts with a secure baseline.

Figure 10-5 shows the overall process of imaging. You start with a clean computer called the reference computer and install an operating system on it. You can then install applications and configure the operating system based on the needs of the organization. For example, you can configure security settings such as auditing, a password policy, an account lockout policy, a password-protected screen saver, and much more. After testing the image, administrators capture it using imaging software. They then deploy the image to other systems, and these imaged systems start with the same configuration as the reference computer.

Figure 10-5   Using imaging for configuration control

Images also make systems easier to maintain. Help desk professionals only need to learn the configuration of one system. No matter what user they are helping, the configuration is the same, enabling help desk professionals to troubleshoot and restore the system quicker.

In contrast, when an organization has 100 computers and each of these computers has a different configuration, support personnel must first figure out how the system should work normally and then take steps to restore it to its original configuration. Effective configuration management programs reduce the overall total cost of ownership of systems by reducing the repair times.

Using Group Policy for Configuration Management

In Microsoft networks, administrators use Group Policy to configure systems. Group Policy allows centralized administration of systems. An administrator can configure one setting with a Group Policy object (such as opening a port on a firewall), and Group Policy applies the change to all the computers within the scope of the Group Policy object. Whether the organization has 50 computers or 50,000 computers, Group Policy can apply the change consistently to all relevant computers in the organization.

Group Policy also supports targeting specific systems, such as all the computers in a specific department or only computers running Windows 7. Administrators with a little knowledge of Group Policy can easily implement configuration control to all their Microsoft systems with very little administrative effort.

Using Other Tools for Configuration Management

Other tools are available for configuration management and these are especially valuable when automating management of non-Microsoft systems such as Linux and other Unix-like systems. A challenge with many of these tools is the learning curve for administrators to master the language of each tool. System administrators often find it challenging to cross the line from administration to writing scripts or developing apps in a programming language. The ones that do are typically the most valuable within an organization. The following list mentions some of these tools:

•  Puppet   Puppet uses Puppet’s proprietary language or Ruby domain-specific language. Many commands must be entered from a command-line interface. It comes in two versions: Open Source Puppet (which is free) and Puppet Enterprise (which has a cost).

•  Chef   Chef uses Ruby to create system configuration “recipes.” Administrators can group multiple recipes together as a “cookbook” to identify packages to install, services to run, and files that should be written.

•  Ansible   Ansible is written in Python, a popular language used to create websites. Administrators can script commands in YAML (YAML Ain’t Markup Language). YAML uses a human-readable data serialization language. It uses SSH to encrypt data sent over the network.

Understanding Change Management

Many organizations have a change management or change control process in place. The primary purpose is to ensure that changes don’t result in unintended outages. Networks are complex, and many of the systems within a network interact with each other. Making a change in one system can easily affect other systems and result in an unintended outage. However, if experts examine these changes before technicians or administrators implement them, the organization can prevent many of the unintended outages from changes.

For example, imagine that a server hosts an application that requires opening TCP port 4567 on a server. Administrators open the port when they configure the server application, and the application runs as expected. Later, a security professional performs a vulnerability assessment and notices TCP port 4567 is open. Thinking this port is a vulnerability, the security professional decides to close the port and reduce the server’s attack surface. Of course, this action breaks the server application. Users begin to complain, and the organization calls in the application developers to troubleshoot the problem. However, it might take them hours, or even days, before they discover the closed port.

Even though the security professional’s intentions are good, the action still caused an outage. You could fill volumes with similar examples of well-intentioned IT personnel making changes, often to correct a minor problem, and in the process creating other problems that cause outages.

In contrast, a change control process ensures that appropriate personnel examine all changes before approving them. It also provides a documentation trail. If the server ever suffers a catastrophic failure, administrators can restore it to its last state, including all the changes applied to the server.

Although many organizations have adopted some level of change management, there is a wide diversity of maturity among organizations. For example, some organizations have a policy for change management, but follow it only for major changes and still suffer outages from many minor changes.

Change Management Process

A change management process gives stakeholders a formal mechanism to propose changes to a system. Multiple entities then examine the change request and either approve or reject it. The following list describes the overall steps in a change control process, as shown in Figure 10-6:

Figure 10-6   Change control process steps

1.   Change submitted Someone identifies the need for the change and submits a change request. The change request identifies the current configuration and the desired change, along with justification for the change.

2.  Change reviewed The review process allows experts within the organization an opportunity to review the proposed change. For simple changes, this can be a quick, informal process, but for major or potential problematic changes, this can require a thorough review by a formal change review board (CRB) or change authorization board (CAB).

3.  Changed approved or rejected The CRB or CAB either approves or rejects the change request. They also analyze rejected changes to see whether a change is required, and if so, they look for suitable alternatives.

4.   Change implemented Personnel implement and document the change. It is also important to ensure that appropriate personnel know about the approved change. If administrators don’t know about changes, they might notice them and then take steps to undo them. If the change is complex, administrators may implement the change on a test system first to ensure it doesn’t cause an unexpected negative impact.

As an example of a change management process, one organization where I worked used an intranet website to submit, review, and approve changes. Experts in different departments reviewed these changes and either approved or suspended them. If each expert approved the request, the CRB approved the request. However, if any expert suspended the request, the CRB reviewed the request at the next meeting.

Identifying Security Impact

When reviewing change requests, it’s important to identify potential security impacts. As an example, imagine someone wants to open incoming port 3389 on a border firewall to enable the use of an application. While it will enable the application, it also opens the port commonly used by the Remote Desktop Protocol (RDP). Many attackers also use RDP to access internal networks, so opening this port brings additional vulnerabilities.

Chapter Review

Auditing is an important component of enforcing accountability. When an organization implements strong authentication and authorization methods, administrators and security personnel can use auditing methods to track user activity and hold individuals accountable for their activity. Most auditing methods use clipping levels to generate alerts only when the system detects the number of events exceeds a predetermined threshold. The auditing system ignores events that don’t meet the threshold. Together, logs create an audit trail that administrators and security professionals can use to reconstruct the events that occurred leading up to and during an incident.

Many different types of audit logs exist. Operating system logs record events on individual systems. These include security logs, system logs, and application logs. Security logs record security events, such as when a user accesses a file. System logs record system events, such as when a service stops or starts. Application logs record application events based on the needs of the application. Proxy logs and firewall logs record activity through proxy servers and firewalls, respectively. An important step related to logs is to review them on a regular basis.

Security audits examine an organization’s practices and operations to determine whether they conform to existing policies or applicable laws. Audits are often required to ensure that an organization is complying with specific external requirements (such as PCI DSS) or laws (such as HIPAA), and internal audits show an attempt to comply with these external requirements. In some situations, organizations are required to hire external auditors to perform audits.

Configuration control ensures that systems are configured using a baseline. This ensures that systems are configured in a secure manner and that configuration is similar (if not identical) for similar systems. Imaging is a common method used to deploy systems with similar needs and configuration requirements. Change management helps prevent unauthorized changes resulting in unintended outages, while also identifying potential security impacts.

Questions

1.  Your organization uses strong authentication and authorization mechanisms and has robust logging capabilities. Combined, what do these three elements provide?

A.  Guaranteed security

B.  Prevention of unintended outages from unauthorized changes

C.  Accountability

D.  Configuration control

2.  An accounting system ignores logon failures until an account has three logon failures within a 30-minute period. It then generates an alert. What is the accounting system using?

A.  Account lockout

B.  Password policy

C.  Snipping level

D.  Clipping level

3.  Which of the following statements best describes a benefit of using clipping levels?

A.  Clipping levels ignore baselines and generate alerts when they detect security violations.

B.  Clipping levels ignore normal user errors but generate alerts when these errors exceed a predetermined threshold.

C.  Audit trails use clipping levels to record all potential alerts for accountability.

D.  Clipping levels ensure systems generate alerts when they detect any potential security violations.

4.  A user entered an incorrect password three times. Now, the user is no longer able to log on. What caused this to occur?

A.  Password policy

B.  Account lockout policy

C.  Clipping level

D.  Audit trail

5.  What do you call a group of one or more logs used to re-create events leading up to and occurring during an incident?

A.  A configuration control program

B.  A change management program

C.  A security audit

D.  An audit trail

6.  What type of control is an audit trail?

A.  Preventive control

B.  Corrective control

C.  Detective control

D.  Physical access control

7.  What type of log on a Microsoft system records auditable events, such as when a user deletes a file?

A.  System

B.  Security

C.  Application

D.  Forwarded Events

8.  Of the following choices, what is an example of an auditable event logged in an operating system’s security log?

A.  Access through a firewall

B.  Accessing a website through a proxy server

C.  Reading a file

D.  The date and time when a service starts

9.  Of the following choices, what is the best example of a log used as a deterrent for internal employees?

A.  Proxy server log

B.  Network firewall log

C.  Security audit

D.  Change management log

10.  You suspect that many internal systems may be part of a botnet. What log would you review to verify your suspicions?

A.  Network-based firewall logs

B.  Host-based firewall logs

C.  Operating system logs

D.  System security logs

11.  Your organization is updating its security policy. Management indicated that they want to address best practices associated with audit logs. Of the following choices, which ones are recommended best practices with audit logs? (Select all that apply.)

A.  Review the logs regularly

B.  Archive logs for later review

C.  Periodically overwrite logs

D.  Store logs on remote servers

12.  What is the purpose of reviewing logs?

A.  Detecting potential security events

B.  Preventing potential security events

C.  Correcting potential security events

D.  Deterring potential security events

13.  Security professionals within your organization recently completed a security audit. Which of the following are valid steps to take after the audit is complete? (Select three.)

A.  Evaluate controls

B.  Approve changes

C.  Implement fixes

D.  Delete the security audit

14.  An organization handles credit card data from customers on a regular basis. What provides the security objectives and requirements that the organization must follow?

A.  PCI DSS

B.  HIPAA

C.  FIPS Pub 200

D.  NIST SP 800-53

15.  A badge reader records employee names, dates, and times when employees enter and exit a secure server room. An auditor reviewed the logs and noticed that they showed that many employees entered the room, but the logs do not show when all the employees exited the room. What does this indicate?

A.  The badge reader is operational

B.  Tailgating

C.  The mantrap is not being used

D.  Unauthorized entry

16.  Who would measure the effectiveness of an organization’s security controls?

A.  An administrator

B.  A manager

C.  An auditor

D.  A data owner

17.  Of the following choices, what is a primary method used for configuration control?

A.  Baseline

B.  Change management requests

C.  Security logs

D.  Password audits

18.  Which of the following are valid methods used for configuration control? (Select three.)

A.  Imaging

B.  Microsoft’s Group Policy

C.  Change management

D.  Proxy server logs

19.  Of the following choices, what helps prevent unintended outages caused by system modifications?

A.  Security audit

B.  Change management

C.  Configuration control

D.  Audit trail

20.  Application developers are currently testing a new application that salespeople can use while traveling. The application works when it’s tested in the internal network, but not when testers attempt to use it by connecting to the internal network via the Internet. Developers recommend a firewall modification to resolve this issue. Which of the following will evaluate potential security impacts from this modification?

A.  Configuration management processes

B.  Vulnerability assessment

C.  Firewall logs

D.  Change management processes

Answers

1.  C. Authentication, authorization, and accounting (AAA) provide accountability, and logging provides the accounting element. Although AAA increases security, it does not guarantee security. Change management prevents unintended outages from unauthorized changes. Configuration control ensures systems are deployed with a secure baseline and maintain approved configuration settings for system stability.

2.  D. A clipping level uses a predetermined level as a threshold. A classic example is three or five logon failures in a short period, such as within 30 minutes. Although many operating systems use account lockout policies to lock the account after a predetermined level, the question doesn’t ask what happens to the account, but instead asks what the accounting system is using to ignore the first two logon failures and only generate the alert after three logon failures. A password policy ensures that users have strong passwords and change them regularly. Snipping level isn’t a valid term associated with accounting systems.

3.  B. Clipping levels ignore normal user errors, but generate alerts when these errors exceed a predetermined threshold. Clipping levels are not associated with baselines. It is possible to configure an audit trail without clipping levels, but if clipping levels exist, the audit trail does not ignore them. Clipping levels do not generate alerts when they detect any potential errors or security violations, but instead only generate alerts when they detect the number of events has exceeded a predetermined threshold.

4.  B. An account lockout policy locks out an account after a predetermined number of failed logins. The password policy ensures that users create strong passwords and change them often. The account lockout policy is using a clipping level by ignoring failed login attempts until it detects a preset threshold, but the clipping level doesn’t lock the account. An audit trail is one or more logs used to reconstruct events leading up to and occurring during an incident.

5.  D. An audit trail is one or more logs that can re-create events leading up to and occurring during an incident. Configuration control helps ensure that systems are configured in a secure manner. A change management program allows stakeholders to request changes and helps reduce unintended outages from unauthorized changes. A security audit examines an organization’s policies and procedures to determine whether the organization follows these policies and procedures.

6.  C. An audit trail is a technical detective control, because it uses technology and can detect incidents after they occur. A preventive control attempts to prevent incidents. A corrective control attempts to reverse the impact of an incident after it has occurred. A physical access control is an item that you can physically touch.

7.  B. The Security log records auditable events, such as when a user accesses or deletes a file (if resource auditing is enabled). The System log records system events such as when a service stops or starts. The Application log records application events. The Forwarded Events log shows events forwarded from other systems as part of an event subscription.

8.  C. A security log records auditable events related to resources, such as when a user reads, modifies, or deletes a file. Firewall and proxy server logs are not operating system logs. A system log would record events such as when a service stops or starts, but not security events.

9.  A. A proxy server log can serve as a deterrent for internal employees. If employees know that the server is monitoring and logging their activity, they may be less likely to engage in activity that violates the security policy. A network firewall log can capture activity for traffic to and from the Internet but does not provide much of a deterrent for internal employees. A security audit is not a log. A change management log documents changes for a system.

10.  A. Network-based firewall logs record traffic on the network, and because many systems are involved, network-based firewall logs is the best choice. Each of the other logs are local logs on individual systems. This would require checking logs on multiple systems, rather than checking logs on a single network-based firewall.

11.  A, B, D. Reviewing the logs, archiving the logs, and storing logs on remote servers are recommended strategies to retain the integrity of audit logs. If you periodically overwrite the logs without first archiving them, it’s possible to overwrite log entries, erasing them forever.

12.  A. Security professionals and auditors can detect potential security events by reviewing logs after the event has occurred. Reviewing the logs doesn’t prevent an incident that has already occurred and reviewing the logs does not enable security professionals and auditors to correct the effects of an incident. While logging some activity, such as proxy servers, can deter events, reviewing the logs doesn’t deter the activity.

13.  A, B, C. A security audit often recommends changes in the form of additional security controls. Personnel evaluate the recommended controls, management approves changes, and personnel then implement the fixes. It isn’t appropriate to delete the audit after it has been completed.

14.  A. The Payment Card Industry Data Security Standard (PCI DSS) provides 6 control objectives and 12 supporting requirements that organizations must follow if they process credit card payments from customers. The Health Insurance Portability and Accountability Act (HIPAA) covers organizations handling health- and medical-related data. Federal Information Processing Standard Publication 200 (FIPS Pub 200) identifies standards required by federal agencies. NIST SP 800-53r4 provides information on recommended security controls.

15.  B. Logs that include entries showing employees entered a secure area but do not include entries showing they exited indicate tailgating is occurring. Some employees are using their credentials to exit (and the logs show them exiting), but other employees are following closely behind these employees without showing their credentials (and the log doesn’t include entries for these employees). While it is possible the badge reader has a problem, it is recording some employees exiting, so this isn’t the most likely cause. Mantraps prevent tailgating, and if a mantrap is in use, employees would be forced to use it. There isn’t any indication of unauthorized entry.

16.  C. An auditor would measure the effectiveness of a security control. An internal auditor might have other roles, such as an administrator, a manager, or a data owner. However, when measuring the effectiveness of security controls, they are acting as an auditor.

17.  A. A baseline is a primary method used for configuration control and it ensures that systems start in a known state. Automated or manual processes periodically examine the systems to verify the system still has the same configuration settings from the baseline. An organization doesn’t approve and implement all change management requests, so examining the requests does not give an accurate representation of the server configuration. Security logs and password audits aren’t typically used for configuration control.

18.  A, B, C. Imaging, Microsoft’s Group Policy, and change management processes are all used for configuration control. Proxy server logs are often used for auditing, but not for configuration control.

19.  B. A change management program allows stakeholders to request changes and helps reduce unintended outages from unauthorized changes. A security audit examines an organization’s policies and procedures to determine whether those who work in the organization follow these policies and procedures. Configuration control helps ensure that systems are configured in a secure manner and similarly to each other. An audit trail is one or more logs that can re-create events leading up to and occurring during an incident.

20.  D. Change management processes evaluate recommended modifications and changes and can identify potential security impacts from a change. Configuration management processes help ensure systems are configured consistently. A vulnerability assessment evaluates a system or network for weaknesses. Firewall logs can show activity, but they won’t evaluate potential changes.