Time to put some meat on the bones of this How-To. Writing a configuration standard doesn't have to be a nightmare, if you follow some straight forward structure.
Document Control !
First off - apply some sensible document controls - this is of particular importance if your documentation is going to reside in word / excel documents and have to be controlled manually. If you are using a SharePoint or wiki to host the documentation you can automate this. This should contain the following details :-
Author - name and contact details
Document version and version history - its common to have three fields
Version - Update reason / revision notes - Date
Revision period - with a reference to the revision owner as necessary ( it may be different from the original author)
Introduction
Write a brief introduction to the config standard, explain why the standard exists and why it must be followed -
Scope
Detail which assets the standard is intended to be applied to e.g. all Windows 2008 servers, or Windows 2008 servers in the card-holder data environment "CDE". If this is going to be used for PCI DSS compliant assets now is a good time to make reference to the industry standard hardening approach you are using (SANS, NIST, CIS etc) and also make a reference to your exceptions appendix, discussed later.
Implementation Instructions
If you have an existing build guide or base install you might wish to reference it here. Otherwise its common for this to be a step by step procedure so that it can followed by anyone - very handy in a DR scenario.
PCI DSS - requirement reference - 2.1
For a PCI DSS relevant system you should ensure that your implementation instructions mandate the changing of vendor-supplied defaults before it goes onto "the network". PCI DSS lists out some simple example such as SNMP community string, removal of unnecessary accounts etc. If you are following something such as CIS benchmark for Windows you will get all this covered.
If the asset in question comes with a default password - this should also be changed. Default passwords can easily be found on sites like http://cirt.net/passwords.
PCI DSS - requirement reference - 2.2.1.
To meet 2.2.1 the standard requires that you implement one primary function per server this applies to physical and virtual environments - where in a virtual environment the hypervisor's sole function is to be a hypervisor, and each guest system has is own primary function. The one primary function can often be seen as a stack. I've often seen people get hung up on breaking out n-tier applications on to multiple bits of hardware for no real security benefit. If the tiers are so closely coupled that a breach in any one tier would be a breach of another - then the "function" of those tiers is to support the application. That would be the primary function, and they can sit on one box. The PCI SSC have repeatedly answered this to clients I've worked with when asked.
PCI DSS - requirement reference - 2.2.2
Your configuration standard should say that only the required services, protocols are to be enabled. This is the foundation of a hardened build. Mandatory!
PCI DSS - requirement reference - 2.2.3
This particular requirement requires that common security settings are documented in the configuration standard. The vagueness of this requirements wording doesn't help us implement it much but the intention is that the config document details the specific settings.
One sensible way of covering this is to reference the implementation of your chosen industry standard, lets say CIS, and then put an appendix at the back of the standard to detail which settings have not been applied and why. Simple!
PCI DSS - requirement reference - 2.2.4
Dealing with 2.2.4 is the half of 2.2.2 really. In 2.2.2 we are to enable just the required services, protocols, daemons etc. For 2.2.4 we're being asked to remove what we've disabled, as well as unnecessary scripts, drivers, functionality etc.. In a windows environment this isn't as difficult as it seems. Have a look at this article on technet on use of the sc.exe tool.
PCI DSS - requirement reference - 2.3
Whilst 2.3 doesn't relate directly to the config standard document, it makes sense to ensure that the need to have none console access encrypted is documented and made mandatory.
In the rest of the implementation instructions it is useful to add in the details from, or refer to other documents that cover any of the following, host-based firewall / IDS config, Antivirus settings, specific log/audit settings, any encryption implemented, file integrity monitoring settings.
To finish up with, its important that these config documents are kept up to date (your QSA will ask!). It helps to integrate these updates with the change control process you operate but if you are implementing them just for PCI DSS then you will have to update them if you find vulnerabilities that need to be addressed.
No comments:
Post a Comment