Privileged Users and the Mainframe

2 Pages

There’s always been debate in the security community about whether the largest threat is internal or external. It appears auditors and regulators have cast their vote: The insider threat has become the hot topic of audits. The threat that’s most concerning is that of the privileged user, and their (usually) unintentional but harmful mistakes. When you consider this threat and the auditors’ focus in the context of a mainframe-specific challenge, you’ll realize why you’ve been so busy lately. With great power comes great responsibility. Do you know who’s being responsible on your mainframe? Can you not afford to find out? You must. Here’s how.

The Privileged User Problem

Study after study confirms that insiders can cause more damage than external hackers. A recent Insider Threat Survey, conducted by the U.S. Secret Service and CERT, confirms that the insider threat usually comes from technical or privileged users.

What scenarios make a Chief Information Security Officer (CISCO) most nervous? In discussions with compliance practitioners, these situations, mixing malicious acts with damaging mistakes, are frequently mentioned:

  • Sabotage of information or systems: This category includes physical destruction of network cabling, computing devices, or disabling of electrical or other environmental control.
  • Theft of information or computing assets: This category includes theft of anything from digitally stored information, such as customer credit card information, critical financial data, internal product engineering plans, and physical devices.
  • Introduction of bad code: This may include time bombs or logic bombs.
  • Viruses: While the most significant internal threat is the “ignorant” employee who double-clicks on the email attachment, activating a virus, results from numerous “insider attacks,” surveys show that viruses may be intentionally exploited by hostile employees.
  • Installation of unauthorized software or hardware: Common attacks include the installation of Trojans by privileged users.
  • Manipulation of protocol design flaws: Protocol weaknesses in TCP/IP can result in a virtual treasure trove of problems, including DNS spoofing, TCP sequence, hijacked sessions and authentication session/transaction replay, denial of service, and TCP_SYN flooding.
  • Manipulation of operating system design flaws: Commonly used operating systems, such as Windows and Linux, weren’t designed to be highly secure. Privileged users have easy access to information regarding which vulnerabilities exist and which have been patched. With read/write and administrative access, privileged users can manipulate these design flaws and exercise native vulnerabilities.
  • Social engineering: Attackers may use email, Instant Messaging (IM) or telephones to impersonate or pretext employees and administrators to gain usernames, passwords, or escalated privileges to information or systems, and execute Trojan horse programs.

The message here isn’t that privileged users are bad. Absolute power does not, in this case, corrupt absolutely. Privileged users are generally good, but have enough power to make big mistakes. In other words, with great power comes great responsibility.

As ISO17799 points out, “Inappropriate use of system administration privileges (any feature or facility of an information system that enables the user to override system or application controls) can be a major contributory factor to the failures or breaches of systems.”

Auditors and regulators are concerned, too. In one Sarbanes-Oxley (SOX) audit after another, the message is clear: Get control over your privileged users.

The Mainframe Challenge The old, reliable mainframe (a.k.a. Enterprise Server) is alive and kicking, but the mainframe provides a unique privileged user challenge. One of the cost-saving aspects of z/OS systems— the high “users to technicians ratio”— opens up new challenges for data center managers. Additional efficiency improvements in security management have allowed data center management to reduce the size of security management teams down to the level where conventional separation of duties is no longer feasible. Today, each staff member wears multiple hats, even if that violates good change management and audit policy. Smaller shops may run with one security administrator and use the systems programmer as backup and technical consultant. Even in large mainframe installations, there’s typically only one security administrator who really understands z/OS, the legacy applications, and how these are defined to the security product.

In such installations, the lead security administrator may have tasks ranging from:

  • Defining the security structure for new applications
  • Granting authority
  • Cleaning up obsolete structures
  • Keeping house when the help desk can’t shoulder the load
  • Identifying data exposures
  • Fixing misconfigured parameters
  • Investigating and escalating incidents.

Since the lead security administrator is the only person who understands the ins and outs, he becomes an untraceable, self-supervising agent. In a typical environment, he would have the ability to change any security rule or parameter, and simultaneously bypass those rules. In a RACF system, he might have system special and operations and might even require the auditor attribute to run some standard reports. In CA-ACF2, he might have the security attribute and bypass rule validation. In Unix, he might need UID(0) to create new home directories. When all these authorities accrue to the same person, you have a Super User.

2 Pages