Meeting up with seasoned database security and IT operations teams always keeps me on my toes. The RSA Conference is one such event where I get to meet people who have been doing database security far longer than your average practitioner, and their perspective of the daily grind -- in the trenches -- is very different from my typical analyst inquiry on how to deploy a specific security technology.

To this group of veterans, the tools are secondary; they are only as good as the management process that leverages the tool to automate tasks. Get the process wrong and you end up doing more work, not less, regardless of automation. And if the process is not monitored, tasks -- security or otherwise -- don't get done at all. The lesson that was consistent among this group: Security needs to be part of dev-ops (development and operations teams), built into the process as part of the every day set of tasks to ensure basic quality.

Part of the reason for this is that security, if not implemented, is not something the average IT user notices. Don't do it, and no one complains, and no one notices. Well, until there is a breach. The second, and more selfish reason, is to preserve the sanity of the DBAs. There was only so much they could take on, so adherence to the process showed they were doing their job. It gave them a bar to measure against success or failure, and it limited the number of ad-hoc requests from other organizations. Defining what they would and would not do gives priority to tasks.

One thing clear from my experience is that unless security is systemic to the daily process, it won't work. It's a lesson learned from secure software development. No other security-related discipline is more at odds with productivity -- and the most likely to be set aside in favor of new feature development.

The example I cite most is the need to do security unit testing -- in essence, ensuring the code the developers send to QA does, in fact, meet minimum standards. If you actually require security as part of the hand-off requirement, then the work actually gets done. If you treat security as just another feature, then it must compete with more glamorous additions for attention. And any of you in software development know that, at the end of a waterfall development cycle, decisions are made as to what makes it into the build and what gets cut. Security usually loses to shiny, new toys.

The same holds true for database security. If it's not part of the dev-ops cycles, it gets sidelined in favor of other work. If patching is not a regular, regimented, and monitored process, it tends to sit on the sidelines. If you don't run predeployment validation -- making sure that configurations are accurate -- remove unwanted and unneeded modules, and close secondary avenues of database access like PUBLIC permissions or external procedures, then they hang around forever. Seldom does anyone find the time to go back and clean up a mess, as there is always more to do.

Next week I'll get back to setting up a basic database security program.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.