PCI DSS - How to - Configuration Standards - Part 2

Configuration Standards Part 2


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.  

PCI DSS - How to - Configuration Standards - Part 1

Writing good configuration standards is an important job for any IT team.  Everybody needs to know how that box was built and a good configuration standard can help you piece the information together at a time of need.  Like the time you are on call, and someone is shouting at you down the phone line.  Its also great place to document all the hardening / security config that has been done and how everything has been locked down.  This is useful for patch management.  Patching services that have been disabled or removed in most cases doesn't warrant the reboot!


However - if experience has taught me anything it is that almost everyone hates doing writing technical documentation, especially retrospectively.  So if you are retro documenting a build I do feel for you.


However!  There are compliance brownie points for you in the PCI DSS world if you have good configuration standards.  The PCI DSS expects a build that shows the system to have been hardened consistent with "industry standards", such as Centre for Internet Security (http://www.cisecurity.org/), NIST (http://www.nist.gov/index.html) or SANs (www.sans.org).


My personal favourites have always been the CIS docs, I just prefer the way they are written.  They detail everything in a fairly linear manner as well as explain what the changes you are making actually do.  Have a look on those sites and you'll get a good feel for what is required to lock down a device if you are relatively new to this. 


The next few blog posts will be about the content needed in these config documents in order to a) satisfy the PCI requirements and b) Still be useful.  
I'll not go into the details of how you store/manage them, you can do these in Word/Excel/pdf or make use of a wiki (good if you have an environment that changes frequently).


Part two - here - 

Breach Disclosure @AthCon

After being fortunate enough to have my presentation on breach disclosure selected by the AthCon CFP panel I had a fun trip over to Athens last week!
AthCon (http://www.athcon.org/) is in its third year now and it was great to see such a large attendance despite all the talk of economic turmoil in Greece.  Arduino printed circuit boards were the badges, and one of the sponsors even hacked one together by the end of the conference to run a small version of the game Simon.

So what was I doing there?  Most of the presentations were significantly more technical than mine, discussing subjects such as the one by finux on IDS evasion techniques, iOS hacking, rootkits etc.  Ian Glover from Crest spoke about the need for standardised professionalism in the security testing industry and I found myself completely agreeing with what he said.  I was there to talk about breach disclosure.  Not reporting vulnerabilities, not putting out a security advisory.  But how I think we should be thinking about security breaches.

Having seen a number of breaches as an auditor and QSA, I've seen first hand lots of bad responses.  Also I've seen businesses be reluctant to communicate about events occurring for fear of damage to their reputation  So some of what I had to say is about thinking about the problem differently, thinking about it from the consumers perspective.
The idea behind my presentation was really inspired by a conversation or rather a set of questions that were raised at the PCI community event in London.  On of my old colleagues was there and we were chatting about his new role, and when the microphones went open one of his new colleagues stood up and made a really good point to Visa and the SSC.  Which was basically, "Why aren't all the payment card breaches made public?" - there was a lot of mumbling about NDA's and reputation and it not being appropriate.  However I couldn't help think that he'd made a really good point.  Would it really hurt if the details from a breach were made public (even anonymously) so that everyone could see what happened and learn from it?  This made me think, in the infosec community we are really good at finding vulnerabilities, exploiting them telling people what could happen, but we're not really great at telling them how likely they are to be attacked, or how likely they are to be breached.  This in my experience leads to difficult discussion when dealing with senior executives that perhaps don't really understand the threats out there or that want things quantifying consistently with other risks.

So I started putting together some examples of how other industries do this, primarily the healthcare industry, the police, and nuclear energy industry.  These industries all seem better at sharing information than the infosec industry in order to quantify risk.  The UK Health and Safety executive have even gone to the trouble of writing a document called the tolerability of risk from nuclear power stations available here.  This puts in layman terms the risk of death from a number of causes (e.g. cancer, 1/374 people).  The thing that really interested me though was that human life as an asset had been assigned a monetary value.  Without getting into the morality of this, I actually thought this seemed like a good idea (for reference its £600,000 in the UK).  As this can be used by insurers to help quantify values in the event of various incidents.

Valuing Information Assets
This then lead me on to one of the other problematic areas when dealing with information security.  How do we value information assets?  This could end up being hugely subjective dependent on the type of business one is in or the type of information.  Lets look at personal information such as a name and address.  Whilst this has some inherent value to both businesses and fraudsters, its also not to difficult to obtain legitimately.  Whereas banking information, medical records and other data that the UK-DPA would consider sensitive is not.
One of the things I suggest in my presentation is that we should look to or even lobby our regulators to give some absolute minimum values for these assets.  They legislate for them and can fine people, so it doesn't feel unreasonable that they should give them a formal minimum value.  E.g. for simple maths sake - if we look at someone's name and address and gave it an arbitrary value of 1p but gave their medical record a value of £10 we can infer that the medical data is significantly more valuable/sensitive.  We can also then start to look at  whether we can put security expectations around certain values of data.  e.g. do we really care if someone loses a couple of names and addresses on a piece of paper - maybe not.  We valued the data at 2p and protected it accordingly.  However the same data is now sensitive, would someone leave a £20 note unattended on a train.  Probably not.  The ICO could set some sensible thresholds around what is acceptable to lose and what isn't and in what circumstances.  Business could value the data and then apply controls that are appropriate to the value of the asset.  Getting back on topic,  breaches could also be identified based on the value of data lost/stolen.  Post breach reviews could have consistent context applied when auditors and forensics come in, and the control environment can be reviewed in the context of the value of the data.  These breaches could be disclosed anonymously to the regulator or a body operating for the regulator, who could then openly produce statistical information on the likelihood of certain breaches occurring in certain sectors (over time).  This would give us all a better ability to beat off the FUD, and manage our information security risks in a more quantifiable manner.



More soon

Andy

First post!

After much deliberating, and finally succumbing to twitter I've finally decided to start a blog.


The purpose of this is really to help answer or to start discussion on the question I get asked most often.  "How do we make it compliant?" - As an information security consultant,  IT security auditor and a PCI-QSA I must hear this question on a daily basis.  So I thought I'd start to post some of the thoughts, conversations and various other info I have for the benefit of who-ever is listening.


A few words of warning, I'll probably rant, I'll probably go off at tangents and I'll probably not give you all the answers.  That being said I'll certainly try to keep this as useful as possible.