You know how some scenes stick with you? Early on in my IT career, I learned a valuable lesson while on the job: The person who loses their temper is most likely the person to lose the issue at stake.
This story dates back to the early 1980s when I was working for a regional bank in one of the first positions hired specifically to manage computer security. Until then, no employee had been dedicated to system security at the bank, so the measures that had been implemented were very basic or inconsistent.
[ Pick up a $50 American Express gift cheque if we publish your story: Send it to firstname.lastname@example.org. | Get a dose of workplace shenanigans -- follow Off the Record on Twitter. | For a quick, smart take on the news you'll be talking about, subscribe to the InfoWorld TechBrief newsletter. ]
With a database team and a production team previously established, I initially took over user ID administration from someone in the database group who'd been doing that work on a part-time basis.
Plugging the security holes
As I delved deeper into the issue, I discovered the bank had next to no security on the mainframe's production files. Anyone in the bank who had access to the mainframe's time-sharing system had read-write-purge permissions to all production files. This list included every IT person in the bank, even those who didn't need access to them to do their work.
Amazingly, a few accidental deletions were the only problems they'd had in that time. I drafted a cautious plan to restructure permissions so that programmers could read production files, but could not alter or delete them. Nonprogrammers with time-sharing access would not be allowed to even read production files.
For most functions, programmers only needed to be able to read production files, and the bank already had a process in place if a file had to be updated with a temporary programming change. My plan included a process for them to get management approval when a file required a direct edit.