PCI, You Have Chosen Poorly

PCI DSS, You Brought It On Yourselves

I have never hidden my disdain for the PCI DSS, and have written numerous blogs as to why. Not just whinging mind you, I have always included a stab at providing solutions or alternatives. But every now and again, I have to remind myself why the DSS even exists in the first place. And who needs to accept a sizeable chunk of the responsibility for it.

It’s you Mr. Retail, and you Mr. E-Commerce, and especially you Mr. Service Provider. You are every bit as culpable as the Card Brands.

Yes, the payment card technology is 50+ years old, and hopelessly outdated. Yes it’s a ridiculous way of paying now that there are so many better ways. And yes, it’s very difficult to protect cardholder data, but it’s really not complicated. All it took was effort.

But organisations didn’t make any effort. For decades on end. From stand-alone terminals, to integrated points of sale, to e-commerce, and now to mobile, the threat landscape has changed beyond measure. The corresponding risk management programs have done next to nothing.

Let’s take a quick look at the causes of 3 of the worst card data breaches to date:

  1. T.J. Maxx (2007 – 45.7M Primary Account Numbers (PANs) compromised) – I know this one’s going back a bit, but it’s one of those rare examples of where the PCI DSS was [mostly] up to speed with the prevailing threat landscape. The breach was caused by weak encryption on their wireless access points. Although Wired Equivalent Privacy (WEP) was:
    o
    i)   known to be vulnerable way back in 2001;
    ii)  replaced by WPA in 2003;
    iii) deprecated by the IEEE in 2004, and;
    iv) addressed specifically in the DSS from as early as v1.0 – “4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi Protected Access (WPA) technology if WPA capable, or VPN or SSL at 128-bit. Never rely exclusively on WEP to protect confidentiality and access to a wireless LAN.
    o
    …T.J.Maxx still had WEP as its standard. This vulnerability (plus horrifically poor network segmentation) lead to the compromise. It also took T.J.Maxx 18 MONTHS to find out.
    o
  2. Target (2013 – 40M PANs compromised) – Network access credentials stolen from a 3rd party and used to remotely log in to systems in-scope for PCI. An HVAC provider at that! Where to even begin on where Target went wrong?! But we can assume:
    o
    i)   vendor due diligence and management was sub-standard (addressed in Requirements 12.8.x);
    ii)  vendor access standards and monitoring were not in place (addressed in Requirements 8.1.5.a, 8.1.5.b, and 8.3.2.a);
    iii) change detection mechanisms were either not in place, or ineffective (addressed in Requirements 6.4.x);
    iv)  logging and monitoring mechanisms were either not in place, or ineffective (addressed in Requirements 10.x), and;
    v)   network segmentation was inadequate.
    o
  3. Home Depot (2014 – 56M PANs compromised) – Similar to Target, which makes this one even more embarrassing and unforgivable.

If we were to look at the thousands of other breaches that have occurred we would find little difference. It’s not so much concerted attacks from dedicated and skilled hackers that’s the problem, it’s the complete disregard for basic security practices by the vast majority of organisations. Organisations who KNOW better, but have chosen instead to just roll the dice.

I’m not saying that these three examples were not perpetrated by skilled hackers, but the level of skill required was significantly less than it should have been. In fact, if these organisations only had DSS levels of security controls in place, the attacks would have significantly more difficult. REAL security would have made these targets of last resort.

What Are You Going to Do About It?

As the South Africans say; If you want security, build your fence higher than your neighbour’s.” The reason the PCI DSS exists is because no one was building any fences!

The right things to do for security have, quite literally, been written down for generations. Ignore these basics and the upcoming regulations related to privacy will make PCI look like a walk in the park by comparison.

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

Can Governance Replace the CISO?

Perform research on IT Governance models and you’ll eventually come across the concept of People, Process, & Technology (The Golden Triangle). Yet another concept whose origination has been lost in time (it was not Bruce Schneirer), but one whose evolution has polarised the security industry.

On the one side you have the technology-first advocates. Even a security icon like Bruce Schneier says; “We rely far too much on policy and people, neither of which are reliable, especially when dealing with fast-changing, large scale infrastructures.“. Oddly enough you’ll find most of the security product vendors in this camp too. I know, weird huh?

Then you have the side that I’m on, that says all the technology in the world can’t fix stupid. The enormous benefits that can be derived from technology are only achievable if the people put the processes in place to make the technologies effective.

