Application Security // Database Security
12/23/2013
12:04 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%
Repost This

Database Risks Increase As Patch Frequency Decreases

Department of Energy breach report offers stark lesson in patch management's relationship with database risk postures

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web