January 2006 Volume 10, Number 1

Security and Systems Management Spotlight

By Joe Baumgarten, Sales Engineer

“Ev’rybody’s talking ’bout Sarbanes-Oxley, HIPAA, COBIT, FDIC, ISO, CFR, PCI, FBI, my, my, my . . .
All we are saying is, give peace a chance.”

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.

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:

• Audit Control — If an item has changed outside of TurnOver, it reports who made the change, what was changed, and when it was changed.
• Pre- and Post-run Commands — The Administrator sets the proper authority for TurnOver to adopt when a developer tells it to run a pre- or post-run command in a form.
• Interactive SQL — Requires any use of interactive SQL to run inside of TurnOver forms to ensure that using this powerful tool to alter databases is fully tracked, authorized, approved, and so on.
• Application Definition Management — Requires any changes to the application definition itself to be checked out and checked back in. TurnOver logs who made the change, what was changed, and when it was changed.
• Extensive Reporting — TurnOver’s new Crystal Reporting engine makes the wealth of information that TurnOver logs throughout the process more visible than ever.

Back to Table of Contents

WHAT'S NEW