A Division of the UNICOM Global Companies
The Software Management Experts
 January 2006 Volume 10, Number 1
Security and Systems Management SpotlightBy Joe Baumgarten, Sales Engineer “Ev’rybody’s talking ’bout Sarbanes-Oxley, HIPAA, COBIT, FDIC, ISO, CFR, PCI, FBI, my, my, my . . .
One of the first items to be flagged by auditors in shops with no Software Configuration Management (SCM) process in place is that too many people have too much authority to the source and objects that make up the production layer of your applications. Programmers and IT managers alike have fought long and hard against corporate Security Officers eliminating, or even restricting, their access to these key resources. “How will I get my job done?” “What about emergencies?” And the ultimate killer is “This will cause my backlog to double!” When my son was a baby, if he had something in his hands that I did not want him to have and I grabbed it away, he cried. However, I learned a trick: if I replaced it with a toy that I did want him to have, he was okay with that. No, I’m not calling your programmers children, but this is the philosophy that TurnOver adopts. Instead of simply telling your developers “you can’t touch this,” tell them “I’ve replaced the way you used to make changes to production code with one that you will find is much easier and much safer.” By shifting the power from the many into the one (TurnOver), you can now use the power of TurnOver to manage access, both into and out of, your production-level objects. At its simplest design, as long as a programmer is in TurnOver, he can do what he needs to do to accomplish his job. If he leaves TurnOver, he cannot. Another hard lesson is that security is not a one-off project. You may spend days, weeks, maybe even months, getting the security of your critical objects set just right. Who owns the files? What profiles have access? How much access? What programs adopt authority? How much authority? For how long? The good news from TurnOver in this battle is that once you have configured your security settings, TurnOver helps you maintain them as developers make changes to the objects. I call this TurnOver’s “if it ain’t broke, don’t fix it” feature. By default, when an object is promoted, TurnOver applies the same ownerships, authorizations, and object attributes to the new object that existed on the old object. The next security measure that TurnOver can implement comes into play as changed objects are returned to the “vault.” When I need to access the contents of my safety deposit box at the bank, I must show my ID and sign the logbook with the date and time. Then two keys are required to open my box: the bank’s key and mine. TurnOver can implement the same protections. First of all, it knows who you are by your profile. Secondly, it uses process-driven automation to log what you are doing in TurnOver into its central database of knowledge. Next, it compares your profile against the authorities that the TurnOver Administrator has given you. It checks that you have the rights to do what you are attempting to do. Finally, with the form approval process, TurnOver ensures that more than one person agrees that running this particular promotion is a good thing for the business. Here are some other security-enhancing features of TurnOver:
  |
If John Lennon were alive today, perhaps he would consider amending his famous song to reflect the plethora of security regulations with which modern businesses must comply. Even if you are not saddled with one of these compliance requirements, chances are good that your company is interested in keeping the source, data, and objects that drive your “bet-the-business” applications secure from accidental or malicious damage. For years, people have turned to TurnOver to help them make their applications more secure without compromising the productivity of their IT staff. Here are a few of the ways this is accomplished. 
Back to Table of Contents
