Auditing Mainframe Database Data Access and Modification

Tracking who did what to which piece of data, and when they did it, is important because there are many threats to data security. External agents trying to compromise security and access company data are rightly viewed as a threat to security. But industry studies have shown that many security threats are internal – within an organization.

Some organizations are extra vigilant in tightening down access to intruders from outside the organization but forget about the security threat that comes from a disgruntled or malevolent current or ex-employee that has valid access to the mainframe. Auditing is the best way to find an unauthorized access emanating from an authorized user.

Tactics for Compliance

So how can financial institutions ensure they are in compliance with industry and governmental regulations… and protect their data against threats both internal and external? Data access auditing, sometimes simply called database auditing, can track the use of database resources and authority.

Each audited database operation produces an audit trail of information. The audit trail will show which database objects were impacted, what the operation was, who performed the operation, and when it occurred. This comprehensive audit trail of database operations produced can be maintained over time to show in-depth analysis of access and modification patterns against data in the mainframe.

But as with any technology, there are multiple considerations to understand and deliberate upon before implementation.  The first step is to make a list of the regulations to be complied with, based on the types of data your institution holds. After you have created a compliance roadmap, determine what level of data access auditing is required, with input from an internal auditing group. A good database access auditing solution should answer at least the following questions:

  1. Who accessed the data?
  2. At what date and time was the access?
  3. What program or client software was used to access the data?
  4. From what location was the request issued?
  5. What command was issued to access the data?
  6. Was the request successful; and if so, how many rows of data were retrieved?
  7. If the request was a modification, what data was changed? (A before and after image of the change should be accessible)

When choosing a solution, consider one that delivers pre-canned compliance reports. For example, if you are looking to comply with PCI DSS, a database auditing solution that delivers out-of-the-box PCI reports will shorten your implementation timeline.

Furthermore, the method by which the audit trail is produced is a significant consideration. This is especially important for mainframe data, as we will soon see.

There are basically four options for auditing database access and modification:

  1. deploying native DBMS traces
  2. scanning database transaction logs
  3. sniffing network traffic
  4. tapping requests at the source.

Of these methods, only the last provides 100% visibility into database activities without becoming a performance drain. Native  traces can be performance prohibitive and often times do not collect all of the required information needed to show compliance. Scanning transaction logs can capture database changes, but not access (as is required for some regulations, such as HIPAA). Sniffing network traffic works well when all database requests must go across the network (as is common for Linux, Unix and Windows workloads), but what about when the request is all on one box (such as a CICS transaction that access DB2)? The only sure method of gathering all required auditing information, especially for mainframe auditing, is for data access requests (both read and modification) to be tapped at the DBMS level.

There are auditing solutions on the market that deploy all or a combination of these methods so be sure to investigate how auditing is accomplished by any product you are considering before making a purchase decision. For each product, be sure to investigate the methodology being used to ensure its comprehensiveness, performance, and usability.

Synopsis

Ensuring compliance with tedious government and industry regulations is a daunting task. This, along with the growing need to protect databases from the increasing online and internal threats to sensitive data has resulted in business executives being asked to be more personally responsible for the safety of corporate data. Data access auditing solutions can help your organization meet its growing requirements safely and proactively.

About these ads

About craig@craigsmullins.com

I'm a strategist, researcher, and consultant with nearly three decades of experience in all facets of database systems development.
This entry was posted in auditing, compliance, data, Database security, tools. Bookmark the permalink.

2 Responses to Auditing Mainframe Database Data Access and Modification

  1. Pingback: DB2 Hub | Auditing Mainframe Database Data Access and Modification

  2. comptoir quartz says:

    Oh my goodness! Impressive article dude! Many thanks, However
    I am having problems with your RSS. I don’t understand why I am unable to subscribe to
    it. Is there anyone else getting similar RSS issues?
    Anyone that knows the answer will you kindly respond?

    Thanx!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s