Category: Core Concepts

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.

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.

Been composing this blog for several months now, and it started when I was thinking about how superstitions begin; It’s bad luck to walk under ladders, or it’s 7 years of bad luck if you break a mirror for example.  And then it occurred to me that these superstitions were probably the only way to scare children into, or out of, certain behaviour.

Walking under ladders, well duh, things fall OFF ladders, so don’t walk under them, and mirrors used to be really, REALLY, expensive, so telling children that breaking them would have horrific consequences makes a lot of sense (in a very negative way of course). I’m surprised that playing with matches didn’t become a superstition, but then again, household-use matches were not readily available until the 1800’s.

Unfortunately, these things have a way of sticking around long after the original cause is either meaningless, or worse, is twisted and perverted by those with a vested interest in the status quo. ‘Heretics’ were burned at the stake for suggesting that the Earth revolved around the Sun, and not the other way around*, and ‘witches’ were similarly killed in horrific ways when they suggested that herbal remedies were better than leaches and other forms of bleeding. Priests and Doctors respectively were very protective of their power.

Human nature has changed very little since then, only societal laws and the more progressive ‘norms’ keep the peace.

I have for years likened information security to insurance, in that no-one wants to spend money on it, but they know it’s a cost of doing business. And more recently I have likened security to the law, because it’s becoming so complex in terms of regulation / legislation / standards etc, that’s it’s often out of reach for the organisations and individuals who need it most.

Now I find myself likening security to superstition, because from the way we’re going, it won’t be long before being in security will have the same stigma as being a tax auditor, a parking enforcer, or a lawyer. QSAs are almost there already because the entire concept of PCI is so limited, but there is no reason true security professionals should not be seen in the same light as those responsible for driving revenue growth or competitive innovation.

Security departments are something people go out of their way to avoid, or to circumvent. They are seen as the department-who-says-no, who will stifle innovation and good ideas, and generally do the one thing that would label them heretics; get in the way of revenue.

Nothing could be further from the truth, as no other department has the knowledge and DESIRE to do the things that make staying is business possible:

  1. Innovation: It’s the 2000s, the vast majority of innovation now is in technology. Who else is best placed to pick the RIGHT technologies to ensure that innovation is implemented in a way that enhances the organisation and not just adds risk?
    o
  2. Business Transformation: Competitive advantage in the information age is now measure in weeks and months, not years, organisations without the ability to adjust critical business processes quickly and appropriately will be left behind. What other department has the knowledge of exiting processes to enable the adjustments?
    o
  3. Revenue Protection: Can you think of anything worse than seeing all your revenue disappear into the hands of regulators because your focus on selling failed to take into account that your processes for doing so were completely inappropriate. I understand completely the pressures, but revenue generation is not about doing what it takes, it’s about doing what’s right.
    o
  4. Reputation Protection: I could have put this under revenue protection, but wanted to break this out as corporate reputation goes way beyond just revenue, and my OCD will not allow for an even number of bullet points. Damage of reputation through loss of data C.I.A. can have long-term negative effects on a business, just ask CardSystems who went from $25M / annum to out of business in less than 1 year after their breach.
    o
  5. Infrastructure Investment Optimisation: OK, long title, but consider that the amount of money spent on PCI is already in the multi-billions, when a huge chunk of that could have been save by adjustments in PROCESS. Technology purchase is the last resort of a true security professional.

I really don’t have an answer to HOW we can ensure our reputations remain unsullied, and there are a lot of so called security experts out there giving the rest of us a bad name, but I think the worst thing to do is fall back one of the phrases I hate most in this world; “It is, what it is.”

Actions speak louder than words, and I will never stop trying to show my clients that security is something to be embraced, not avoided.

Forward this to all your friends or you’ll have 3 years of bad luck.