Article

Does Your Business Trust Its Data?

IBM i
Posted:
August 16, 2016

 

Every day when a report is run or an inquiry is made in an application, the automatic assumption is that the underlying data is accurate and has not been tampered with. But how can you be so sure?

This is one of many important questions that IT professionals are confronted with on a daily basis. How can IT assure management that the integrity of the data being used to make important business decisions has not been compromised?

Integrity with confidentiality and availability stands as one of the pillars of IT security. If one of these pillars were to crumble, your entire security would be compromised. From an IT security viewpoint, Wikipedia refers to ‘data integrity’ as ”maintaining and assuring accuracy and consistency of data over its entire life cycle.”

To improve the trustworthiness of data it is important to have a complete audit trail that allows you to answer the following critical questions:

  • Who made the change?
  • What did they change?
  • How did they change it?
  • When did they change it?
  • Why did they change it?

If you are able to answer these questions confidently then you are in good shape to provide assurance to the business of the integrity of the data and information derived from that data.

It is also important to understand the difference between an application audit trail and a data audit trail. Many applications will provide answers to the critical questions above, however that’s if the change was made using an application. What if the change was made directly at the database level, bypassing the application? In most cases, if the data is manipulated—perhaps with malicious intent—it is done outside of the application altogether using tools such as Data File Utility (DFU), SQL, ODBC/JDBC, MS Excel, etc.

The importance of data integrity is quite apparent in the way it’s been mandated by numerous compliance regulations and frameworks such as:

FDA (FDA 21 CFR Part 11)

Produce complete and accurate, time-stamped records, equivalent to paper records.

PCI DSS

10.2—Implement automated audit trails to reconstruct the following events, for all system components:

10.2.1—All individual user accesses to cardholder data.

COBIT

DS 11—Manage data

DS 11.6—Security Requirements for Data Management

Define and implement policies and procedures to identify and apply security requirements applicable to the receipt, processing, storage, and output of data to meet business objectives, the organization’s security policy, and regulatory requirements.

As much as we dislike audits and compliance initiatives, we should take this compliance push positively as an impetus to implement database monitoring for the greater good of the business.

From an IBM i point of view there are a few options available to track database changes. These include:

Object Auditing

At the basic level you can activate ‘Object Auditing’ in the Security Audit Journal (QAUDJRN) for critical objects (database files) so that you will have an audit trail of the changes. Although this is a good way of tracking changes, you would not get the answer to one of the critical questions we discussed: “What did they change?”. Unfortunately, this method will only record that the object has been changed, not which fields or values were changed.

Database Journaling

By journaling important database files, you can get the answer to the question “What did they change?” because journaling can provide a before and after value for a database change.

Trigger Programs

Another option is to write trigger programs and attach them to the database files so that you can record changes to that file. These programs will ‘fire’ when a change is issued to the database, and the programmer can design the program to record an audit trail.

Although these options are capable of providing an audit trail, there are performance considerations and considerable effort is required to configure and maintain these setups—especially in the case of trigger programs.

It is difficult to get an answer to the last question: “Why did they change it?” This is where Powertech Data Thread comes in handy! Data Thread is capable of prompting the user for an electronic signature so that they provide a reason for the change.

Data Thread is a comprehensive solution for database monitoring, providing answers to all the critical questions.

Data Thread enables:

  • High-performance database monitoring
  • Comprehensive data audit trail and forensics
  • Real-time notifications sent via e-mail
  • Trigger workflows for transaction authorization
  • Electronic signatures and reason descriptions for critical changes

Most businesses have complicated application architectures in which a single data file can be accessed by hundreds of programs. Furthermore, database administrators, programmers, and other IT staff add more complexity when they access data outside of the approved application. Therefore it is imperative that we have the right tools to monitor database changes and maintain a comprehensive audit trail of critical business data.

 

Get Started

Find out how Data Thread can make an immediate difference for your operations. Request a demo to learn more.

Related Products

Related Solutions