Monday, May 05, 2008

Security access for programmers

Given all of the recent news stories about consumer information security problems, programmer access control is likely to be more critical in many companies than ever before.

Back in the 90s, a lot of programmers would claim that the need to request access to update production files was a pain. The thought was, all programmers should be bonded, and that it wouldn’t be necessary. But when you’re responsible for the integrity of a system for years, you want all of the automated protection you can get from accidental “Manchurian” involvement in some sort of corruption or scandal. So, in retrospect, I welcome the rapid development of products like Top Secret and RACF starting in the 80s, and the automated source control of packages like Endeavor and ChangeMan (the rules have to be followed to guarantee source-load module integrity).

Now, basing QA data on real data can be a security problem, as can keeping paper records of the tests or runs (something we all had to collect for Y2K verification and storage in “Iron Mountain”).

I am aware of a situation 15 or so years ago where even a regular applications programmer was given responsibility for setting the security access for other programmers in a Vantage system. The programmer did not do this and was fired. But this was not the way security in any shop should ever have been handled.

No comments: