David Lacey lays into Compliance. Again!

He co-authored BS7799, the forerunner of the now trendy ISO27000 family of documents that describe best practices in Information Security Management. And now he has disowned his own creation as not fit for purpose in the modern age. In his latest blog post The Three Faces of Information Security, David Lacey goes further and decries all compliance thus:-

"Unfortunately, it's all based on collections of ancient practices, with a heavy emphasis on documentation and audits. And if you don't want to pay for security, you simply accept the risk. Your security might be completely ineffective but your paperwork will gain you full marks."

Lacey then goes on to describe "Real Security" as distinct from both compliance and the "business enablement" view of security we sell to management. With a doom and gloom conclusion that "most organizations are sleepwalking into a future crisis" Lacey paints a grim picture of the current state of Information Security.

Is he right? Certainly the continuous stream of breach notifications and ever growing landscape of threats seems to bear this out. We once knew what we were dealing with, or at least thought we did. We don't, not if we are relying on standards written in the 80s and revised six years ago when the term "cloud computing" was still met with giggles and shrugs and "virtualisation" was a software tool fit only for development environments. The future of Infosec demands imagination, foresight, a step change fit for the 201Xs just as BS7799 was a step change in the 1980s. Because the if current trends show anything, it's that we're even worse prepared against the enormous imagination and technical skill of todays malicious agents than we thought we were. But in truth, no more than we deserve to be.

Human Nature. Friend, not Foe?

A good education programme is worth a dozen new technical controls.

In 2007, details of 25 million UK citizens went missing on two CDs because a junior employee didn't know the rules and management procedures were lax. Similar mistakes led to huge data losses in more recent years at Zurich insurance, UK railways operator Network Rail and the British Ministry of Defence.

One possible response to these breaches is a technological one. Maybe Data-Loss Prevention technology could have helped, even something as simple as disabling the writable DVD drive on employee workstations. If the employee could not copy data to DVD they could not have lost it.

But are we missing the point? These were human failings. Like many security issues these were entirely preventable human errors. A system of people is capable of a myriad different failings. If we continue to throw expensive technological solutions at human error then we will never be finished. Wouldn't we feel better knowing that our employees know what is expected of them in the fight to remain secure and compliant? That they are on the side of Information Security and they work with us to prevent fraud, loss and service disruption?

This is what a security awareness programme does. A good one will change people's understanding of security, will encourage them to feel part of the solution, and engender good habits in their day to day activities. If the HMRC junior employee had had some education around the value of sensitive information, the trust placed in them by their customers - the British people - and the risks inherent in moving that data from a secure place to an insecure one, then maybe that breach would never have happened.

Much talk after the events above was about technological prevention and improving procedures. But human nature suggests that whatever technical or administrative control you put in place, there will be a tendency to resent the control,  to see it as a barrier to productivity and to work around it. More so if the subjects of the control - the employees with pressure to get the job done - perceive it to be too restrictive, or don't value the risk you are mitigating.

Technical and administrative controls have their place, they are a major weapon against data breaches. But a far more effective weapon is the power of human nature. Education programmes can go a long way to change staff behaviour and keep your data safe.

Why then do we spend so much money on technological solutions to human problems? DLP and Security Incident and Event Management (SIEM) are often recommended after a breach with its roots in human error. While these have their place, human element measures such as education are often more cost-effective. So why the technological focus?

Maybe it has something to do with the people doing the recommendations. Maybe the auditors, analysts and CISOs feel they have to justify their position and sizeable fee by sounding knowledgeable. Recommending staff training does not sound like expert Information Security advice. It's too simple, and not what we expect from a CISSP/CISA/whatever. So several new appliances and desktop software suites are recommended - the latest wizardry - thus the CIO feels he has received value for money from his security experts.

This needs to change. We need to value the human element in our Information systems, and recognise that it needs managing at least as expertly as the digital elements. Our people need help, encouragement and empowerment to become security advocates.

Once you've established a permanent, rolling security education programme then you might want to review your technical controls and ensure they are appropriate to the risk you are managing. Who knows, maybe you might find you can relax some controls without degrading your risk posture, and at the same time make your staff more productive. And what CIO doesn't want that?

InfoReck blog, great minds etc...

I'm delighted to have found this blog, written by Robb Reck, because we share a common belief that Compliance does not equal Security, and worse, that Compliance efforts can make you less secure. This post summarises his position and is essential reading for Infosec professionals and CISOs.

InfoReck» Blog Archive » Security Leads to Compliance

Amusingly we both wrote mid-year on the subject of compliance regimes hindering security efforts. I swear I had not read Robb's column before writing mine. Enjoy.

