The recent report released by the Inspector General of the Department of Energy about a massive breach at the agency earlier this year detailed a number of important breakdowns in security that led to the breach. Perhaps one of the biggest lessons to be learned from the report, though, was how important the patching process is to the risk posture of sensitive databases.

According to Gregory H. Friedman, the author of the report, among the biggest failures that led to the breach was the fact that the management information system (MIS) breached by attackers was running on woefully out-of-date software.

"Critical security vulnerabilities in certain software supporting the MIS application had not been patched or otherwise hardened for a number of years," Friedman reported.

In the same vein, Friedman reported that there was no sense of urgency in replacing end-of-life applications that stood up critical MIS databases.

"Specifically, core support for the version of the compromised application upon which MIS was built ended in July 2012, and the department failed to purchase the extended support that would have provided limited coverage through July 2014," Friedman said.

[Are you using your human sensors? See Using The Human Perimeter To Detect Outside Attacks.]

Patch management has long been a thorn in the side of database administrators, who would just as soon not deal with the performance quirks that come with security updates.

"Database patches tend to introduce not only security fixes, but behavioral changes as well, which cannot be separated out of the cumulative patch," says Barry Shteiman, director of security strategy for Imperva. "For this reason, many DBAs or system admins decide to not patch, or only patch on a yearly maintenance basis, and even then, I have a strong feeling that only patches that are considered 'critical' are installed."

But patches within the database aren't the only ones that greatly affect the security of these sensitive data stores. Applications can be equally as important.

"If an application uses a database back-end -- as they always do -- and that application is vulnerable to attacks, SQL injection, for example, then the database that it has rights to read and write from becomes vulnerable to the same attack," Shteiman says. "It is a chain reaction."

Unfortunately, the basic blocking and tackling of patch and vulnerability management continues to lag at many organizations, particularly those within the public sector. A study conducted earlier this year by CentraStage that examined anonymized hardware and software data of thousands of online servers -- including those belonging to 6,000 different public sector agencies -- found that 40 percent of the machines lacked up-to-date security practices.

According to Dave Rosenberg, CTO at DB Networks, organizations should recognize that the patch process will be imperfect no matter how conscientiously it is pursued.

"Patches are available only after significant problems occur and are detected in the field; after they are understood and addressed by beleaguered developers; knowledge of their availability and distribution to operations is unreliable and time-consuming; and they must be sequenced into production along with many other frequently conflicting priorities," Rosenberg says, explaining that it is important to complement patch management with continuous monitoring and behavioral analysis to look for exploited vulnerabilities.

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.