The President of the United States announced early in his term plans to develop a comprehensive, universal healthcare system. This program will require highly sensitive records to be stored on massive computers. Essentially, these records will be a “DNA footprint” for millions of Americans. Security for these records shouldn’t be an afterthought, and will require vigilant, proactive monitoring, regardless of the host operating system.
The records are required to be protected according to the Federal Information Security Management Act of 2008 (FISMA, also referred to as U.S. Senate Bill S.3474). FISMA mandates that “the underlying framework that information systems and assets rely on in processing, transmitting, receiving, or storing information electronically” have adequate security “commensurate with the risk and magnitude of harm from loss, misuse, or unauthorized access to or modification of information.”
Web connections to data residing on the mainframe DB2 platform through z/OS Web Services, CICS, and Time- Sharing Option (TSO) have added functionality to legacy processing and brought transaction processing to new levels. It also has introduced a new perception of vulnerability. Mainframe security administrators sometimes view it as opening up the mainframe to “intruders.”
The “bad guys” are finding new, inventive ways to obtain corporate and personal information and disrupt a company’s business. A recent incident occurred when someone held the State of Virginia’s medical records hostage and demanded a $10 million payment. A May 7, 2009, Fox News report (www.foxnews. com/story/0,2933,519187,00.html) indicated that Virginia officials acknowledged a security breach, but one official added that the state was “satisfied that all data was properly backed up and that these backup files have been secured.”
Many financial, healthcare, and pharmaceutical companies keep their vital records on DB2 and other databases residing on the IBM z/OS mainframe platform. According to the June/July 2008 z/Journal article, “Data Warehousing With DB2 for z/OS … Again!!,” by Willie Favero, all the top-25 worldwide banks, 23 of the top-25 U.S. retailers, and nine of the top-10 global life or health insurance providers all run on DB2 for z/OS. Government interests in these companies will lead to the next wave of exchange of information among them, and it’s expected that private industries sharing database information with the government will soon have to comply with FISMA guidelines.
But regardless of the industry and whether or not they must comply with FISMA regulations, every company is at risk of losing information. Security isn’t always the highest priority for a company until it’s the lead story on the evening news or in The Wall Street Journal and top company officials are asked to testify before Congress.
Commonly used security products for z/OS DB2 are the first levels of defense, and these products either allow or deny a user access to a resource. Unlike UNIX and other operating systems security, it’s a simple yes or no decision. If security is denied, a violation event will be recorded on the security log files and, usually, a message will be issued to the primary console. The event may go unnoticed until the system administrator runs a violation report in response to an incident.
DB2 logs activity by writing System Management Facility (SMF) records. The DB2 SMF records contain information about many different events occurring in the system. The level of granularity depends on DB2 audit trace configurations at the individual table level. SMF records provide data useful for investigating security events, and if used with other resources, can help investigate possible attacks and breaches for incident response, auditing, and compliance. SMF records are in binary format and aren’t readable by a plain text editor, making online viewing and interpretation almost impossible.
Separation of duties is a foundational component of the Sarbanes-Oxley Act of 2002 (SOX), but the DBA and system analyst are expected to start and stop DB2 audit traces when preparing information for analysis by the internal corporate auditing and security teams. Having the same person monitoring security and setting up security records for analysis is a SOX violation.