Tag: Going Beyond the Standard

First, let me be clear; I hate anti-virus. I guess more accurately, I hate anti-virus companies who are still making squillions peddling their no-longer-relevant wares (in my opinion).

Blacklisting (i.e. signature based) end-point protection is meaningless and almost completely ineffective against zero-day attacks. It’s a game of constant catch-up that can (and will) never be won. Yet here we are, still buying anti-virus software because we don’t know better, and standards like the PCI DSS still call for it by name instead of dealing with the actual underlying issue.

What is the INTENT of anti-virus?  According to the DSS, you should;

5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

…and;

5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

Commonly affected? As defined by whom? Clearly they mean Windows but can’t just come out and say it. Yes, other OSs are becoming increasingly affected by viruses, but would you call them common? More to the point; if you had to install and maintain anti-virus on all of your *nix and Apple products would YOU classify them as ‘commonly affected’?

No, neither would I.

The intent of anti-virus is sound; do not let bad stuff run on your systems. However, if you were doing security properly, would this not be basically redundant? Even PCI includes the means by which anti-virus becomes [in my view] excessive;

  1. Security Awareness Training (Req. 12.6) – If users were properly educated, a huge chunck of malware outbreaks would not happen in the first place. If your organisation does not have a very robust program for ongoing security training, they have missed the cheapest, and most effective security control that has, and will, ever exist. Ignorance is a choice, never an excuse.
    o
  2. Configuration Standards (Req. 2.x) – In my continuing theme of never backing up bold statements with actual facts, I will pronounce that the majority of malware out there is ONLY effective because the systems on which the malware is loaded are not configured correctly. Either the hardening guides are absent or inadequate, or the ongoing maintenance of the configurations was neglected.
    o
  3. Vulnerability Management (Req. 6.1) – If all you are relying on is patch releases from your OS vendors, then you deserve what you get. Vulnerability Management is everything from Patching, to Vulnerability Scanning, to Penetration Testing, to Change Control and Incident Response. Done well, vulnerability management is the only way you stand even half a chance of keeping up with the bad guys, but something I have personally never seen done well.
    o
  4. File Integrity Monitoring (Req 11.5) – Don’t buy Tripwire (I hate them too), but figure out a way to detect if a known-good file changes in some way. I have seen a client write an MD5 recursive hash on system32 and write the results to event logs for monitoring. It was free, and effective, but required significant expertise. All you’re trying to do here is make sure things stay the same, and it almost begs the question; Why have AV at all if you have FIM? This question becomes far more relevant the more of these points you master, but I will never negate the concept / cliché of defence-in-depth.
    o
  5. Logging & Monitoring (Req. 10.x) – In my opinion, nothing in your detective security portfolio is as important as this control, and can be used to create the most effective and ‘blanket’ compensating control for PCI there is. If you know what every system SHOULD be doing, anything NOT that is something to investigate. Daily review of log files is a farce, only real-time alerts triggered by base-line deviations makes sense, and should be the top of any organisation priorities to get right. Few do, and the majority of Managed / Cloud Security Services don’t do this either.
    o
  6. Incident Response (Req. 12.9) – Why bother being in business if you don’t intend staying in business? Incident Response can prevent an event from becoming a business crippling disaster, yet, like Vulnerability Management, is almost universally neglected. Do this one badly and I for one have no sympathy.

You should notice one unifying theme across all 6 of these controls; they have a significant process component, not technology. Most security is process, and yet PCI has driven more technology spend than all other compliance / regulatory standards in history combined (yes, that’s another fact-less statement, but I would be amazed if it wasn’t true). Anti-virus vendors, FIM vendors, logging vendors (and QSAs of course) have all made multi-millions from PCI, and not one of these vendors (including the QSAs) has ever made the effort to put their products into the proper context; A business focused solution that provides true benefit. Staying is business  IS an ROI!

All 6 factors will be addressed in their own Beyond The Standard posts, that should give some indication to their importance.

OK [deep breath], end of rant (and my longest blog of the series yet)! I’m not saying don’t use anti-virus if you believe it provides true benefit, and is not a massive capital / resource drain. But do NOT do it just because PCI says you should, do NOT rely on it, and focus your efforts on the above 6 factors as they are the things that actually meet the intent.

If you are only doing PCI minimums your QSA probably has no choice but to insist on AV (especially for Windows), your job is to give them an alternative.

This is one of my weakest subjects when it comes to the 12 Section of the PCI DSS, the only one at which I’m actually worse is coding stuff. That said, there are a few things I can touch on that should be self-explanatory, but for some reason are still tremendous pain-points for a lot of organisations.

In terms of cardholder data storage, what it really boils down to is one question; Is cardholder data core to your business?

This may sound like a stupid question, but unless your business IS the processing of cardholder data there’s a very good chance it’s not a core function of your business. For example, in ALL of retail, cardholder data is not core, it’s simply one means to an end. The end is receiving payment for your service / products, HOW you receive payment is not the important part.

If you accept the fact that credit cards in their current form will die over the next 5 – 10 years, any investment into your cardholder data infrastructure should match this end-of-life process. Outsource card payment if you can, if you can’t, encrypt the data from the point of interaction (POI, usually a PED / terminal of some sort) to your processor, and retain nothing except the first 6 / last 4 of the PAN post-auth. If that.

You simply don’t need to keep it for the myriad of reason you once did:

  1. Settlement – now handled by your third party processor or your acquirer
    o
  2. Fraud Investigation – There is enough information in a transaction to not require the ‘middle six’ digits of a card (this is not the same as anti-fraud processes)
    o
  3. Marketing – There was never a need for card numbers in marketing processes, and this should have been removed long ago
    o
  4. Finance – The card number is not part of any finance department reconciliation, and again, should have been removed long ago
    o
  5. Recurring Transactions – e.g. subscriptions, this can now be handled by your third-party processor or your acquirer

What you’re fighting against here is one of the worst phrases in history; “But we’ve always done it that way!” (Only “What are you thinking? and “Is that it?” are worse). Your Risk Assessment should have mapped your business needs to to your data flows, and any storage fully justified. And they should be RE-justified every year as part of the Top 5 risks to your business (just look at Target, and Michaels, and Neiman Marcus, I’ll bet they wish they had examined their business a little more closely).

Assuming you DO need to keep cardholder data, then here you should involve an encryption subject matter expert (SME), and if budget allows, a Host Security Module (HSM) to perform your key management. Unless you have significant in-house expertise, writing your own code and managing your keys manually is like pushing a car down the highway to save money on petrol.

As for encryption of data in transit, this is relatively simple. The cardholder data should never be seen on the wire outside of either data / file-level encryption, or an encrypted tunnel. SSL / VNP tunnels to / from every system in the process flow should be in place at a minimum.

However, does the PCI DSS require this for compliance? The answer is no, it doesn’t, it only says this; “4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:…“.  I assume that you consider your internal subnets / VLANS behind the DMZ to be closed and private, thus negating the need for encryption.

Of course, this exposes the data to packet sniffers on those private networks, which automatically includes the majority of Intrusion Detection Systems (IDSs), so performing transport level encryption just makes sense if latency issues are manageable. This also adds yet another ‘blanket compensating control’ to your growing portfolio of above-and-beyond security measures.

This is as much as I can BS my through encryption, but in summary;

  1. Don’t keep it if you don’t need it, and be absolutely brutal in your examination of business processes
    o
  2. If you do need it, get expert help to minimise the complexity of all key management processes
    o
  3. Encrypt the connection between all systems in the CHD process flow, regardless of trust status

As always, if you need any help on this stuff, you need to find someone who can help you ask the right questions.

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!]