In cybersecurity, technology can only enhance, it cannot fix.

Yes, of course technology is critical, why do you think I rage against PCI’s ‘daily review’ of logfiles so much? No, I do not believe that an organisation can ever achieve good security without the automation that only technology can bring, but putting technology first is the definitive cart before the horse.

In cybersecurity, technology can only enhance something that already works, it cannot replace it entirely.

So, to me, the job of the CISO is to get the three aspect of the golden triangle into line with the only things that matters; the business goals. In the digital age, technology is the ultimate enabler, and the CSO/CISOs the ultimate facilitators of that technology. The IT security function gets involved in everything from M&A to compliance, from incident response to internal audit, it’s the CISO’s role to bring it all together into a sustainable program. One that that is only ever appropriate to the business’s needs and no more.

But none of this is possible without Governance. The CISO, as a facilitator, is only a bridge between the business goals and the means to get there. It’s the Governance function that gets the job done.

Also, not every organisation can afford a CISO, and frankly nor should they even contemplate one if there is no discernible return on investment. This is where the Virtual CISO can come into play, and from my perspective, the only reason to consider one. It’s the v-CISO’s job to train the governance committee (or whatever it’s called) to do what CISOs do.

Too many organisations are instantly turned off by the word ‘Governance’. At best it’s seen as unnecessary bureaucracy, at worst it’s perceived as some kind of dystopian ‘Big Brother’. Nothing could be further from the truth; it’s not a department, it’s not an institution, it’s a function, one designed to help keep a business IN business.

EVERY organisation needs governance, regardless of size, region, or industry sector. The governance charter, membership, responsibilities, and operation will vary considerably, but all need to be appropriate, and of measurable benefit.

Only someone with the skill-set of a true CISO can put this in place in such a way as to be sustainable without them. But only a Governance function can keep it going.

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

 

In Security, Technology is Always the LAST Resort

The temptation to spend money to make something annoying just go away is almost irresistible. I’m not just talking about security now, this is a human condition. From get-rich-quick schemes, to diet pills, to online ‘dating’, we want instant gratification and / or results. Sadly we also expect the underlying cause of our issues to be miraculously fixed as part of the fee.

What do you mean “Get your fat arse off the couch and go for a walk!”, I paid you to make me thin!? There are no shortcuts to fitness, and there are no shortcuts in security.

None.

But with phrases like; ‘panacea’, ‘silver bullet’ and my personal favourite; ‘guaranteed hack-proof’, the cybersecurity industry is becoming one of the worst offenders. Money is clearly more important than good service to many security vendors, and to those expounding on their virtues.

And we’re letting them get away with it! Whether it’s because we’re lazy, don’t know the right questions to ask, or just don’t care, it’s immaterial. Vendors will keep making useless products and we’ll keep buying them if things don’t change. Vendors have sold F.U.D. for years and we’re bringing only a few of them to task (FireEye for example).

The more complicated vendors can make security appear, the easier it is to sell their technology. At least that’s how it seems. There’s really no escaping that security must be simple to be effective; forget big data, use baselines; forget microsegmentation, just segment properly, forget user and entity behavioural analytics, fix your access control. In fact, ignore every acronym in the Gartner ‘Top 10 Technologies for Information Security in 2016‘ and focus on the basics, I’ll almost guarantee they aren’t addressed appropriately.

From policies and procedures, to change control, to vulnerability management, to incident response, worry about the base processes. They are not only more effective than any new technology, they are a damned sight more sustainable, more scalable, and cheaper!

One of the universal truths in security is that you cannot fix a broken process with technology, you can only make a good process even better. Better in terms of accuracy, speed, effectiveness, efficiency, long-term cost, you name it, the underlying process had to have worked beforehand.

Take incident response (IR) for example. If you have top-notch plans, a well trained team, and robust vulnerability management, a technology that gives you earlier event warnings is of distinct value. As would technologies that; reduces false-positives; automatically quarantine infected machines; supplies greater forensic information up-front, and so on.

However, if your IR plans are crap, your team has no idea what to do, and your systems have not kept up with the threat landscape, no technology in the world will stop an event from becoming a business crippling disaster.

Be honest,  how many of you have:

  1. Firewalls but poor segmentation?
  2. Routers but no mapping of your business processes?
  3. Anti-Virus and no OS hardening?
  4. HSMs and no idea where all your data is?
  5. Centralised logging with no idea what ‘normal’ looks like?
  6. …and the list goes on.

