Tuesday, September 09, 2008

"War and remembrance": ALC coding and security vulnerabilities of the past

My goodness, we have come so far in basic I.T. production environment security since the mid 1980s. Particularly in areas where security vulnerability lies inside source code. Even on the mainframe, IBM assembler, for example, has always had the ability to change updating options and even dataset names from deep within the code with various macros and esoteric techniques (some involving the reflexive “execute” instruction). For example, as recently as 1995 I did a project to increment dynamically the dataset names of tapes to be sent to customers from within a salary deduction billing program, with a special step in assembler to do this.

Back in 1985 I worked on a project to consolidate billing across credit bureaus in an assembler system (MVS IBM assembler, running on Amdahl) of batch programs written originally for DOS and running in MVS under DUO. The DUO option was an execution parameter in the EXEC statement in the JCL.

We had bureau and member masters, and the monthly billing programs would update the member masters (especially the past dues buckets for billing). In those days, when we tested batch, there was no RACF or Top Secret yet. The assignment of the correct file (the test copy of a production file) was embedded in a catalogued proc. Test from production datasets were usually distinguished by a leading qualifier. I suppose as long as it was never touched or overridden, the real production master could not be updated. But then, no security protected the production sets from programmers, either in batch or possibly from TOS commands (or their equivalent) issued from "Tube City." But if a major master file were corrupted, no one would find out until “end of month” ran.

But what’s “worse” is that, in a DUO environment, we also had an “UPSI” parameter. The macros in the DOS program interrogated the UPSI parameter and skilled statements (by branching around them in some parameterized fashion) and if the parm was set to “NOUPSI” it would not update. Some programmers had run with the real master file but with NOUPSI. But, they were counting on good faith that no coding change could have left the file vulnerable to update.

I have some other “fine” memories of ALC programming. One time, all the quarterly (and less frequent) fixed charges failed to post because a programmer had inserted a byte in storage that upset instructions that depended on half-word or fullword alignment to work. I remember trapping that at 7 AM with some kind of snap, and fixing easily with a “DS 0F” command. But on a Saturday morning in January 1986 we had to rerun the statements for about 20 bureaus. It’s a good thing that I hadn’t prepaid any plans that weekend. It was January, after all, after the holidays!

We would soon convert the DUO system to OS, and that itself was a project.

In its day, assembler language on the IBM (or compatible) mainframe was a valued skill. It was an intricate world of its own.

I understand that the IRS still hires assembler programmers through contracting companies, for operations in Merrifield, VA and perhaps elsewhere. But they seem to want experience in very specific engineering applications.

No comments: