Author: David Froud

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?
    o
  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.
    o
  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.
    o
  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.
    o
  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.

Q: What do you do?

A: I’m a consultant.

9 times out of ten the asker of the question enquires no deeper, because they were either just making polite conversation, or they just don’t care. Or both.

The title of ‘consultant’ can hide all manner of sins, as it can be used to enhance the reputation of the unworthy, leading others to believe that their level of expertise goes as deep as the up-front appearances. It is, however, far preferable to ‘expert’, which is bandied around far too often and usually by the very people least equipped to do so.

The old cliche; “An expert is someone who knows 1% more than those around him.” is as true now as it’s always been. And if I’m honest with myself, so is “An expert is just somebody from out of town with slides.”, but that’s a little too close to the mark.

Luckily, you don’t need to be an expert in anything to be a great consultant, you just need to know people who are experts, and when to apply them. For example, there are thousands of people who do every individual thing that I do, and do it many time better, but few can apply their overall knowledge, experience, and skill-set to a client’s maximum long-term benefit.

What are the 4 consultant types?

  1. The ‘Auditor’: Auditors are extremely detail oriented, and can (and do) write massively detailed reports on exactly what you’re doing wrong. While this can be very useful in some scenarios, if you were looking for someone to tell you anything other than what is broken you have the wrong person. There will be little to no out-of-the-box thinking with an auditor, if you aren’t doing exactly what is written, you will fail the test. You will also receive very little in the way of of help actually fixing the problems, so will probably end up paying someone else to finish the piece of work;
    o
  2. The ‘Assessor‘: Assessors are still very tied to the written instructions, but are better able to read the intent of the situation, and are subsequently better able to tell you why a things is not right, as well provide some limited guidance on how to fix it. As with the Auditor, you will likely require additional help to reach your goals, but if you are looking for a sanity check or [cringe] tick-in-the-box compliance with a standard like PCI, then Assessors are a reasonable choice. Mostly because they are cheaper;
    o
  3. The ‘Consultant’: I reserve this title for people who are able to not only explain simply what you are doing wrong, but 1) why it’s wrong, 2) what you should be doing, and 3) provide several options on how to fix what’s wrong. The Consultant’s experience will be such that they have seen close to your specific scenario many times, and can provide all the guidance you need to choose the right solution(s) as well as implement them appropriately. You might be thinking this is the ultimate, but it isn’t, there is a critical aspect missing from the Consultants’ portfolio, which is filled by;
    o
  4. The ‘Teacher’: Teachers approach every gig with a single goal in mind; to never have to repeat anything they do. These rare folks are able to enormously simplify the challenge at hand, and TEACH the client to fix it themselves. And not just once, whatever the solution was, the Teacher will show the client how to maintain the fix, and how to implement a cycle of continual improvement in line with business goals. Above all, the Teacher will help you to always ask the right questions, which is half the battle.

In the PCI space for example, I can count the number of Teachers I have seen on one hand, and even Consultants are thin on the ground. I don’t blame the consulting companies for this, it’s the clients who are continually bitching about price and settling for the lowest bidders.

In consulting, more than in almost any other profession, you get what you pay for, and Consultants/Teachers are always cheaper in the long run.

Also, you will eventually get the type of consultant equivalent to the level of effort you put in finding one. If you end up with an idiot, it’s because you’re lazy.

Don’t know where to start? Ask.

[If you liked this article, please share! Want more like it, subscribe!]

Behind every PCI requirement is an intent. Unfortunately the intent is almost always obscured by the level of detail and specificity within each requirements’ description and testing procedures. But it’s important to understand this concept or you’ll end up chasing rainbows.

The networking section (PCI DSS Section 1.X) is no exception, so before I can provide an above-and-beyond I have to provide a baseline.

The intent of Section 1 is basically four-fold (I’m ignoring personal firewalls and network diagrams for now):

  1. Keep the bad guys out, especially from the Internet
  2. Limit communication between trusted and un-trusted systems to what’s necessary for their business function
  3. Limit ANY connectivity to/from in-scope systems to/from the Internet
  4. Limit insecure protocols, or ensure that their use is both justified and the risk mitigated

The ONLY thing in PCI that you cannot compensate for is the retention of sensitive authentication data (SAD) post-authorisation, EVERYTHING else can replaced with other controls as long as the risk mitigated by the original control is not greater with the replacement control(s).

For example; you do not have a personal firewall running on administrator laptops. All you have to do here is restrict all connectivity to in-scope devices to a jump server / bastion host through which ALL administrative connections must pass (BTW, this works just as well for lack of 2-factor authentication too). Note: You’ll hear QSAs use the phrase; “above and beyond” here, but it’s the intent of the requirements that’s the overriding factor.

As long as you have met the intent of the above 4 bullet points, you have your baseline, all of the following therefore are above-and-beyond (AaB.):

  1. A rule-set review more frequently than twice a year – Depending on your environment, having each rule owner (which should correspond to a data and/or business process owner) confirm that all rules are still required more than semi-annually is considered AaB. This would be especially effective if the network administrators could confirm the frequency of each rules’ use during that quarter.
    o
  2. A business justification for every rule – PCI only says that you must limit inbound and outbound traffic; “to that which is necessary for the card holder data environment.”, and between ‘trusted’ and ‘un-trusted’ networks. Which means that not only can these justifications be done at the protocol level (and not at the individual IP level), but does NOT have to be in effect between trusted networks. Therefore, if you have the following in place, you have gone wayyyyy AaB:
    o
    i.    Business justification of ALL ingress and egress filtering, including that between trusted networks
    ii.   Filtering down to the IP level (not subnet blocks / services), but this can be EXTREMELY complex so a judgement call is required
    o
  3. Automated confirmation of rule set accuracy – If both firewall rule sets AND the end systems were perfectly configured, there would be no ‘denies’ in the firewall logs except that which corresponds to changes in the environment (which should have a change control request next to it), or to things that should be investigated. This can work in both directions; system configuration validation and rule set validation, but a significant base-lining effort would need to be performed and maintained by Asset Management (see PCI – Going Beyond the Standard: Part 6, Asset Management).
    o
  4. Review and baseline firewall / router traffic logs – The logging requirements in PCI refer to administrative connections to the network devices themselves, nothing in PCI says you must collect and retain traffic logs, therefore including these in your ‘daily review’ can be considered AaB. It will also be impossible to do 3. above if you don’t.
    o
  5. Network devices capable of more than stateful pack inspection (SPI) – PCI only requires that the network devices in use are capable of SPI, which can be performed at layers lower down the OSI stack than todays’ devices are capable of performing. Therefore, a network device which also performs application layer filtering can be considered as AaB in all instances except where it would be required anyway (i.e. Requirement 6.6)

A recurring message throughout the next 12 blogs (which corresponds the DSSs’ 12 sections), is the need to read the requirements VERY carefully. Good security consultants will naturally make assumptions on a requirements’ intent based upon their perception of good practice, but PCI is a bare minimum standard, and quite often allows things that make little sense (daily review of log files for example).

Most of the above AaB points are easy to achieve, and by doing so you are building a portfolio of compensating controls which can be used in places where you cannot meet the DSS requirements language.

There will be many.

The thing with security is that there is always more than 1 top priority, so the trick is not to choose which comes first, it’s to get them ALL assigned and moving forward at the same time. There are simply too many interdependencies, and you will only avoid the inevitable road-blocks or analysis paralysis if you plan accordingly.

Asset Management is one of those top priorities, and is at the core of everything else you will ever do in the development, maintenance, and continuous improvement of your security program.

If you do it properly that is.

Prior to v3.0 of the DSS, the requirement for asset management only went so far as an understanding of every system type, function, and number of them. Basically a spreadsheet to support the sample sizes and PCI validation efforts. But this undermines the entire assessment process itself, as the whole point of an assessment is that you are able to make educated judgment calls. Knowing that you have 20 Windows web servers tells you nothing about the potential impact of their loss, for example.

I think everyone’s heard the famous mis-quote by Peter Drucker; “If you can’t measure it, you can’t manage it.”, but how do you measure the value of an asset? The answer, like everything else in security, is simple. Not easy, and pretty much never done well, but it IS simple;

“The value of each of your assets is directly related to the value of the data that flows through it.” and;

“The value of your data is directly related to its importance to your business.“

If you don’t know the above values you have a lot more problems than security.

It does not matter whether or not the ‘value’ is in financial or criticality terms, what matters is that every other security process must directly reflect its relative importance to your organisation. Does a web server have more importance to an e-commerce only merchant than it does to a plague/nest/whoop of lawyers (or whatever their collective noun is)? Maybe, maybe not. Would you expend far more effort protecting your intellectual property than you would your public web content? Of course you would, unless you’re irretrievably stupid (my favourite quote from A Fish Called Wanda).

