Say "System i security" to some administrators, and the first thing they'll inevitably come back to you with is, "Sure, I know what you mean; that's all about controlling access to the System i from those Web-connected PC terminals with terminal emulation software, isn't it?"

And then they'll say something like, "Oh, and let's not forget the system audit journal. Hey, you need a product for reporting on that-I mean, everyone does!"

Well, by now most IT people know that there's a lot more to System i security than that. There are user-profile-management issues, password control and validation schemes, green-screen lock-out requirements, and even products that search your System i for PC viruses!

What doesn't come to mind so quickly, though, is the two unique security-related capabilities that the market has been asking for and that nearly none of the System i security vendors have addressed.

Capture Your Users' Green-Screen Sessions

Suppose that one day-say, six years from today-your auditors are asked to investigate an alleged tampering with someone's credit card data file (or patient record, loan, etc.). And suppose that investigators can more or less pinpoint one or two persons who may have been involved way back then, but one has left the company and the other has been transferred to another position.

To obtain concrete proof that can stand up in court, you'd have to be able to monitor, collect, save, archive, and, at that appropriate time (six years later), search actual user sessions, screen by screen, in order to determine suspected mischievous behavior on the part of your users.

All of us are trying to satisfy our auditors' government-compliance regulations and prove that all possible compliance-dictated requirements are being met. We can no longer whitewash anyone, nor is it advisable to do so if the best interests of our company are to be served.

A case in point is security surveillance, which is an integral part of all regulatory guidelines-from SOX to HIPAA to guidelines designed specifically for financial institutions, credit card companies, etc.

Satisfying compliance requirements has become more realistic than ever by answering to the guidelines spelled out in the Control Objectives for Information and related Technology (COBIT) developed by the U.S.-based IT Governance Institute (ITGI).

So, what then is security surveillance? Turning to COBIT requirement DS5.7, we are offered the following explanation:

"IT security administration should ensure that security activity is logged and any indication of imminent security violation is reported immediately to all who may be concerned, internally and externally, and is acted upon in a timely manner."

This definition references "security activity," so it should be obvious that your users come under this definition. But what are "imminent security violations," and at what point do they become truly imminent? It would seem more than appropriate to prepare for the eventuality that these security violations could become apparent and open to investigation sometime in the unforeseeable future.

OK, now that the problem is clear, how do you prepare the groundwork today for what could be an all-too-real auditing requirement? The best way to prepare for this possibility is to simply capture user screens. The decision about what to capture would be based on what is right for your business. For one company, it might be all screens; for another, what to capture might be based upon particular applications, user location, or responsibility.

In case you're wondering, capturing and saving these screens isn't very resource-intensive, unless you're particularly worried about disk space. But even then, think about it: A perfectly normal user won't press the Enter key more than two times a minute, 120 times an hour, almost 1,000 times a day. So storing about 2 megabytes of data per day (actually a lot less!) per user is certainly not an exorbitant price to pay for the attendant benefits.

Once you have stored a user's session and archived it, you can always go back whenever you need to, or perhaps on a "spot check" basis to scan for a credit card number, someone's name or address, a patient number, or whatever it is that you suspect has been fiddled with. The incriminating evidence is clearly available!

But taking this one step further, why wait until there's a suspicious activity being reported? Why not begin capturing user screens and then tell your users that their work may be recorded for security reasons (sound familiar)? Wouldn't that simple statement, in and of itself, deter the occasional offender? In most cases, it would, but you never know: Disgruntled employees, employees "on the take," or employees under pressure might put your statement to the test!

Timeline History of Application Changes

Now that you've collected, stored, and archived user green-screen sessions to comply with security surveillance, you still have to contend with COBIT requirement DS5.3, Security of Online Access to Data. As the regulation states, "IT management should implement procedures in line with a security policy that provides access and security controls based on the individual's demonstrated need to view, add, change, and delete data."

Most shops have implemented some kind of "before and after" data auditing capabilities using basic system database journal technology. Unfortunately, this solution requires a relatively high level of expertise, making the use and maintenance of the data, and the possibility of turning the data into usable information, extremely time-consuming and expensive.

But consider the following very real business scenario. Suppose that, in your position as applications manager at a financial institution, you're asked by your frontline clerks for a solution that would provide increased accountability and traceability of all changes made to any mortgage issued by your institution.

Such a solution, based upon currently available mortgage application data, would optimally provide your clerks with a timeline history of all financial, administrative, informational, and other changes made to any particular mortgage provided by your institution, from date of issuance until today.

Chances are, you won't be able to produce a timeline-oriented report overnight. Given the size and scope of today's applications, the challenge of integrating just the right data from many tens of databases is a non-trivial administrative and programming task calling for an investment of significant person years of development, debugging, testing, and implementation.

OK, you may be asking yourself, "Hey, wasn't all this about security? Haven't you strayed from the topic?"

Actually, I haven't, because your auditors, indeed your customers, will not only want to know what changes were made to the loan over time, but also want to insure that all modifications, whether made to financial data or not, were within the limits set by corporate policy or by industry standards. Perhaps your institution's guidelines have been either criminally or unintentionally abused?

Clearly, the capability of producing such a totally new application with the above auditable guidelines becomes of paramount importance to many diverse functional groups at your financial institution. And let's not forget the application's requirements that are always paramount: The application must be quick and inexpensive to implement and maintain, yet allow for diverse levels of investigative capabilities.

The Need for a Total Security Solution

This article has provided just two examples of security-related areas of the System i that have been largely neglected by ISVs. However, as companies define and refine their security requirements and attempt to remain compliant with relevant regulations, they will need to consider implementing end-user oriented security technologies, not just network access and more-or-less standard auditing solutions.

It is the ISV that has developed not only technical security solutions, but also applications-oriented security solutions that should be considered as a total security solution provider.

Eli Spitz is Vice President of Business Development at Raz-Lee Security, a New York-based company providing unique security, optimization and programmer development technologies for the System i environment since 1983. Eli's team has been actively promoting the iSecurity product suite, which encompasses solutions both to the security-related capabilities described in this article as well as to network access and auditing.

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice