Segmenting, hardening, encrypting, insuring, and planning--these are good New Year's resolutions for database administrators.
As organizations gear up for a new year, now is the perfect time to look at processes and technologies and reassess how well they really are mitigating risks. On the database level, there are a number of foundational activities that many organizations are still failing to carry out effectively.
The following action list is compiled from some of the advice doled out by database security experts in 2011. Use it wisely to come up with a sane plan in 2012 and beyond:
1. Make Sure Your Database Isn't Easily Searchable On The Web
Several breaches this year embarrassed organizations because their IT departments configured databases touching Web-facing interfaces in such a way that they could be easily searched on the Web.
"The databases that exist today have ultimately been designed to allow the easiest access from a multitude of devices and places. In many people's minds, they think you need to access a server with an application running on that, and that there is a measure of safety for the data sitting underneath the application because the application is secure," said Dr. Mike Lloyd, CTO of RedSeal Systems. "But your database is sitting out there, and, in many cases, when it came out of the box, it came configured to be connected to the Internet."
2. Segment Your Data Better
When organizations segment their high-value data in databases separate from less sensitive information, they're able to prioritize risk management and institute more targeted protection layers.
"Medium to large organizations are not segmenting enough," said Chris Novak, managing principal at Verizon Business. "In these organizations, they've got databases spread over offices, campuses, and complexes around the globe. And the problem is that if they're not segmenting, then a risk in one place becomes a risk everywhere."
Database access controls keep information out of the wrong hands. Limit who sees what to stop leaks--accidental and otherwise. Also in the new, all-digital Dark Reading supplement: Why user provisioning isn't as simple as it sounds. Download the supplement now. (Free registration required.)
Published: 2014-07-22 Multiple cross-site scripting (XSS) vulnerabilities in the web UI in Sophos Anti-Virus for Linux before 9.6.1 allow local users to inject arbitrary web script or HTML via the (1) newListList:ExcludeFileOnExpression, (2) newListList:ExcludeFilesystems, or (3) newListList:ExcludeMountPaths parameter t...
Published: 2014-07-22 jmx-remoting.sar in JBoss Remoting, as used in Red Hat JBoss Enterprise Application Platform (JEAP) 5.2.0, Red Hat JBoss BRMS 5.3.1, Red Hat JBoss Portal Platform 5.2.2, and Red Hat JBoss SOA Platform 5.3.1, does not properly implement the JSR 160 specification, which allows remote attackers to exec...
Published: 2014-07-22 The org.picketlink.common.util.DocumentUtil.getDocumentBuilderFactory method in PicketLink, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 5.2.0 and 6.2.4, expands entity references, which allows remote attackers to read arbitrary code and possibly have other unspecified impact via...
Published: 2014-07-22 Elasticsearch Logstash 1.0.14 through 1.4.x before 1.4.2 allows remote attackers to execute arbitrary commands via a crafted event in (1) zabbix.rb or (2) nagios_nsca.rb in outputs/.