Saturday, March 1, 2014

Compliance vs Security in Windows Server

In today's world security, compliance and process efficiency are indispensable for a business. Every business public or private realizes the need to create an environment that is compliant with Security and Auditing Requirements by continuous monitoring and tracking. This is with the objective to satisfy
·         Shareholders, Government bodies and Other internal security concerns.
IT Managers are designated critical roles to ascertain necessary compliance requirements are met and to ensure that every constituent in the network is functioning smoothly by continuously monitoring them.

Compliance Regulations and Controls
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, We 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 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. Well, when it comes to the concepts of servers, security, corporations, IT, administrators, etc… those rules have proven to be somewhat missing the mark. 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.


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), In order to do this usually create a master list of security controls up front. From this list, 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 list, 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 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, each company has their own way of writing these and checking them.
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.


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.

No comments:

Post a Comment