Welcome Guest. | Log In | Register | Membership Benefits


Topics:   Database Security Tech Center : Security Views

Securing Databases In The Cloud: Part 4

What kind of data do you have, and how do you want to protect it?

Apr 07, 2011 | 03:42 PM | 

By Adrian Lane
Dark Reading

In this series of blogs, I have introduced the data security life cycle as a generic model for how to approach data security in the cloud. Now we'll dig into the first phase of the life cycle -- the meat of cloud database security -- following the CSK guidance (PDF), but focusing on data security as it pertains to databases in the cloud.

Keep in mind what we are talking about is applying security at the data layer because we can't make assumptions about the security of our environment either in public or private clouds. Further, the technologies we use will be very different depending on the "type" of cloud service (SaaS, IaaS, or PaaS) and the type of database (traditional relational databases, database as a service platforms, or indexed flat files). For the majority of your traditional relational database platforms, in public or private, platform-as-a-service environments will be the deployment model of choice.

The first phase in the data security life cycle is to classify sensitive data as it's "created." Created, in this context, can mean several things. It can be literally as data is created, or it can mean as data is moved from traditional IT systems into a cloud database, or apply to the discovery process when looking for data already residing in a cloud database. In essence, we discover what kind of data we have so we can define the proper security controls. In all cases we are creating a catalog of sensitive information, noting type and location, and designating how data will be protected.

If that sounds like the starting point for other security processes you have read about in the past, it is. But how you do it is very different. In many cases you don't have easy and direct access to the information you need. Many discovery, classification, and some rights management tools cannot be deployed in the cloud. Before you move data into the cloud, even before you create your policies and controls, you have to determine how to scan and classify data. For cataloging data as it is moved into the cloud:

* use DLP and content discovery tools to locate and classify unstructured data. Specify tags that will identify flat-file contents and direct rights management. Apply tags as you move data into the cloud.

* use data "crawlers" to scan relational databases for sensitive information. Define labels for relational cloud databases. All of the major relational platforms have label security options that you leverage, but you want to add these to cloud schema prior to data migration. You'll most likely do bulk inserts, so labels and security policies must be defined first. Plan on writing post-insertion scripts to apply controls and verify labels and access controls are in place. * use DRM, or encryption, to protect data where labeling technologies and access controls are insufficient. Different encryption keys can be used to help segregate who can access information, but this will need to be built into the application layer.

That's the easy part. It's harder for those of you who are already in the cloud, especially those using SaaS. For data that already resides within the cloud:

* SaaS: This is one of the harder problems to solve because the database is hidden from you by design.

Determine whether your SaaS service will provide you with a database schema -- with column definitions -- to assist locating sensitive information. This is a manual process of determining looking at storage structure to find what data needs to be protected. Because your service provider might not allow traditional data discovery tools in its multitenant environment, request an archive of your data and use scanning tools to locate sensitive information. You'll manually review CSV files to determine which columns contain sensitive information. You will need to work with the provider to see what options for encryption, label security, or authorization mapping is available. You will need to review, and possibly modify, your service-level agreements (SLAs) to enforce security controls.

* IaaS: In this case, IaaS equates to database-as-a-service. The good news is you have more access to the database infrastructure so you can discover database structure, system catalog, and content. The bad news is most databases provided as a service are not the same relational platforms you know and love. This means many of the discovery, rights management, and classification tools you use today are not supported. Column/Table encryption, label security and discovery tools are not provided.

As with SaaS, analyze archives to locate sensitive information, or scan database contents and structure with your own scripts. For tagged file or ISAM storage, use tags to designate classification. Work with your provider to determine what authorization facilities are available for fine-grained access controls. You will need to modify your queries to inspect the tags in order to mimic labeling capabilities, but for now we are focused on finding and tagging data so we know how we will protect information in subsequent steps.

* PaaS: Platform-as-a-service offers great flexibility because you can use the same databases in the cloud that you are already familiar with. And all of the existing tools for discovery, classification, and rights management will still work. The biggest problem is finding all of the data. Many leverage global resources to vertically partition databases, deploy multinode grids, or even mirroring. Most use unstructured storage to take database snapshots in lieu of traditional tape archives. Data gets strewn everywhere, so you need to take care in understanding the complete data life cycle prior to discovery. If it seems like we are doing a lot of work before we even get data into the cloud, we are. For most data centers, security has been an evolutionary process, with controls added in bits and pieces over time. For cloud deployments, we are not only moving the data center, but altering many of the underlying assumptions, so we need to rethink data usage and security controls.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.

Securing Databases In The Cloud series:
Part 1
Part 2
Part 3



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS



Database Security Reports

report Securing The Data Warehouse
Many enterprises are building data warehouses to centralize the ever-increasing information flowing through their organizations into useful repositories. This makes good business sense, but it opens up a slew of concerns from a security standpoint. IT professionals can apply many of the same security best practices used with databases, but there are new lessons to be learned as well.

report Defend Your Data From Malicious Insiders
The biggest threat to your company?s most sensitive data may be the employee who has legitimate access to corporate databases but less-than-legitimate intentions. And while the incidence of insider data breaches has decreased, external attacks often imitate them--and do serious damage. Follow our advice to mitigate the risk.

report Ensuring Secure Database Access
Role-based access control based on least user privilege is one of the most effective ways to prevent the compromise of corporate data. But proper provisioning is a growing challenging, due to the proliferation of "big data," NoSQLdatabases, and cloud-based data storage.

Other reports from the Database Security Tech Center:

Related Content

Establishing a Strategy for Database Security is No Longer Optional
As databases continue to grow in size, complexity and importance, enterprises struggle to identify the most appropriate controls regarding their use and misuse. The report identifies best practices, including: Implementing database activity monitoring to mitigate the high levels of risk from database vulnerabilities, and address audit findings in areas such as database segregation of duties and change management; using data security measures, such as data masking and data encryption; and monitoring privileged-user access and access to critical data.

Database Activity Monitoring Is Evolving Into Database Audit and Protection
In this report, Gartner writes that "Database audit and protection (DAP) represents an evolutionary advance in database activity monitoring tools." DAP suites provide comprehensive, cross-platform support in heterogeneous database environments to protect sensitive data from inappropriate use. Organizations are increasingly concerned with optimizing database security and mitigating risks associated with database vulnerabilities.

Protecting Against Database Attacks and Insider Threats: Top 5 Scenarios
Data security presents a multi-dimensional challenge in today's complex IT environment. Multiple access paths and permission levels have resulted in a broad array of security threats and vulnerabilities. We invite you to read this new eBook: "Protecting against database attacks and insider threats" to learn the top five scenarios and essential best practices for preventing database attacks and insider threats.

Demo: Distributed Database Security with Real-time Monitoring and Audit Protection
Organizations across the globe continue to experience compromised data caused by malicious attacks, web application vulnerabilities or unauthorized changes. View this demo and learn how IBM InfoSphere Guardium? database activity monitoring can help protect your sensitive data in distributed DBMS environments with a holistic approach to data security and compliance.

Look Beyond Native Database Auditing To Improve Security, Audit Visibility, And Real-Time Protection
Today's attacks on enterprise databases are more sophisticated than ever, and they occur so fast that it's often difficult to stop them in real time. Despite significant efforts to protect enterprise databases, the number of records breached has grown each year - due to all types of internal and external attacks and violations of corporate policy.




Featured Webcasts
Featured Whitepapers
Featured Reports