Tag: PCI

Once again, my ability to help out with this stuff is limited, but even my knowledge of what constitutes a good coding practice exceeds that of most organisations with whom I’ve worked.

The best phrase I’ve heard about the need for security relevant skills in coding is; “Applications are the gateways to your data.” So no matter how much network security you have, no matter how many controls you have in place, if your applications are insecure the bad guys get what they are after.

Functionality, and sometimes just appearances, often wins over the needs to build in security from the ground up. This is especially true with organisations who do not have the necessary skill-set in-house and are forced to outsource. The inability to conduct the right due diligence, as well as the usual budget constraints, combine to perpetuate the same vulnerabilities for quite literally decades.

Cross-Site Scripting (XSS) for example, has remained in the OWASP Top 10 since its first release back in 2004 (according to this site anyway), and has never dropped below 4th. How is that possible? With the enormous amount of information out there about how to code against this flaw, the answer is not that the bad guys are getting smarter (which they are), it’s that we are staying ignorant.

Ignorance is a choice.

As much as spending money on security is the last resort (in my opinion), few organisations have the luxury of maintaining a secure coding skill-sets in-house, meaning this must be outsourced. This is simple for web-hosting, just find a compliant provider for the services, custom apps however require a little more due diligence. Luckily all you have to do is ask the right questions. Oh, wait…

In a perfect world, your security needs would drive your budget, in reality, your budget determines what quality of service you can afford. To once again quote the cliche; You get what you pay for. Unfortunately, the competition in this field is so fierce, that organisation are almost forced to provide a crap service just to break even. It used to be that security testing involved a human being skilled in the arts of ethical hacking, now price compression is pushing everyone down the road of automation and good-enough-for-PCI-work.

So regardless of which development life cycle forms the foundation of your coding practices, it must include security at all stages. Let’s take the waterfall method as an example;

waterfall

 

Security is built into no less than FIVE separate phases; Requirements, Design, Development, Testing and Monitoring, and this is in no way overboard.  Spiral, RAD, and Agile are no different, it’s just effected slightly differently.

In the end your WRITTEN life cycle must be taught to all parties, and followed explicitly, and strict separation of duties put in to place. This is not to say that you now need to hire ten more developers to meet the intent, but your checks and balances between the FUNCTIONS of the process need to show due care and attention.

Again, I’m no expert in this stuff, and there is really no way of going above and beyond here (not that going too far has EVER been an issue I’ve come across), but there is simply too much information out there, and too many talented security professionals, for there to be any excuses for not building appropriate security into your development life cycle.

Oh, and if you don’t use a code builder software (GitHub for example) to enforce the appropriate phases and authorisations, as well as effect the separation of test and production, you are already way behind the curve.

Finally, if all you use is the OWASP Top 10 as a checklist to test your web facing apps, you will be breached, it’s just a matter of time.

Not sure how to proceed? Ask.

This may be the 12th post in my series, but I cannot stress the importance of good change control enough. I have said [too] many times that maintaining a good security posture is difficult enough, but to make things easier for bad guys from the INSIDE is just plain dumb.

If nothing in your environment changes, the only way risk can increase is by a change in the external threat landscape. Your Vulnerability Management processes should have this mostly covered.

Like almost every other process in security, change control should start with robust policy and procedure, and a well designed and up-to-date, Asset Management system. If you have not only a complete listing of your physical assets, but your business processes, data stores, system and data ownership, personnel & skill-sets, regulatory dependencies, and system criticality mapped out, you have the foundation for very effective change management. Difficult to create?; yes, difficult to maintain?; only if you don’t do it properly.

Speaking of change management, if you don’t have a change control board, get one. It does not matter what you call it, but it should contain enough of the right people to ensure that both the IT and the business side of the organisation can have full insight into the risk management process, and the upcoming changes to the environment, AND to make sure these changes are in-line with the business’s goals.

Good change control starts with a policy, is clearly explained in procedures, and is central to ANY changes that can affect the continued security of your information assets. From patching, to firewall rules, to application upgrades, to server on-boarding, everything must be reviewed and approved by the APPROPRIATE level of authorisation channel. Change control can never be seen as a bottle-neck or it will be bypassed, so unless you are able to rank your changes into distinct approval channels you will end up doing too much, or too little, neither of which is sustainable.

As far as PCI is concerned, you could email your change requests to whomever is responsible, and maintain the list on a spreadsheet. For small organisations this may be appropriate, but of all things to put online, standardise, and at least partial automate, change control is way up at the top of the list. Right next to your Asset Management System itself in fact. Or even better, PART of it!

Here’s how I think Change Control should be done;

  1. The ‘Paperwork’: You will need a –

 i.   Change Control Policy – Keep it simple, even something like; “All changes to IT systems (including, but not limited platforms, application, and data) will be subject to an appropriate review and approval process as determined by the highest data classification.”, is better than most organisations have in place.

ii.  Data Classification Policy – Without a data classification policy there is no way to determine the correct level of review and authorisation required. Patching will not go to your review board, but major application upgrades certainly will. Only appropriate processes are sustainable.

