Secure Development Means Building In Monitoring

When most experts talk about the secure development life cycle (SDL) for homegrown apps, the discussion inevitably gravitates around flaw discovery and remediation. But the truth is that vulnerabilities aren't the only consideration that development teams need to think about when they're creating in-house applications: Not only do these applications need to be built with a minimum of exploitable bugs, but they also need to be easy for the security team to monitor, particularly when they tie into important financial systems or sensitive customer databases.

"The whole discussion in the evolution of application development right now is on how we build applications that are more secure," says Joe Gottlieb, CEO of SIEM vendor SenSage. "Well, one way to do it is to make sure they have a good logging capability and that we're taking the logs of our homegrown apps and including them in the data sets that we're analyzing."

Of course, security pundits are having a hard enough time passing along the message to work on securing the code base during development, let alone baking in monitoring and audit capabilities. The reality is that in this get-it-done-yesterday age of software development, security is the last thing on anyone's minds.

"The problem is a lot of applications are driven and developed with one driver in mind: making money," says Andrew Hay, senior analyst with The 451 Group's Enterprise Security Practice. "So there are many shortcuts taken to get the product out as fast as possible. Then in a couple of years or maybe a few months, people might say, 'We need security in that project.' So we go back to the drawing board and retrofit it with security. And only after that do people say, 'We should probably get logs, too, for when something goes wrong.'"

At that point, Hay says, the application goes from a sleek-looking red Ferrari to a clunker with "a huge stupid-looking spoiler, aftermarket wheels that don't really fit, and doors that are painted green."

Software developer Dave Hatter couldn't agree more. A 20-year veteran who has honed his chops building custom applications for enterprises, Hatter says that building in audit functionality early is key. "It's always easier to start out with the end in mind and build toward it than to try to retrofit a bunch of crap in later because you embraced this stuff too late," says Hatter, CEO of Libertas Technologies. "You tend to break stuff when you retrofit. There are unintended consequences with that sort of thing."

At a bare minimum, he says, developers need to create homegrown applications that include a way to track when records have been created within the database, when they've been modified, and who was responsible for the changes.

"From the best practices standpoint, we wouldn't build any application -- whether we had more advanced monitoring or not -- where you don't have unique user IDs for specific user roles and that every record in the database, no matter what its purpose is, gets a date/time stamp and user stamp," he says. "To me that's an absolute baseline, and anything less than that is unacceptable."

He says from an auditing standpoint, best practices dictate that the application should be able to track who has viewed information, who has changed information, and when these actions were taken. This can be done either through your own code or by leveraging tools you might already have.

"You can build that kind of auditing in with traditional approaches, like triggers, or take advantage of tools in products, like SQL Server with change data control. A lot of these newer database platforms have some pretty sophisticated and powerful auditing and tracking mechanisms," he says. "Don't reinvent the wheel if you can help it."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.