Symantec’s recent issues with stolen source code are interesting. They were not attacked directly; rather, the code they had placed on an outside network was taken, presumably due to defensive defects at the third party where it resided.
The fact that Symantec suffered a breach due to lax protection in someone else’s network is a significant wake-up call. It is not enough to ensure you follow best practices; in an interconnected world, you have to worry about the security of other organizations.
Your business partners and strategic customers may be friendly, but they are not going to expose specifics to you about how well they protect themselves (unless maybe you force them to, as with hosting companies or cloud providers).
This issue – needing to understand the risk of a network you cannot see – has led to standards like PCI, FISMA, and DISA STIGs, which establish accepted, measurable baselines of “basic hygiene”. As we steadily lose control of our own critical assets, and as attackers increasingly automate their attacks, we will need more baselines like this so that one organization can show another that it is handling things properly.
Now, when I wrote the above comments in a discussion, I got some push-back about the standards I chose to highlight – not everyone agrees that PCI or FISMA are good role models. Some correspondents challenged me to defend whether these regulations really work, or provide any security. What follows is my response – a take on what PCI DSS is, what it’s not, and why I think it’s good at what it aims to do:
The key thought here is “cui bono” – who benefits?
PCI is not a magic recipe for perfect security – some would thus call it “inadequate”. But that’s not what it’s for. From the point of view of credit card companies, their money sits inside other peoples’ networks (in the form of those credit card numbers). They have spent years thinking about the problem Symantec faced – what happens when you have to put your assets inside a network you can’t control? You need assurance; PCI exists to give the credit card companies some assurance that the numbers are being looked after.
However, what makes it really interesting is that they cannot simply require that all Mom & Pop corner stores will run Fort Knox levels of security – the issuers lose money if they make it too hard to work with credit cards! So they are really in a bind. Enforce too stringent a set of standards, and nobody will be able to meet them, and so nobody will be able to use credit cards. Set the bar too low, and keep on losing larger amounts of money to theft. PCI is an impressive balancing act between these pressures.
PCI is also moving – the rules change in each revision, in a process of gradually raising the bar. FISMA is changing too. It’s true that it started as a paperwork exercise, but recent changes are shaking that up. I would say the thinking behind FISMA represents some of the best work going on today on this problem – how can you motivate people to improve, without imposing too much overhead, and while staying flexible (since the threat landscape is moving).
The attackers are increasingly relying on automation, and so the big theme in FISMA reform is “continuous monitoring” – automate your defenses, as far as possible. That is, FISMA is no longer a simple checklist – it requires metrics, and it requires them to be generated so frequently that it’s not even possible to use wasteful, inaccurate human effort. Automation is the only way to meet FISMA, and defensive automation is the right next stage of evolution.
As for how the baselines should be enforced, we can already see the answer. The government focuses on regulations of defense networks (DISA STIGs), on government infrastructure (FISMA), and on critical infrastructure such as power generation (NERC/FERC) – this is an appropriate role for government. PCI, on the other hand, is not a law – it’s a commercial agreement between people whose money (in the form of credit card numbers) is held inside the networks of other people (merchants, clearing houses, etc). This is the right model.
Anyone who faces risk due to assets under someone else’s control needs to establish a yardstick that the outside entity can use to show they have taken due care. Such yardsticks cannot be impossibly hard to meet – they need to be practical and achievable (even if this means they cannot guarantee perfect security – who can?).
The yardsticks need to be measurable – opinion calls should be avoided. They need to maintain some privacy for the organization being studied – nobody will agree to expose all their infrastructure to an outside party, so the yardstick needs to summarize well. Finally, the yardstick must actually measure security effectiveness, not just busy-ness.
In today’s world, PCI is a good example of all of these properties. It’s no panacea – it doesn’t guarantee security. All it does is offer some assurance to the person taking on third party risk that the third party is at least basically competent – “you must be at least this high to ride this ride”.
Other organizations can learn lessons from PCI, and use comparable guidelines when they take on third party risk. The movement to cloud services is a great example – the financial benefits of moving to the cloud are obvious, but the risk side remains too murky.
Buyers of cloud services face the same problem Symantec faced, and that credit card companies faced. They need to demand quantified, summarized metrics of security effectiveness and security posture from their cloud service providers. Government cannot solve this (beyond prosecuting fraud), but commercial contracts can, and PCI stands as a clear example.