Introduction
For years I have been educating auditors, security professionals, and administrators how to correctly audit a Windows environment. Every time I enter a location I am bombarded with the fact that they need to ensure that the SOX (Sarbanes-Oxley Act) and PCI (Payment Card Industry) compliance controls are also reviewed is getting rather old. The reason it is getting old is the fact that SOX and PCI are not very good security related regulations. In fact, this authors opinion is that both of these regulations should stop even mentioning that they in any way ensure that the Windows environment is secure with the controls that they “suggest” be checked. I am not saying that these compliance regulations don’t have their place in the industry. I just feel that to include any statement that they are checking for security of Windows servers or Active Directory is completely missing the mark.
Compliance Regulations and Controls
If you do any research on the Internet at even the slightest level regarding the validity of compliance regulations, you will find a plethora of comments that say that the effectiveness of the compliance regulations are just the “surface” of security of the systems that they are evaluating. In reality, checking just one or two security controls for a compliance regulation, group membership and password policies for example, are only the tip of the iceberg when it comes to true security auditing.
There are many other issues with compliance regulations, especially the top two, SOX and PCI. After being in so many organizations where they are “afraid” of these regulations, I have obtained a keen sense of what these regulations are all about. The regulations are all about focusing on the computers that house the financials, for SOX, and credit card transactions and information, for PCI. From an outsiders point of view, that makes 100% logical sense. From a computer network standpoint, that is as silly as focusing on just the Whitehouse in order to protect the president.
It should be, but seems to not be, clear (CRYSTAL CLEAR as one great actor said) that more than just the servers that house the financial and credit card data need to be evaluated. Sure, some domain controllers for Active Directory are checked, but again, these servers are typically more secure than even the financial and credit card servers.
Another key dysfunction of compliance regulations is the concept of sampling. I understand that when statistics are put in place over a set of objects, that sampling should give you a pretty clear indication of the population. Well, when it comes to the concepts of servers, security, corporations, IT, administrators, etc… those rules have proven to be somewhat missing the mark. Ok, I have found that a sampling of 20 to 30 servers is about as worthless as picking just one server out of the population! The more servers in the sample will bear much better fruit when it comes to computer security.
Security
Well, I will say that a security approach to auditing servers is radically different than the compliance method. Security methods don’t really look at compliance at all, as security is concerned about all high risk points of ingress into a computer. Compliance suggests that the high risk security controls are considered, but based on the controls that are evaluated, I find that the list is missing a majority of the controls.
Security looks at all important aspects of how a computer can be accessed, attacked, and compromised. The following is a good example of areas that security is concerned about, where compliance is not:
- User Rights
- ALL “default privileged group” membership
- Local Administrators group membership
- Authentication protocols
- Anonymous access
- DNS configurations
- Workgroup vs Domain affiliation
- Active Directory delegation
- Group Policy delegation
- User controls
- Administrator controls
There are more, but this gives you an idea that the security aspects of a server far outweigh those of compliance.
Merging Compliance and Security
As a consultant that deals with auditing of Windows networks as well as the administration of Windows networks (both including Active Directory), I must come up with solutions that meet both the internal auditors (really the company as a whole) needs and the reality that security controls in general must be evaluated.
In order to do this I usually create a master list of security controls up front. From this list, we will first check off the security controls that the company must check for their compliance regulations. Usually this list of checks is less than 5!
If there are any security controls that are not on my list, we add those. Yes, there are usually one or two of these. What are these? Well, these are usually not physical/logical controls, but process controls. I find that the “interpretation” of compliance regulations is so wide spread, that each company has their own list of process controls. This might include the following:
- Use of administrative privileges on any computer by anyone (rather vague!)
- Method to request and approve changes to membership to privileged groups (usually only those groups related to financials and credit cards)
- Method and policy to disable and purge users that leave the company
- Policy for creating new users, adding them to groups, creating initial password, providing them with the new password, and changing of password on first use.
Yes, these are important! However, I find that each company has their own way of writing these and checking them, so I leave it up to each company to fill in the blanks for each of the process oriented controls.
Next, we will discuss the overall security management in the organization. We will talk about how IT does business, how Active Directory is managed, the size of Active Directory, number of domains, number of forests, etc. From this we can then begin to evaluate the scope of the audit and tie that the time/resources that are available for the audit. If there is only a single domain, for example, we can choose more servers and more settings compared to an Active Directory infrastructure that has 3 domains.
Now that we have our scope, we can start to evaluate how many servers, domain controllers, and security controls to choose. It is always my suggestion to choose more servers for the high risk security controls as this will indicate the overall consistency of the server configurations. In essence, if the high risk security controls are not consistent across servers, chances are very good that the other security controls are not consistent either.
Summary
We should never ignore compliance as a measuring stick in our audits. I would never suggest that. However, we should never state that compliance checks are a good measure of security for our servers! If we want to ensure good security, we must not only include compliance, but also security controls. There is a difference, a rather huge difference. Compliance is an industry driven “general list” of controls. Security controls are based on historical data that have proven to be ways for an attacker to gain access to a server, network, or Active Directory domain. It is this level of security auditing that we must be at in order to really feel comfortable that our networks are secure.
