Perimeter
11/28/2012
12:46 PM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Threats And Security Countermeasures

Big data and relational database protections are very similar. What's available to end users is not

How do you secure a database? I get that question a lot. After 15 years of people asking, my reaction is almost instinctual.

"How do you secure Big Data environments?" is the new question people ask. The first time someone asked me this, my gut reaction was to consider what security features we have in relational systems, how they protect data and the database, and then show which facilities are missing from big data clusters.

But this is one of those cases where gut reactions are totally wrong, and that approach misses the essential differences between big data clusters and relational databases, both architecturally and operationally. A reasonable answer to that question would not come for many weeks, as that question kicked off a several-month long research project into big data systems and how to secure them.

In a future post, I'll go into detail about what big data is, and work through some of the specific issues in securing these systems. They're a lot different than relational systems and it requires a bit more discussion about how big data clusters work, and address the architectural differences between the two before we can dive into different approaches to secure them. For now, I do want to highlight the differences in available security features. Most security professionals think about risks, threats and responses, and as the methods to counter threats remains the same, be it big data or relational databases. It's helpful to consider what we are reliant upon today to get an understanding of what's missing.

A quick look at threat-response models for all types of databases:

Data at rest protection
Encryption is the accepted method of protecting archives and data files from unwanted inspection or any attempt to examine data outside of database interfaces. Any data encryption system will be supported by key management.

Unwanted system access or usage
User and administrative access management -- a.k.a. user names and passwords -- is the normal way to gate access to the database. Privilege management is how features and functions are allocated to different users/roles.

Fraud and misuse detection
Separation of duties is key in making fraud and misuse more difficult by requiring physical or virtual participation by one or more people. Logging and activity monitoring are used to track activity and forensically analyze what transpired.

Snooping
Unwanted inspection of data or queries over the network is address via network layer encryption.

Injection or malicious queries
Application layer defenses, built-in database parsing, query interception and filtering, dynamic masking, and activity monitoring are all means to thwart injection and malicious queries and -- potentially -- unwanted map-reduce or similar operations.

Transactional integrity
Either provided at the app layer or, if the database has an understanding of what constitutes a transaction, performed by the database.

Exploits and code weaknesses
Configuration and patch management are the principle approaches to fixing database flaws. In some cases application layer protections and monitoring (a.k.a. virtual patching) can help as well.

Compartmentalization
Databases are inherently multitenant, and constructs like schemas, features like groups or role based access, and facilities to logical segregate data access through labels provide these capabilities.

Data leakage and overprivileged user protections
Encryption, at the application layer, is used as a backstop should these other security measures fail. Leaked data, without the key, is inaccessible. Tools like masking and tokenization remove sensitive data from the database altogether. With most big data environments, many of the protections we rely on are not included within the base set of functions. For example, a Hadoop will not provide means to encrypt stored data, configuration and patch management, identity management, groups and roles, query and data type integrity, nor transactional integrity. The concepts of label security, schemas, communication security, and logging are available -- usually via add-on package -- but not by default.

The good news is several missing capabilities can be bolted on, either by the application developer or IT support. The bad news is some of these will work, to a point, but are not designed to scale in the same manner as big data clusters and create a performance bottleneck in order to implement.

In the next post I'll branch into specifics of big data and introduce the essential characteristics that help define what big data is to help you better understand the security issues.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0640
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote authenticated users to bypass intended restrictions on resource access via unspecified vectors.

CVE-2014-0641
Published: 2014-08-20
Cross-site request forgery (CSRF) vulnerability in EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to hijack the authentication of arbitrary users.

CVE-2014-2505
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to trigger the download of arbitrary code, and consequently change the product's functionality, via unspecified vectors.

CVE-2014-2511
Published: 2014-08-20
Multiple cross-site scripting (XSS) vulnerabilities in EMC Documentum WebTop before 6.7 SP1 P28 and 6.7 SP2 before P14 allow remote attackers to inject arbitrary web script or HTML via the (1) startat or (2) entryId parameter.

CVE-2014-2515
Published: 2014-08-20
EMC Documentum D2 3.1 before P24, 3.1SP1 before P02, 4.0 before P11, 4.1 before P16, and 4.2 before P05 does not properly restrict tickets provided by D2GetAdminTicketMethod and D2RefreshCacheMethod, which allows remote authenticated users to gain privileges via a request for a superuser ticket.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.