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.
Posts