iii. Change Control Procedure – Specific and easy to follow instructions enabling EVERYONE in the organisation to request a change in a uniform manner.

  1. Change Control Board – It does not matter what you call this, Change Control Board (CCB), Change Advisory Board (CAB) or Rumpelstiltskin, the charter is the same; Bring to bear all relevant resources from the business and IT sides (and SMEs if appropriate) to review and approve all changes that meet the established criteria. This should include relevant system / data / process owners where appropriate.
    o
  2. Integrated Asset Management System (AMS) – Without an integrated AMS you lose the ability to add a second layer of criticality rating to your change requests (Data Classification being your first). A proper entry into the asset register will include process dependencies, regulatory implications, max. data classification, and a system ‘importance’ rank. When these assets are available to the change control requester as a drop-down list, the full impact of the requested change is immediately apparent, and the correct level of review and approval automatically assigned. If each asset also had the system / data / process owners assigned, the review board can be built and perhaps even alerted automatically.
    o
  3. Change Closure Checklist – Too often changes are closed before the correct testing is performed, but again, what testing and approval is appropriate should be tied to the importance of the change. Vulnerability scan results, penetration testing results, user testing input, and so on are just a sample of the things that could / should be done before any change is closed.
    o
  4. Periodic Review Against Management Metrics – The change was made for the benefit of the business in some fashion, right? How do you measure success? The answer of course is; “That depends.”, but a specific date / time should be set to review the changes made to ensure that all success criteria are met. This should not be complicated or labour intensive, ever, but the review process is the only way to feed back efficiency improvements into the risk management process. Nothing is perfect.

The above list assumes you have included the basic information required to request a change (Documentation of Impact, Back-Out Procedures etc.), but the PCI minimums are rarely sufficient for an organisation that really cares about this stuff. Again, you don’t want the request process to be ridiculously long or complex, but if you don’t provide enough information up-front, you cannot perform the correct review process, nor can you measure success of the results.

Finally, if your change control process is not owned by your Governance function, you will never be able to bring the correct business oversight to bear. IT and IT Security are only ever enablers, it’s the business side that needs to own the goals.

Another crazy long blog, apologies, but change control is just that important.

For those of you errr… fortunate enough to be have been performing PCI assessments as long as I have, you will have noticed the ‘progress’ the DSS has made in terms of turning ‘just patching’ into more of a risk based approach to threats. Yes, it’s about time, and no, it has not gone far enough to be truly effective, but it should go to show just how important this subject is.

v1.1 of the DSS didn’t contain the phrase ‘risk-based’ at all, v1.2 and v2.0 say that organisations “MAY consider applying a risk-based approach to prioritise their patch installations.”, then finally in v3.0 says; “6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.”

This only took 8 years.

Unfortunately, it’ll be 3 more years before they can make any additional improvements, and when you consider how far they are already behind, and the rapidly worsening threat landscape, you simply cannot afford to do the PCI minimums here.

Vulnerability Management is the overarching process whereby a significant number of other processes are combined into a method for the never-ending examination and remediation of threats to your business. Everything from risk assessment, to asset management, to configuration standards, to change control, to patching, to vulnerability scanning to penetration testing, to monitoring and incident response, all combine into a life cycle of knowing your business goals, and enabling both IT and the business side to get there safely.

REAL Governance in other words.

I have already explained [hopefully] why Risk Assessment s and Asset Management are the starting points for a proper vulnerability management program. The rest of my list below will get their own post in due course, but here’s why they are included here:

  1. Configuration Standards – No point trying to manage risk on something that is fundamentally flawed. Don’t get these right and all the vulnerability scanning and penetration testing in the world isn’t going to help. Not to mention your logging and monitoring would be so inundated with false positives as to be rendered ineffective;
    o
  2. Change Control – Without VERY robust change control even the best initial set-ups can become rapidly insecure. Why make things easier for the bad guys?;
    o
  3. Patching – For the longest time the PCI DSS focused on the patching of systems, and insisted that all relevant, critical security patches be installed within 30 days. This completely missed the point, and while patching is an important aspect of vulnerability management, relying on reactive security measures is like taking aspirin for a broken leg;
    o
  4. Vulnerability Scanning & Penetration Testing – I lump these two together not because they are so similar (they aren’t), but because they are complimentary and fall within the same category; Testing. The cycle of constant improvement cannot be maintained if you aren’t testing your security controls and processes in some way. Test, fix, test again, repeat forever;
    o
  5. Monitoring – For every second of the day, your systems are providing information relevant to their health and security. Ignore these events, or fail to properly interpret these events and you have negated any ability you have to prevent a minor incident from becoming a worse. Unless you are able to baseline a ‘known-good’ environment, you have no idea what ‘bad’ is;
    o
  6. Incident Response (and Disaster Recovery) – In theory, you should never need Disaster Recovery if your Incident Response is as good as it should be. Without all of the above in place, you don’t have the ability to perform either well.

One of the most common complaints I get from clients is that previous QSAs have insisted that relevant, critical security patches are installed within 30 days. Yes, that’s what the PCI DSS says, but the only reason I can see that this should be a problem is if your Vulnerability Management process is so poor that you cannot show your QSA how installation within one month is actually MORE risky than to not.

There can be many reasons for this, but the inability to test patches and/or get them rolled-out in time are not excuses I would accept.

I have yet to see Vulnerability Management done well, in ANY organisation I have assessed. The pro-active life cycle approach to security, while very difficult to set-up, is nevertheless very simple and far cheaper in the long run that a reactive one. My analogy for this is that it will take me a year before I’m fit enough to ever run a marathon again, but if I had just MAINTAINED my fitness from the last one, it would be a hundred times easier.

The only things in security that stay the same are the basic good practices, vulnerability management is one of those basics.

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

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.