Print Email

An ‘A’ Takes Effort

Proper preparation can improve the audit process—and its results

1/16/2013 12:01:01 AM | For decades, mainframes—from their beginning, “grownup” computers—have provided various forms of system management data. Their OSs (z/OS, z/VM, z/VSE, z/TPF, Linux for System z) reliably and comprehensively report performance, event, security, accounting and problem information. And even though each OS does this differently, based on its evolutionary history and overall orientation—across systems and data, abundant mainframe resources enable planning, operation, budgeting and other necessary aspects of enterprise operation.

But as rich as this material is, it doesn’t address higher-level issues, such as regulatory compliance, industry reporting requirements and security/integrity. Enter system auditors—whether internal, service providers, standards bodies or government.

Of course, many people didn’t enjoy getting school report cards. And in some ways, enduring IT auditor evaluations is no more fun than classroom grading, and can be positively irritating. But just as report cards gave valuable insights into academic progress and effort needed, audit reports benchmark critical installation issues, such as security. And while a flawless audit is only one measure of site quality, red flags are much less painful than widely publicized system breaches, data theft or IT failures.

When facing an audit—whether your first or a routine event—learn what’s being audited. Whether you’ll be measured against corporate requirements (e.g., security), government/regulatory compliance, industry best practices or a formal standards organization’s checklist, review documents auditors will use before they arrive. That will avoid surprises and reduce “gotcha” moments. And you’ll prepare better for discussions of where audit standards might defy common sense or reality.

For example, one site was told to remove userid Games from the system. The fact that it was a standard part of the SUSE Linux distro—and would be restored if deleted—wasn’t convincing for an auditor. But when he couldn’t cite documentation prohibiting the account, he dropped the matter. At another installation, departing employees were required to “return” CMS minidisks assigned to them, like overdue library books.

Corporate policies can also be an issue, especially when they’re too general, specifying OS-dependent rules across multiple environments. So it’s worth working with auditors—and audit requirement authors—to craft requirements and procedures that both meet organizational goals, and fit specific computing platforms and associated applications.

Federal and Standards Organization Compliance
Federal data centers are measured against Federal Information Security Management Act (FISMA) standards, which also might apply to other government and contractor installations. Unfortunately, these requirements can be generic in nature, and where they are specific, they often apply only to Windows environments.

Obviously, mainframes don’t need real-time or periodic-scan protection from malware, email checking for Trojans, or logging off already-locked terminal sessions. And it’s wrong flagging as unused userids that are validated as functional credentials for HTTP/POP/etc. sessions without logging on.

So FISMA requirements, specific audit test cases and your auditors may not be mainframe-savvy. Accordingly, you might spend much of the audit time (sometimes measured in months) making requirements and test cases mainframe-meaningful, and educating auditors about mainframe architecture. For example, creating “last authenticated” userid records can notify users when they are about to be suspended, locking their accounts if they don’t exercise their credentials (with notification, of course), and ultimately deleting them after FISMA's prescribed interval. At first use—perhaps with local coding—this might greatly reduce system director size while bringing user registrations into FISMA requirements compliance.

Another set of metrics is the International Standards Organization (ISO) 9000 family of standards. Though described by some as a minimal-attainment “Good Housekeeping seal of approval,” they’re widely used. Evaluation is typically done by an external agency or auditor, with guidance through systems and applications from a local staffer. Because these standards are published and updated, and you’ll know in advance that an audit is coming, prepare appropriate reports and documentation and address issues that will be reported.

Recognize that policies and standards can be overly bureaucratic, nit-picking and not useful or relevant for mainframes. They might defy common sense or even physics (e.g., some requirements for sanitizing magnetic media). But they’re real and often mandatory, so it’s best to accommodate them and apply their intent along with their wording. Modern technology—hardware features, utility programs—can provide compliance/reporting tools satisfying requirements.

You might encounter different sorts of people with the “audit” label. Subject matter experts (SMEs) determine and document best practices; auditors document current practices and deviations; and compliance officers enforce compliance. A specialized SME is a qualified security assessor (QSA), certified by the Payment Card Industry (PCI) Security Standards Council to assess compliance with PCI’s Data Security Standard. You’ll have different conversations with each; so don’t argue substantive matters with someone who is simply using a compliance checklist.

Auditors are as good (or bad) as their training and experience. So don’t expect a recent graduate—or a Windows-only expert—to fully grasp mainframe intricacies and nuances. Learning your auditor’s orientation can guide your interactions and establish the level of technical detail you’ll discuss. A naïve auditor can be good or bad news. If you’re accepted as the SME and a partner in achieving a successful audit, that’s great. But beware someone understanding neither questions asked nor answers received, and quibbling over mainframe-context answers not matching a rigid mental template.

Ideally, of course, auditors are familiar with the systems they’re auditing. If not, it’s useful to explain your systems and applications at a high level, then refine details to clarify configuration and operational specifics. They might appreciate understanding mainframes to a deeper degree than black-box Windows systems, and being able to do a more meaningful evaluation than from a canned script. Or, however, they might be stubborn and demand RACF data when another security system is used, or insist that all PTFs be applied within 30 days of availability. In such cases, cite authoritative sources supporting the mainframe environment along with recognized best practices.

When strange issues arise (whether encrypted data is really encrypted, risks of residual data, how to remove required maintenance tools) be patient and remember how mysterious and intimidating a mainframe can be to someone who hasn’t seen or used one.

Reminders and Tips
Consider the following to help achieve a successful audit:

• Don’t take inappropriate shortcuts just because you can. One of the worst—and all too common—offenses is using production data for testing. Easily detected, this especially concerns health, financial, personally identifiable information (PII) and much government-stored data.

• Anticipate auditor unfamiliarity with mainframes (e.g., expecting or requiring anti-virus software) or applying basic z/OS concepts to other systems where they’re meaningless.

• Watch for one-size-fits-all audit requirements and couch them in mainframe contexts.

• Answer questions directly and to the point with minimum added information/explanation. Don’t let being helpful or showing off open the lid of Pandora’s Box.

• Keep cool—no matter how insignificant (or seemingly ignorant) auditors’ requests seems, they believe they’re performing a valuable service. It’s their job, so don’t make it adversarial.

• Audit veterans suggest letting auditors find something to report, and reaching joint conclusions with them. They’ll be happier that way than filing empty findings and you’ll be seen as cooperative. Similarly, don’t say you told them so—even if you did—because that might not reflect well in their report.

• Use audits to impose/enforce useful policies. For example, a formal requirement to eliminate non-current userids can mandate useful notification from HR of employee terminations and allow system directory cleanup.

• After technology/management/auditor discussion of audit results, document agreed-upon resolutions in writing with signatures. Avoid verbal-only conclusions, fuzzy results or moving-target discussions.

• Remember that audits aren’t just a chore to finish, and auditors aren’t the enemy. A good audit can identify and resolve real issues in need of addressing; audits and auditors can facilitate running quality mainframe services.

Finally, when all else fails, think of the old joke told about many professions: If you ask three auditors the same question you’ll get three different answers. Many personal opinions are sold as gospel in the mainframe world (so ensure your opinions are fact-based).

Gabe Goldberg has developed, worked with and written about technology for decades. He can be contacted at

Please sign in to comment.

Sign In

Join Now!
Learn, Collaborate and Share

Learn, Collaborate and Share

Welcome to the Destination z community site, which offers a one-stop shop for everything related to IBM System z.

Read more »

The People’s Group

The People’s Group

SHARE attributes 60 years of success to its members and looks to the event in August.

Read more »