Secure for Compliance, don't Comply for Security.

It's been all about compliance for the last few years. Wave after wave of legislation has left us reeling, it seems not a week goes by without a recertification, attestation or visit from the auditors. Maybe we're passing our audits, maybe our auditors are giving us glowing reports as our procedures and the evidence of their being followed ticks all the boxes.

But we still get hit by a security incident. Maybe the theft of thousands of customer PINs has been traced to our software support team where a little known privilege has been exploited. Or the recent DoS attack on our web servers was routed via a previously unknown and unpatched print server. Or a rogue trader in our dealing room has been escalating his privileges to allow himself to both raise and authorise payments to his holiday fund.

How did this happen if we're compliant? Perhaps we focussed too narrowly on the specific directions in each piece of legislation, performing a box-ticking exercise on them all (which in practice often means lots and lots of new, labour-intensive processes such as user recertification, dual authority, two-factor authentication, enhanced monitoring, reporting and change control).

Ironically, it is all of this focus on new processes and procedures - implemented with the right intentions: to enforce security policy - that has made us less secure. Because now our technical staff - the experts in the hardware, OS, infrastructure and applications who were previously doing their best to keep ahead of new threats - are now hamstrung with attestations, visits from auditors and recertifying user access rights.

What happened?

Well perhaps the new compliance framework was implemented as a stand-alone instrument, a panacea rather than being used to inform and enhance existing standards and processes. Perhaps not enough thought was given to the extra work involved, or in developing systems and software to enable the new processes, ensuring they have minimal impact on productivity. Perhaps we didn't recognise the things we were already doing that were contributing to compliance, and building on these. Perhaps we saw Compliance as a "New Thing" and sought to implement it as such. In short, we sought compliance for its own sake, and thought that compliance would bring us security. And perhaps we hastened to become compliant with a single piece of legislation such as SOX but didn't build a framework scalable or flexible enough to absorb further controls and threats. And we relied on auditors with little technical knowledge to tell us when we had got it wrong, and their technology-agnostic box-ticking failed us.

We need a new approach to compliance. It's the old approach but better. We need to go back to basics and take a proper technical approach to security. We need to identify and tackle all existing threats against all of our components whether hardware, OS, infrastructure, application or web service(which incidentally needs a sound approach to configuration and change management that should include automated discovery) and a means of identifying and tackling new and emerging threats. We need to let our technical guys have greater input to the process and encourage and enable them to raise security issues and resolve them. And we need to bring back the technical audits.

We need to revisit our Security Policy, ensure it supports all of our security and compliance goals, and then use this to inform lower level documents including standards, baselines, guidelines and procedures so they all hang together. Then we need to implement rigorously, allowing our technical experts to decide what controls are needed to achieve each particular policy objective. And we need to remember to lock in compliance, with as many automated detective and corrective controls as we can - thus achieving Continuous Controls Management at the same time.

To give you a flavour of what I'm talking about, consider RACF. A typical (abriged) SOX control might require that "privileged users are kept to a minimum" and another might say "privileged user activity should be reviewed". Typically, well-known RACF privileges such as SPECIAL would be well covered by this control. The control objective, control details, processes and procedures adopted to implement this control would be comprehensive for SPECIAL users. Evidence is collected and preserved showing that SPECIAL users are well controlled.

Enacting a self-fulfilling prophesy then, SOX auditors come in and report compliance, but only because we are doing what we said we would do and protect SPECIAL users. The SOX auditor will not verify that controlling SPECIAL users is sufficient to achieve the SOX control objective of curbing "privileged users".

In our practical example, our Software Support programmer exploits a lesser-known privilege, say SURROGAT authority to a second SPECIAL user, UID(0) or UPDATE authority to a privileged user's EXEC or HOME library where he plants code (somewhat like a Trojan attack on z). These are all esoteric privileges which generally are not well controlled in a System z environment. But they are privileges nonetheless.

Staying with System z for a moment, we can avoid this situation if we let the RACF Admins and z/OS Sysprogs dictate the controls required. The true vulnerabilities of the system should be tackled, the real threats deterred and the actual risks reduced.

Then we provide evidence upwards, with our hierarchy of documents and a decent control framework we can determine which technical controls contribute to which higher control objectives, and therefore we can demonstrate compliance with each standard, baseline or policy as necessary. If we do it right we can secure once, comply with many.

In short, top-down imposed compliance has not made us more secure. Only a bottom-up approach - informed by the policy but driven by the technology - will work.

We need to Secure for Compliance, not Comply for Security.