PCI – Going Beyond the Standard: Part 8, Configuration Standards

A consistent theme in all of my blogs is that security must be simple to be effective, and the configuration of your systems (both device and application) is no exception. Just as Role Based Access Control (RBAC) is the established norm for access control, and event base-lining is the only way monitoring of log files can be automated, the configuration standards of ALL systems must be able to reduce their functionality to only that required.

Clearly the PCI DSS was written for Windows OS, as Windows is by far the worst in terms of having to remove unnecessary functionality from a base installation. As opposed to adding in the function you need, like in ‘mainframes’ for example. However, every configuration should be based on the same premise, follow the same format, and effect the same results.

The most common error is that configuration standard, or hardening guides, are one per operating system, one per application and so on. Instead, standards should be at the operating system / FUNCTION level, as function will ultimately be different for each systems’ business purpose. For example, the configuration of a Windows 2008 web server, will be significantly different from a Windows 2008 Database server,  even at the base operating system level.

Clearly your configuration standards for operating systems will be very different from those for network devices, and both in turn are very different from an application configuration, but the premise is the same. EVERY system, regardless of type, should have its own baseline configuration standard.

Taking a Windows web server as my start-to-finish example, here are the steps;

  1. Determine whether or not you have the necessary skill-set in-house to design and implement the relevant configuration / hardening guide – Just because you have someone who can take a config standard from the Internet, effect some of the recommendations, and put your logo on the resulting paperwork does NOT make a decent or effective standard. You wouldn’t read a manual on hang gliding and jump off a cliff without talking to a professional first would you?
  2. Find the most appropriate guidance on which to build your operating system baseline – Assuming you do have an expert in-house, they will most likely be basing their hardening guides on freely available and open source best-practice guides like: Windows Server 2008 Security Baseline or CIS Microsoft Windows Server 2008 Benchmark. These will then be suitably tweaked to produce a baseline relevant to EVERY system function; from web server, to application server, to database server and so on. This will be the baseline image for all Windows 2008 installations.
  3. From the above baseline image there will then be function-specific operating system tweaks – which will then form as many configuration standards as there are required system functions. These baseline images will be used for EVERY installation of ‘like’ systems. The last two pages of these documents will be a netstat of listening services, and a complete listing of all running services. Both of these lists will have a business justification next to every entry.
  4. Next comes the installation of the systems’ function – which will result in a ‘delta’ between the baseline services / listening ports and the running services / listening ports. This delta will naturally correspond to the installed apps, and will again result in two more lists of listening ports and running services, both with their documented business justifications.
  5. Standards now become part of a life cycle of continuous improvement – No document in security stays the same, not even policies, and standards like hardening guides should be a large part of the effort within the Vulnerability Management process. The threat landscape changes every day, configuration standards / hardening guides need to adapt, as does the appropriate patching effort to existing systems.

So, in theory, what you’re left with is 4 distinct documents for every server in your environment:

  1. Baseline for all servers of an operating system type (e.g. ‘Windows 2008 Configuration Standard’)
  2. Baseline for all servers of an operating system function (e.g. ‘Windows 2008 Web Server Configuration Standard’)
  3. Baseline for all servers of an operating system / application function (e.g. ‘Windows 2008 IIS Server Configuration Standard’)
  4. Baseline for each individual system (e.g. ‘IIS Server [hostname] Configuration Standard’)

The beginning of document 3. will usually just point to 1. and 2., and the beginning of document 2. will point to 1, and so on, but there is nothing wrong with having everything is every document.

The part that is never done well (or at all) in my experience is the 4th one; a baseline standard for every individual system. This is a shame, as nothing can provide a better foundation for not only your security efforts, but the VALIDATION of those efforts. Show your PCI assessor (for example) a documented configuration standard with every service / port justified next to the netstat / screenshot from the actual system and you have met the vast majority of DSS Requirement 2.

Now image if your system baselines were part of your Asset Management and you could automate the comparison of the know-goods and running configs on a daily basis  AND alert on exceptions?

What you now have is part of Continuous Compliance Validation, and you are truly in the realms of REAL security.

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.