How can you expect a new technology to help when you’ve haven’t optimised what you already have?

There are of course exceptions to every rule, and in this case the exception is to buy an Asset Management System. Everything else you do in security has your assets at the core. Do this well and everything else becomes much easier.

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

[For a little more information on technology purchases, this may help; Security Core Concept 2: Security Control Choice & Implementation]

Virtual CISO

Are ‘Virtual CISOs’ a Good Idea?

Type “virtual CISO” into Google and you’ll get ~240,000 hits, with the top 10 being mostly vendors who offer this as a service. I have no doubt much of the remaining pages are the same.

In other words, just about every security vendor out there is seeing a need, and they want to be the ones to fill it. As a corollary, if organisations weren’t crying out for the service, no-one would be offering it.

I am no different, in that I too see a massive gap in senior leadership security expertise that no one in-house can fill. Due to price constraints, it is quite often inappropriate to fill such a senior and specialised role on a full-time basis. Where I differ is the length and function of the v-CISO, as I cannot see how an indefinite ‘outsourcing’ is in my client’s best interest.

Let’s face it, once you outsource the function of something, it is a very small step to try and outsource the responsibility for it too. And finally, if you got away with that, an attempt at shirking the accountability is never far behind. This is where both organisations asking for help, and v-CISOs alike, make their biggest mistake.

The v-CISO should never be a long-term proposition, which is why I call my service an ‘Interim Security Chief’. While this may seem like semantics, it’s the difference between doing the work for you, and enabling you to do it for yourselves.

First and foremost, a v-CISO should be a teacher and a mentor, not [necessarily] a ‘doer’. Yes, they can design big-picture processes, from secure architecture to governance charters, but they had better not be expected to own them. A good v-CISO is nothing more than an consultant at the senior management level, and any deliverables must be sustainable long after they have moved on.

That said, I see nothing wrong with a v-CISO remaining part of ‘steering committees’, providing ongoing security awareness training, or even taking part in incident response testing. But, once the CISO functions have been absorbed internally, the v-CISO becomes part of the cycle for continuous improvement only. They stay around to provide strategic input on industry trends and the changing threat landscape, they don’t dictate the enterprise goals.

What You Should  Expect From a v-CISO

These are the three main things you should expect from a v-CISO, take particular note of the transience of each deliverable.

  1. Governance Charter Development – There is no security program without Governance, and there is no better platform onto which the v-CISO can pass on their operational function. This committee can in fact replace the v-CISO in due course, but may bring them back in as a trusted advisor or SME. The members of the governance committee will share the CISO function amongst themselves based on individual capability, and their meetings will bring it all together.
    o
  2. Policies & Security Awareness Training – Along with governance, policies are intrinsic to a security program, and along with the formation of that committee, represent the most important part of a v-CISO’s role. Unless the polices are in place, and all employees appropriately trained, nothing else they try to do will work effectively.
    o
  3. Process Development – Security programs consist of a number of critical processes, all of which must be developed, tested, tested again, and take their place in the never-ending cycle of improvement and business as usual. These are the big ones:o
    • Risk Management – Includes the enterprise-wide risk assessment and risk treatment procedures.
    • Vulnerability Management – Keeping up with the threat landscape.
    • Vendor Due Diligence & RFPs – Significant aspects of the security program will likely be outsourced to skilled providers, so the right questions must be asked.
    • Event Management & Incident Response – Bringing all the controls together into a business saving process.
    • Disaster Recovery & Business Continuity – What to do if everything goes completely pear-shaped.

Anything else the v-CISO does will depend on the organisation’s needs and the v-CISO’s skill-set.

But what about Strategic Advice, Board Level Interface, Regulatory Compliance Lead and a whole host of other fancy names / clichés? Yes, these are all important, but are utterly meaningless until the basics are in place.

Any security program put in place by a v-CISO must be in-line with the business’s goals, appropriate to their needs, and sustainable in their absence. So if you’re on the market for a v-CISO, you had better know what you need, or you’ll get what a salesperson thinks you asked for.

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

PCI SSC: Effective Daily Log Monitoring

PCI SSC: ‘Effective Daily Log Monitoring Supplement’ – They Missed Again

The SSC released their Information Supplement ‘Effective Daily Log Monitoring‘ in MAY, and I’m only just hearing about it now! Either I’m completely out of the loop (not being a QSA) or the SSC did a very poor job PR-ing it.

