Should we share mainframe vulnerabilities? I've been involved in an interesting discussion on LinkedIn recently and I've come to the conclusion that we should. But first let's discuss where we are and how I came to this decision. Security features built into the mainframe are second to none, leading many to claim that it is "unhackable" or at least has "never been hacked". This may be true if we take the term hack to mean externally-originating attacks which exploit code integrity issues in the operating system or infrastructure software. This is traditional hacking, seen very commonly on Windows and requiring strong perimeter defences, regular code patches and malware protection software unknown in the mainframe environment.
However this virtual immunity of the mainframe to external attacks on the code base might have led us into a false sense of security. There is more to security than malware attacks. Increasingly I find on my travels, when auditing mainframes with zSecure, that organisations don't know how to securely configure mainframe security and infrastructure software.
A typical System z security audit reveals a large number of vulnerabilities caused by poor configuration, management or maintenance practices. Excessive privileges, unprotected sensitive libraries or unmanaged "New Workloads" are par for the course. What's most surprising is that these errors could and should have been avoided, as mostly they are against common wisdom; in most cases best practice guidelines, or straightforward configuration instructions in the software have been ignored.
Often these issues could be exploited only by "staff" but we must remember that term is increasingly likely to include contractors, temps and workers for outsourced service providers. Factor in the high likelihood of being able to escalate your own privileges through Social Engineering in most organisations and it's clear that any complacency towards attacks on the mainframe is misplaced.
So what to do? If we limit ourselves to configuration errors - and by that I mean technical weaknesses such as RACF SETROPTS NOPROTECTALL, APF libraries with UACC(UPDATE) or privileged users who execute TSOPROCs from libraries with weak protection - and then we have a straightforward option open to us. Publically document correct configuration for optimum security, of operating system and common infrastructure software. One could reasonably object to this action on the grounds that putting such information in the public domain would be dangerous; that it would assist hackers at least as much as security professionals. However, this would be to assume that the hackers don't already know this stuff or that it is currently hard to find out. In fact as I noted before, I'm talking about common wisdom here, stuff that has already been revealed in IBM's and ISV's documentation, discussed on IBM-MAIN and RACF-L or published in white papers, best practice websites and IBM redbooks. A person with enough skill to mount an attack on one of these vulnerabilities would already know enough or be able to do the research now. Nobody need fear a public collection of vulnerabilities except those who trust deeply in Security through Obscurity, trust which is generally misplaced.
The benefits of enabling System z Security professionals to document, share and discuss common vulnerabilities can only lead to more secure software, while enabling Administrators and Auditors to self-audit and fix their own systems against an authoritative list of common configuration weaknesses can only lead to more secure systems. In turn this will help protect the reputation of System z, cement its position as the most securable platform, and bring us up to speed with other platforms with which System z is increasingly competitive.
And talking of other platforms, shouldn't we take a look at them? What happens in the Windows world, by far the most fertile ground for hackers any time in the last 20 years. Well Microsoft has a huge Security TechCenter which includes a link to "Threats and Countermeasures Guide" for Server 2008 and Vista - a 280-page doorstop that is both a Security Admin's Bible and a Hacker's 101. A new document is published for each new version of Windows, plus software tools to automatically analyse and fix insecure settings. Discussion is welcomed and continues on many forums including some hosted by Microsoft, and new vulnerabilities are published and discussed in places such as the SANS Internet Storm Center.
So we're not breaking new ground here. I feel that a culture of open discussion of mainframe vulnerabilities and countermeasures will be beneficial and is absolutely necessary as the platform becomes more interconnected, the perimeter of System z becomes more blurred and the threats once confined to remote distributed systems creep ever closer.
I propose a Wiki, which unsurprisingly forms the basis of Wikipedia, which could be edited by multiple persons. My favoured location is here on developerWorks, which is an IBM-hosted collaboration platform running on Lotus Connections. It is a rich-content fully-featured platform that gives us all we need to make this a success. To that end I have set up a "zSecurity" wiki here, as a placeholder for now. I welcome your comments.