Mitigating security issues in a mainframe environment remains a hot topic. Mainframe security isn’t new or unique; we’ve all benefited greatly from the relative safety and security inherent in the mainframe architecture. Once it’s set up, we can almost stop worrying altogether, but where does a new installation start? How can they lock down the mainframe and protect the corporate jewels? Detailed answers to those questions could fill volumes, but the path to security nirvana can be easier to follow if you adopt the four “baby steps” to compliance outlined here.
A mainframe is a powerful tool, easily adapted to any task, with several control points or boundaries, each of which can provide a level of control over various aspects of security (including internal, external, local, remote, physical, and application security). The problem is that this exceptional flexibility introduces additional complexity and a need to research, study, plan, and implement the capabilities carefully to maximize them.
Not every organization is required, by law or corporate mandate, to undergo an annual audit, nor will every organization be required to submit to a security assessment or audit. Nevertheless, you should treat every IT installation as though a security audit is required. Establish a big enterprise mentality toward security, regardless of the size, complexity, or ultimate use of your mainframe system.
Even if your mainframe is used strictly for development or testing, can you really afford to lose data or spend time reconstituting the environment if a breach occurs? We all know the benefits of taking frequent backups and testing the restoration process to ensure the disaster recovery mode of operation actually works, but we should also embrace the philosophy of tight security guidelines for every system. Once you get into the habit of locking down all the mainframe resources, you’ll find the exploitable holes begin to disappear.
You can view the mainframe environment from the local perspective, considering the hardware complex in the data center, and in that view, from the outside in. While the examples provided here are z/OS-centric, there are equivalents in z/VM and z/VSE, and all environments will benefit from these guidelines.
When an external audit team arrives to perform a security assessment, they’ll start with the easiest items to identify and investigate—areas where mistakes often occur, including ones that are sometimes the easiest to disregard. Too often, security controls create an environment that’s more difficult to use or navigate. Too many roadblocks can create frustration, aggravation and eventually contempt, but they’re required if we’re to take back control and deflect the probing investigations that seem about as invasive as today’s airline passenger screenings.
Security is an ongoing activity. Once started, it’s never stopped; it’s only enhanced and updated. It’s obligatory for every mainframe shop, regardless of size, but the process doesn’t need to be overwhelming. You can start with small, simple implementation activities, and gradually adopt the enterprise security models recommended by the National Institute of Standards & Technology (NIST; learn more at www.nist.gov).
You don’t need to have everything set up and in place on day one; you can gradually develop and implement. The important thing is to establish policies and procedures, the base foundation, and do a little bit each month. Eventually, the process will be complete and management will appreciate the initiative as you help solve important security problems.
Baby Steps to Compliance
Here are four baby steps you can take and considerations for ensuring your systems are complaint before an audit:
Step 1: Start at the first boundary for the mainframe: the hardware configuration. The Input/Output Configuration Data Set (IOCDS) configuration file associates various hardware components with specific LPARs. A component can be a candidate to an LPAR, meaning it’s defined to the LPAR but not necessarily connected to that LPAR software configuration. To be usable by an LPAR, it must be accessible, meaning it’s defined in the I/O Definition File (IODF, the software configuration) and IOCDS. A device that’s in the IOCDS for an LPAR but not defined in the IODF for the LPAR isn’t accessible. This provides the logical first line of defense for security assessment review. A non-accessible device is less vulnerable to exploitation.