File Integrity Monitoring Comes to IBM i

November 13, 2012 Alex Woodie

Keeping a close eye on your IBM i server, including its configuration files, database files, and user activities, isn’t just a good idea. In some cases, it may be the law. Depending on which industry you work in and whether you work for a public company, file integrity monitoring, or FIM, may be in your future. Here are two tools that may fit the bill for your newfound FIM needs.

Townsend Security unveiled FIM functionality earlier this year in Alliance LogAgent, an IBM i tool that monitors various journals and logs for evidence of unauthorized changes, and then translates those records into industry standard formats. Although it didn’t announce the new field-level database monitoring capability as “file integrity monitoring” at the time, Townsend has started using the term, which is expected to become more widespread.

In a recent podcast, Townsend Security founder and CEO Patrick Townsend explained the significance of FIM, and where it fits into the overall security program at IBM i shops. In particular, Townsend says his FIM solution will provide an additional layer of protection–above and beyond the security capabilities of the IBM i OS itself–for three areas in particular, including configuration files, application files, and the data.

“The IBM i [OS] has system values that are basic core security configuration values that should be monitored,” Townsend says. “IBM gives us the ability to capture configuration changes into the security audit journal on IBM i. Customers should first enable logging of those change to the QAUDJRN, security journal, and capture those in a log collection server or in a SIEM solution.”

The next area that IBM i shops should monitor are the application-specific configuration files. “Every commercial app has its own set of configurations that control who can access different functions and these should be monitored, too,” he says. “If you’re a JD Edwards OneWorld user, there are configuration files that define which users can access which function within that very common ERP application.”

The third area where FIN can provide security coverage are the database files that contain sensitive information or personally identifiable information (PII). “We all have sensitive data in files within IBM i–Social Security numbers, credit card numbers, and email addresses, that should be subject to monitoring also,” he says. “You should know who accesses those files. You’ll want to know if a value has been changed, if a new option has been enabled for a particular user.”

Townsend says IBM i shops would do well to drop the attitude that the platform is inherently secure, and do the hard work that’s necessary to achieve actual security. “I know for a fact that we’ve helped customers deal with breaches on the IBM i platform,” he says. “We should not be thinking that the IBM i is immune or somehow not going to experience these sort of breaches. They do and they will in the future.”

ALL Out Security

Another vendor selling FIM tools is ALL Out Security, a security software and consulting company that comes out of the JD Edwards world. The company recently acquired a product called TRACE from Ategrity Solutions that provides field-level monitoring of database changes, user activity monitoring, and reporting.

When it bought the product, TRACE was geared specifically toward JD Edwards World, and to work with JDE World files and user accounts. But ALL Out Security realized the product could have broader appeal in the wider IBM i world, so it did the work to turn it into a generic IBM i security tool and released it to the market last year .

Since that initial launch, ALL Out Security has bolstered the product, and widened its distribution. TRACE is now used by more than 30 companies, ranging from large pharmaceutical companies to smaller businesses. Not all of the customers are in highly regulated industries, but all of them understand the need to closely watch data on the IBM i server.

“It’s all about prevention. It’s all about applying controls within your application in order to stop people from doing things that shouldn’t be done,” ALL Out Security co-founder Richard Belton said in a Webcast last week.

TRACE is helpful for tracking two types of activity: potentially fraudulent ones, and purely stupid ones. When TRACE is being used to monitor a file (via QAUDJRN or database triggers), it will automatically track all adds, updates, and deletions of the file, and keep an encrypted copy of the transaction that includes before and after images.

The capability to watch specific files for activity by unauthorized users is clearly beneficial for stopping crimes, such as by gifting yourself a pay raise by changing the salary master. A clever IBM i user could conceivably do this, and cover his tracks to boot.

There are also cases where TRACE can keep a helpful eye on the less-gifted or new user who unknowingly stumbles into DB2/400’s nether regions. “It’s useful in new application rollouts and upgrades because it enables you to see what’s going on, if people are making mistakes and screwing something up in the database,” Belton says. “It can be very difficult to go back and make the correction. What you inevitably have to do is have technical people bypassing your conventional controls to fix the database itself.”

That’s another area of use for TRACE: documenting deviations from the separation of duty (SoD) provisions of regulations such as Sarbanes-Oxley. Knowledgeable users can fire up DFU or DBU, or use straight SQL, to get a lot of work done quickly. But these tools can cut both ways, and TRACE can provide the documentation to show auditors that a process was followed.