Application Security //

Database Security

12/23/2013
12:04 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2765
PUBLISHED: 2018-08-20
pyro before 3.15 unsafely handles pid files in temporary directory locations and opening the pid file as root. An attacker can use this flaw to overwrite arbitrary files via symlinks.
CVE-2018-15594
PUBLISHED: 2018-08-20
arch/x86/kernel/paravirt.c in the Linux kernel before 4.18.1 mishandles certain indirect calls, which makes it easier for attackers to conduct Spectre-v2 attacks against paravirtual guests.
CVE-2018-15572
PUBLISHED: 2018-08-20
The spectre_v2_select_mitigation function in arch/x86/kernel/cpu/bugs.c in the Linux kernel before 4.18.1 does not always fill RSB upon a context switch, which makes it easier for attackers to conduct userspace-userspace spectreRSB attacks.
CVE-2018-15573
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in Reprise License Manager (RLM) through 12.2BL2. Attackers can use the web interface to read and write data to any file on disk (as long as rlm.exe has access to it) via /goform/edit_lf_process with file content in the lfdata parameter and a pathname in the lf...
CVE-2018-15574
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in the license editor in Reprise License Manager (RLM) through 12.2BL2. It is a cross-site scripting vulnerability in the /goform/edit_lf_get_data lf parameter via GET or POST. NOTE: the vendor has stated "We do not consider this a vulnerability."