I think I understand which it is now that I’ve read it.

Anyway, despite the blatant oxymoron in the document’s title, and my own predisposition toward negative bias where the SSC is concerned, I was still hoping to be pleasantly surprised.

I wasn’t, but nor was I as horrified as I have been while reading output from other SIGs.

It’s actually a really good beginner’s guide to logging, but it’s completely unsupported by the DSS in its current form. And it’s not just me looking for faults, they have not put logging into a proper, or even accurate, context to the DSS requirements as written. With their knowledge of best practice, they basically made the rookie mistake of assuming requirements mean more than they do.

To be clear; If it’s not specifically spelled out in the standard, it is not mandatory. Period / full stop. Even if it’s the right thing to do.

For example: There is no requirement for any automated alerting. Not from firewalls, not from A/V, not from IDS, not from FIM, and not from ‘system components’ like servers and applications. So the statement; “The PCI DSS recognizes the importance of proactive monitoring of security logs in the detection of attacks on information assets and the protection of those assets from compromise.” is inaccurate. The SSC might recognise the importance of pro-active monitoring, the SIG’s participants clearly do, but the DSS only recognises the need for what amounts to forensic evidence. Nothing more.

The DSS uses the word ‘alert’ in only 6 relevant Requirements:

  • 6.6  For public-facing web applications, ensure that either one of the following methods is in place as follows:

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

– Is configured to either block web-based attacks, or generate an alert that is immediately investigated.” – [Alerts are non-mandatory, and can be manually generated.]

  • 10.5.5  Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).” – [No time-period defined, so you have to assume weekly like 11.5, or at most daily like 10.6. Alerts can be manualy generated.]
    o
  • 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.” – [Non-mandatory]

  • 11.1.d  If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.” – [Non-mandatory, and/or no time-period defined.]
    o
  • 11.4  Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.” – [Alert how? Automatically or during a daily review?]
    o
  • 11.5  Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.” – [Weekly notification, so clearly does not require automation.]

So if there’s no requirement for automatically generated alerts, and daily is the maximum defined review timeframe, how can they possibly insist on 24/7 availability related to Incident Response (DSS Req. 12.10.3)? Who is going to choose 2AM for their daily review?

Even the SIG makes the statement; “Without automated alerting mechanisms, it is almost impossible to identify and alert about such events in near real-time.“. In other words, in time to actually do something about it before it gets out of hand.

But I thought this was about effective DAILY log monitoring?

So All In All…

The thing that still confuses me most, is that the DSS is full of mandatory technologies, but a manual and daily review of logs is still OK?! Not one technology in the DSS is required to be utilised properly, and some have significantly less benefit than a Security Incident & Event Management (SIEM) or an equivalent managed service:

  • why require firewalls and routers then don’t mandate review of the traffic logs?
  • why require an asset database, but not an asset management system on which every other security processes can rely?
  • anti-malware is based on signatures so is all but useless
  • intrusion detection is pointless unless the entire infrastructure is baselined to a known-good
  • …and so on.

So of ALL requirements, how can centralised logging and automated alerts not be mandatory?

This post in already too long, and I’ve barely begun to scratch to surface of why logging and monitoring is so important.

There’s no escaping that the document name; ‘Effective Daily Log Monitoring‘ is misleading, it should be called the ‘We Cannot Tell You to Buy a SIEM, But Good Luck Getting Compliant Without One‘. Basically the SSC has all but admitted that the logging and monitoring requirements are completely inadequate, but can think of no way to change them in the DSS. Not without pissing off a lot of people anyway.

Finally, it IS  a good document, worth a read, and kudos to the authors. Unfortunately it’s guidance is meaningless to those without the means to perform anything other than manual daily reviews.

Bonus Material

If you’re interested, I have provided some additional thoughts in my own Logging Supplement document. There are 3 sections:

  1. Breakdown of Existing DSS Logging & Alerting (Non-Server) – There are 5 DSS requirements outside of the established logging and alerting requirements, and are ambiguous at best. They are also not covered appropriately in the SSC’s Supplement.
    o
  2. Missing from the DSS – The SSC’s Supplement did not cover daily review appropriately, nor did then then go far enough to cover appropriate automation. This section covers a few of the major benefits of logging and monitoring properly.
    o
  3. Automating the Daily Review – There are only three processes required to automate the daily review, but it cannot be done without centralised logging and scripting skills, a managed service, or a SIEM.

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