Information Security in the Real World. Confidentiality, Availability, Integrity, Practicality.

Thursday, 24 June 2010

Is there a Mainframe Skills Shortage?

I like Joe Clabby. He tells it like it is. He has responded robustly a number of times now to Gartner advice to move off the mainframe to more "modern platforms". His latest such article is here.

However I think the truth lies between Gartner's doom and gloom predictions and Clabby's upbeat "you've never had it so good" optimism. Don't be under any illusion, decades of in depth knowledge of mainframe systems is going to leave your organisation over the next few years. But where Gartner gets it wrong is their insistence that the solution lies in migrating off the mainframe. They have used that phrase "more modern platfom" many times in recent years and this is starting to look like staggering ignorance of what IBM have been doing with System z for ten years.

There's no need to move off System z for modernity. IBM have brought modernity to System z. You want management GUIs? Check out the Tivoli automation range. You want a visual developer platform? Rational Developer for z (RDz). You want to run Java, C and C++? No problem. You want to consolidate your racks and racks of servers? Virtualise them? z/VM is the worlds most mature hypervisor, add SLES or RedHat Linux for up to 1500 servers in a 30kW box 10 feet square.

But I do think now is the time to modernise your mainframe. To streamline and automate the maintenance and management of the infrastructure. The product set has never been richer and I recommend you take a look. The greybeards will go soon, and while there are a new generation of System z afficionados leaving college as we speak, don't make them suffer needlessly. Enable them to be productive and creative. Simplify, streamline and automate with IBM Software.

Tuesday, 15 June 2010

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.