But what IS an asset? It’s not just your servers, network devices and software, it’s your locations, your vendors, your business processes, and just as importantly, it’s your PEOPLE. Or more to the point, your people’s knowledge and skill-sets. There are often many single-points of failure in most organisations, and the one that’s most often overlooked is the human factor.

Unless you include ALL of these things, none of the following business processes will be anywhere near as effective, and perhaps not even possible:

  1. Risk Assessment – No point trying to examine your risks if you don’t know what those risks are related to.
  2. Gap Analysis & Security Control Acquisition – A logical follow on from a risk assessment, what are the gaps you have to fill? Can you use existing assets?
  3. Change Control – How can you give appropriate attention to change requests if you have no indication of regulatory relevance, maximum data classification, or the business criticality?
  4. Automated / Continuous Compliance Validation – If [for example] you don’t have a list of all the running services and listening ports against your systems, how can you hope to automate the detection of policy / compliance violations?
  5. Business Transformation – Try adjusting your business in the face of competition when you don’t know what you have and how it fits together.

Quite simply, Asset Management is too important and too core to security to give it real justice in a blog. Suffice to say, it is one of the easiest ways to centralise the required information to support every other process used to manage your security program. It is because Asset Management is so overlooked by PCI that everything else is seen as being so difficult.

This is one of the few areas where I actually recommend you look into implementing technology. An Asset Management System (AMS), especially if it forms the core of a Governance, Risk and Compliance tool. Surprisingly few do.

[If you liked this article, please share! Want more like it, subscribe!]

It is the job of every QSA to help their clients reduce their scope as much as humanly possible prior to inflicting the remainder of the assessment processes upon them. Even the very far from ideal Prioritised Approach from the SSC alludes to this in Milestone 1: Remove sensitive authentication data and limit data retention.

While the remainder of the Prioritized Approach can effectively be ignored, removing ANY sensitive data that is not required will automatically reduce risk. And once the redundant instances of data have been removed, hopefully the number of systems that transmit, process or store card holder data have been equally reduced.

The second part of the scoping exercise is to ensure that ONLY the systems in-scope for PCI are in-scope, and other systems which could be deemed in-scope-by-association are minimised.

There are 3 things that can put a system into scope for PCI:

  1. It directly transmits, processes or stores card holder data – obvious, and will include things like points of sale (POS), back-office servers, network devices and the like.
    o
  2. It’s in the same subnet / VLAN as a device that matches 1. above – not quite so obvious, and provides the greatest opportunity for scope reduction. e.g. you have 2 web servers in your DMZ but only one is relevant to e-commerce. By putting these servers in 2 completely separate VLANs, you can most likely take the non e-comm server out of scope entirely.
    o
  3. It has significant impact on a system that matches 1. or 2. above – This can include things like active directory / scanning servers / log servers / jump servers / system admin laptops and so on, and while they may never directly touch CHD, can significantly affect the security of ones that do. Being in-scope in this category does not necessarily put the other devices in the same subnet in scope, but you need to be careful here.

Unfortunately this is where most organisations start to make the biggest mistake in PCI; focusing on just the in-scope systems. Just because it’s no longer in scope, does NOT mean it should now be excluded from the processes necessary to bring the in-scope systems into compliance with what amounts to the barest minimum of security controls.

Not being in scope for PCI just means it’s a lower priority, and even then you can only make that determination if you have properly performed a Risk Assessment in conjunction with the company-wide data classification and asset management mechanisms. A good QSA will always ask for a risk assessment before they ask for a network diagram.

Segmentation to reduce scope should never, EVER, be exclusive to card holder data and PCI compliance, it should be part of an enterprise-wide project to ensure that all systems have the necessary level of protection per their data classification and their overall criticality ranking to the business.

Any effort to segment based on PCI should be appropriate, sustainable, and above all SIMPLE. Over the course of time organisations can grow organically with new business processes being tagged on to existing ones, and networks becoming more and more complex and ungainly. Unless these changes are implemented with simplicity in mind they can become rapidly unsustainable, and security itself goes out the window.

A good QSA will be able to determine scope and potentially some scope reduction options, a good CONSULTANT will be able to help you define your optimal network and segmentation infrastructure, so choose your help wisely.