Automating IT Security Policy Compliance
The one thing that computers are good at is repetition. They can do the same task repeatedly and always give the same result. Conversely, people aren’t so good at repetitious tasks. Ask an administrator to change the same setting on 100 different computers and it’s very possible that one or more of the computers will not be configured correctly. Additionally, automated tasks take less labor and ultimately cost less money. For example, a task that takes 15 minutes to complete and needs to be done 100 times will take 25 labor hours (15 × 100/60). If an administrator took 2 hours to write and schedule a script, it results in a savings of 23 labor hours. Depending on how much your administrators are paid, the savings can be significant.
Many security tasks can also be accomplished with dedicated tools. For example, the “Automated Systems” section earlier in this chapter lists several different tools with a short description of some of their capabilities. However, if you plan to automate any tasks related to IT security policy compliance, you should address some basic concerns. These include:
- Automated policy distribution
- Configuration and change management
Technical TIP
Open source configuration management software has become widely available and accepted in many organizations. Many of the open source solutions support newer technologies such as integrating with cloud providers. For example, a product named Chef offers configuration management for network nodes either on premises or in the cloud.
Automated Policy Distribution
Earlier in this chapter, imaging was described as a method to start all computers with a known baseline. This is certainly an effective way to create baselines. However, after the deployment of the baseline, how do you ensure that systems stay up to date? For example, you could deploy an image to a system on July 1. On July 15, the organization approves a change. You can modify the image for new systems, but how do you implement the change on the system that received the image on July 1, as well as on the other existing systems? Additionally, if you didn’t start with an image as a baseline, how do you apply these security settings to all the systems on the network?
The automated methods you use are dependent on the operating systems in the organization. If the organization uses Microsoft products, you have several technologies you can use. Some, such as SMS and SCCM, were mentioned previously. Another tool is Group Policy.
Group Policy is available in Microsoft domains. It can increase security for certain users or departments in your organization. You could first apply a baseline to all the systems with an image. You would then use Group Policy to close any security gaps or increase security settings for some users or computers. This method can also ensure regulatory and standards compliance such as with those controls required to protect credit cards under the Payment Card Industry Data Security Standard (PCI DSS).
Consider FIGURE 15-2 as an example. The organization name is ABC Corp and the domain name is ABCCorp.int. The Secure Password Policy is linked to the domain level to require secure passwords for all users in the domain. The organization could define a password policy requiring all users to have strong passwords of at least six characters. If the organization later decides it wants to change this to a more secure eight-character policy, an administrator could change the Secure Password Policy once and then it would apply to all users in the domain. It doesn’t matter if there are 50 or 50,000 users—a single change applies to all equally.
FIGURE 15-2 Using Group Policy in a Microsoft domain.
All the PCI DSS server objects are placed in the PCI Servers organizational unit (OU). A policy named PCI DSS Lock Down Policy is linked to this OU. It configures specific settings to ensure these servers are in compliance with PCI DSS requirements.
TIP
Figure15-2 represents a simplistic view of Group Policy in a Microsoft domain. It doesn’t show the Default Domain or the Default Domain Controllers policies that are both created by default and add basic security to a domain. Additionally, an organization will likely have more than just three organizational units (OUs).
Human resources (HR) personnel handle health data covered by the Health Insurance Portability and Accountability Act (HIPAA). These users and computers can be placed in the HR OU. The HIPAA Compliance Policy includes Group Policy settings to enforce HIPAA requirements. For example, it could include a script that includes a logon screen reminding users of HIPAA compliance requirements and penalties.
The figure also shows a research and development OU, named RnD OU, for that area. Users and computers in the research and development department would be placed in the RnD OU. The RnD policy could include extra security settings to protect data created by the RnD department.
Group Policy not only configures the changes when systems power on, but also provides automatic auditing and updating. Systems query the domain every 90 to 120 minutes by default. Any Group Policy changes are applied to affected systems within two hours. Additionally, systems will retrieve and apply security settings from Group Policy every 16 hours even if there are no changes.
Training Administrators and Users
These tools and technologies aren’t always easy to understand. They include a rich set of capabilities that require a deep understanding before they can be used effectively. It takes time and money to train administrators and users how to get the most out of these tools.
Training should be considered when evaluating tools. Determine if training is available and its cost. Almost all the companies that sell these tools also sell training. You can send administrators to train at a vendor location. If you have enough employees who require training, you can conduct it on-site.
The important point to remember is that even the most “valuable” tool is of no value if it’s not used.
Organizational Acceptance
Organizational acceptance is also an important consideration. Resistance to change can be a powerful block in many organizations. If the method you’re using represents a significant change, it may be difficult for some personnel to accept. As an example, using a baseline of security settings can cause problems. Applications that worked previously may no longer work. Websites that were accessible may no longer be. There are usually work-around steps that will resolve the problem, but it will take additional time and effort.
NOTE
Automated solutions providing configuration management must be well protected. By their nature, these solutions require administrator authority across any device they manage. Consequently, any hacker who gets into a configuration management system might then gain administrator access to your production environment.
To illustrate, assume that a baseline is being tested for deployment. Administrators in one department determine that the baseline settings prevent an application from working. There are three methods for resolving the problem. First, the administrators could weaken security by not using the baseline settings; however, weakening security is not a good option. Second, the department may decide it can no longer use the application. If the application is critical to its mission, this may not be a good option. Third, a work-around method can be identified that doesn’t bypass the original baseline settings, but also allows the application to work. The third option will require digging in to resolve the problem. If the administrators are already overburdened, or don’t have the knowledge or ability to resolve the problem, they may push back. This requires a climate of collaboration to address the problem.
Vulnerability scanning is a common tool and part of normal security operations. Ideally, it quickly and routinely identifies vulnerabilities to be fixed. Penetration testing takes that capability to the next level. A penetration test is designed to actually exploit weaknesses in the system architecture or computing environment. Typically, a penetration test involves a team pretending to be hackers, using vulnerability scanners, social engineering, and other techniques to try to hack the network or system.
Testing for Effectiveness
Not all automated tools work the same. Before investing too much time and energy into any single tool, it’s worthwhile testing them to determine their effectiveness. Some of the common things to look for in a tool include:
- Accurate identification—Can the tool accurately identify systems? Does it know the difference between a Microsoft server running Internet Information Services (IIS) and a Linux system running Apache, for example?
- Assessment capabilities—Does it scan for common known vulnerabilities? For example, can it detect weak or blank passwords for accounts?
- Discovery—Can the system accurately discover systems on the network? Can it discover both wired and wireless systems?
- False positives—Does it report problems that aren’t there? For example, does it report that a patch has not been applied when it has?
- False negatives—Does it miss problems that exist? In other words, if a system is missing a patch, can the tool detect it?
- Resolution capabilities—Can the tool resolve the problem, or at least identify how it can be resolved? Some tools can automatically correct the vulnerability. Other tools provide directions or links to point you in the right direction.
- Performance—The speed of the scans is important, especially in large organizations. How long does the scan of a single system take? How long will it take to scan your entire network?
Audit Trails
If a tool makes any changes on the network, it’s important that these changes are recorded. Changes are recorded in change management logs that create an audit trail. The tool making the change can record changes it makes on any systems; however, it’s common for logs to be maintained for individual systems being changed, separate from the change management log.
Logs can be maintained on the system or off-system. The value in having off-system logs is that if the system is attacked or fails, the logs are still available. Additionally, some legal and regulatory requirements dictate that logs be maintained off-system.
Audit trails are especially useful for identifying unauthorized changes. Auditing logs the details of different events. This includes who, what, where, when, and how. If a user made a change, for example, the audit log would record who the user was, what the user changed, when the change occurred, and how it was done.
Imagine a security baseline is deployed in the organization. You discover that one system is regularly being reconfigured. The security tool fixes it, but the next scan shows it’s been changed again. You may want to know who is making this change. If auditing is enabled, it will record the details. You only need to view the audit trail to determine what is going on.
TIP
Some auditing is enabled by default on systems. However, you may need to enable additional auditing to determine details on specific events.
Configuration Management and Change Control Management
The Information Technology Infrastructure Library (ITIL) includes five books that represent the ITIL life cycle, as shown in FIGURE 15-3. A central part of ITIL is Service Transition. This relates to the transition of services into production. It includes configuration management and change management.
FIGURE 15-3 The ITIL life cycle.
ITIL isn’t an all-or-nothing approach. Organizations often adopt portions of ITIL practices without adopting others. Configuration management and change management are two elements within the Service Transition stage that many organizations do adopt.
Configuration management (CM) establishes and maintains configuration information on systems throughout their life cycle. This includes the initial configuration established in the baseline. It also includes recording changes. The initial public draft of NIST SP 800-128 defines CM as a collection of activities. These activities focus on establishing the integrity of the systems by controlling the processes that affect their configurations. It starts with the baseline configuration. CM then controls the process of changing and monitoring configuration throughout the system’s lifetime.
Change management is a formal process that controls changes to systems. One of the common problems with changes in many organizations is that they cause outages. When an unauthorized change is completed on one system, it can negatively affect another system. These changes aren’t done to cause problems. Instead, well-meaning technicians make a change to solve a smaller problem and unintentionally create bigger problems. Successful change management ensures changes have minimal impact on operations. In other words, change management ensures that a change to one system does not take down another system.
Change management is also important to use with basic security activities such as patching systems. Consider for a moment what the worst possible result of a patch might be. Although patches are intended to solve problems, they occasionally cause problems. The worst-case scenario is when a patch breaks a system. After the patch is applied, the system no longer boots into the operating system.
If a patch broke your home computer, it would be inconvenient; however, if a patch broke 500 systems in an organization, it could be catastrophic. Patches need to be tested and approved before they are applied. Many organizations use a change management process before patching systems.
NOTE
It’s important that change management be tied to an external process such as emergency fixes, often referred to as firecall systems. A firecall system allows for quick access to fix an issue. For example, if a website is down, an emergency ticket may be opened in a firecall system to grant access to the server hosting the website.
Configuration Management Database
A configuration management database (CMDB) holds the configuration information for systems throughout a system’s life cycle. The goal is to identify the accurate configuration of any system at any moment.
The CMDB holds all the configuration settings, not just the security settings. However, this still applies to security. The security triad includes confidentiality, integrity, and availability. Many of the configuration settings ensure the system operates correctly. A wrongly configured system may fail, resulting in loss of availability.
NOTE
NIST SP 800-128, “Guide for Security Configuration Management of Information Systems,” covers configuration management in much more depth.
Tracking, Monitoring, and Reporting Configuration Changes
Many organizations use a formal process for change requests. It’s not just a technician asking a supervisor if he or she can make a change. For example, a web application could be used to submit changes. Administrators or technicians submit the request via an internal webpage. The webpage would collect all the details of the change and record them in the change control work order database. Details may include the system, the actual change, justification, and the submitter.
Key players in the organization review the change requests and provide input using the same intranet web application. These key players may include senior IT experts, security experts, management personnel, and disaster recovery experts. Each will examine the change as it relates to his or her area of expertise and determine if it will result in a negative impact. If all the experts agree to the change, it’s approved.
NOTE
Change management reviews must also consider regulatory and compliance matters. Implementing a change could result in compliance violations. For example, suppose an organization makes a change on how the network is segmented. If this change resulted in credit card systems no longer being segmented, then the change might result in a PCI DSS violation.
Collaboration and Policy Compliance Across Business Areas
It’s always important for different elements of a business to get along. One element of the business should not make changes without any thought to how it may affect other areas. Collaboration is also important within IT and security policy compliance.
Some security policies must apply to all business areas equally. However, other policies can be targeted to specific departments. If you look back to Figure15-2, this shows an excellent example of how different requirements are addressed within a Microsoft domain. Group Policy applies some settings to all business areas equally. Additionally, it can configure different settings for different departments or business areas if needed.
In Figure 15-2, different policies were required for PCI DSS servers, HR personnel, and research and development personnel. Each of these business areas has its own settings that don’t interfere with the other units.
No matter how hard you try to communicate through the approval process, inevitably some miscommunication will occur. Someone will be caught off guard by a change, or two changes will conflict. You might find multiple changes need to be backed out, but the resources are not available as expected to perform the recovery. Or the miscommunication will occur because the full scope of the change was not fully understood.
There’s no magic formula to solving all these problems. A good rule of thumb is to overcommunicate and build change into a predictable schedule and set of resources. For example, maybe routine (noncritical) patches are always applied the first Saturday of every month. Create a SharePoint site to house the descriptions of the changes. Commit to having descriptions of the changes available the week prior. Send reminder emails to both approvers and stakeholders. In short, be transparent and make a best effort to communicate accurately and often. This provides every opportunity for stakeholders to be engaged and offer comment.
Version Control for Policy Implementation Guidelines and Compliance
Another consideration related to automating IT security policy compliance is version control. First, it’s important to use version control for the security policy itself. In other words, if the security policy is changed, the document should record the change. A reader should be able to determine if changes have occurred since the policy was originally released, with an idea of what those changes were.
Version control requirements for a document can be as simple as including a version control page. The page identifies all the changes made to the original in a table format. It would often include the date and other details of the change. It may also include who made the change.
It’s also important to record the actual changes to systems. However, these changes are also recorded in the change control work order database and the CMDB discussed in the previous section.