Audit Time: How Do Your Source And Objects Match Up?

June 22, 2015 Alex Woodie

When an auditor comes into your IBM i shop, chances are good he will check that processes are in place to control source code. But all too often, your underlying source code will not match up correctly with the program objects that actually run in production, indicating a process problem. A free new tool from Rocket Software called iAudit is designed to help IBM i shops identify this divergence of source code and object before the auditor comes around.

Regulatory audits are once again on the rise. Whereas the Sarbanes-Oxley Act enacted in the wake of the Enron scandal at the turn of the century applied only to public companies, there is scarcely an industry today that is isn’t impacted by some industry regulation. Whether it’s PCI, HIPAA, Basel II, or FDA regulations, audits can be conducted to ensure that companies’ computer systems adhere to certain business processes to prevent data leakage and fraud.

But when it comes to development environments, too many IBM i shops either don’t have the right processes in place to manage their source code, or they make it too easy to circumvent the processes they do have. That’s been the experience of Dan Magid, who’s the managing director of Aldon Labs at Rocket Software.

“We see stuff like this almost every time we go out to a prospect or a new customer where we’re looking at their environment,” Magid tells IT Jungle. “We almost always find situations like this where they have multiple sources for the same object, and they’re not sure which one is the right one, or the object timestamp doesn’t match the source code, or there are missing source members or sources in the wrong library. We find things like that in pretty much every account we go into.”

Rocket recently launched a new product called Integrity Audit (or iAudit for short) that’s aimed at helping IBM i shops figure out if they have these problems. The software, which is free, will automatically scan an IBM i system and identify where the source code and the program objects do not match up. It also analyzes authority levels, which is another thing that auditors look at.

Magid explains how iAudit works: “We’re looking at the object description,” he says. “We’re going to check to see, A.) is the source there and B.) is that the right place for the source. In other words, if you know that that all your source is supposed to be in a library called ‘production source’ and this source code is actually in ‘Dan’s library,’ we’re going to say, ‘Wait a minute, this source is in a place that it shouldn’t be.’ We’re reading what the system is recording, where things should be, and where they are, and then identifying, is that correct?”

It’s not uncommon to find IBM i shops with hundreds of thousands of objects in production. Keeping track of the source code for these objects is no trivial matter.

There are many reasons why source code and program objects don’t match up. “People are in a hurry, or they go around the system, or the system gives them the ability to add their own programs, to do things in their own program that aren’t appropriate,” Magid says. “Maybe I moved a bunch of source code and ran a builder, but I don’t create everything correctly. Or I create a development library because I’m fixing production bug. . . but never moved the source code to the production source library. Or somebody accidentally deletes the source. There’s just a lot of ways this can happen.”

The problem is, bad programming hygiene looks a lot like malicious activity to an auditor. While an overworked programmer may have made an innocent mistake by not cleaning up old source code after fixing a bug–thus creating an out-of-sync condition between the source code and the production objects–the auditor can’t differentiate that from the activities of a malicious programmer who’s looking to commit fraud against his employer.

The auditors can’t divine the intent of the people who have access to the systems. All they can see is what the system tells them. And if the system shows them that things are out of whack–well, it doesn’t matter whether it was caused by an innocent mistake by a harried programmer or caused by an evil mastermind bent on bilking the company. It’s a problem.

“You want to know exactly what’s running, and the only way that you can see what’s in that object is by looking at the source code.” Magid says. “They want to understand that you have control over what’s in production, and anything that would be out of sync would makes them nervous. Why is it that you don’t know where the source for this object is? Why do you have the wrong source? If you have that, that means you have a process problem that puts you at risk. That’s what they’re going to be nervous about–they’re going to be nervous that you’re production environment is not as you think it is.”

The reports generated by iAudit won’t totally get you off the hook with an auditor, but it will go far in proving to the auditor that you do have control over your system–provided, of course, that you actually do have control. If your system is a mess, you need to address that. Rocket, of course, makes money by selling the Aldon application lifecycle management (ALM) software that automates the handling of source code.

“We have a very strong reputation in the IBM i world for auditability, so I think [the iAudit reports] lends credence to it,” Magid says. “They’re probably going to want to do some checking of their own. But to be able to hand them this report and say we ran this thing from Rocket Aldon and it came up with this is a very big step up in the audit process.”

Identifying any inconsistencies between source code and program objects compiled by the IBM i operating system is just the start of the change management journey. And iAudit can’t tell you everything you might want to know about the relationships between source and objects.

“When you run iAudit, it can tell if you if you have these problems,” Magid says. “But it doesn’t know exactly what should be in production. Maybe you have source and object that match up just fine, but that object itself shouldn’t be in production at all. Because we don’t know what’s supposed to be in production, we can’t tell you if what is in production is supposed to be there. We can only tell you have these mismatched things going on. If you have our ALM system installed, then we know exactly what’s supposed to be in development, test, and production and we can tell you is your system in the exact state it’s supposed to be in.”

All of the ALM and security tool vendors are reporting an uptick in compliance audits. While it doesn’t appear to be as painful as the first wave of audits that IBM i shops had to contend with following SOX, it does appear that it’s impacting a wider number of shops this time. Products like iAudit can save a lot of time and grief by identifying problems that the auditor is going to see eventually.

You can download iAudit at www.rocketsoftware.com/iaudit.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search