Perimeter
5/10/2011
04:36 PM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Secure Access To Relational Data

How to secure relational data in cloud data centers

Use of data in the cloud does not differ all that much from traditional in-house database systems, but there are a couple important differences in how you secure data in a cloud environment. Databases still provide the essential infrastructure to house, manage, and secure data. We still need to authenticate and authorize users as a first line of defense to gate access. And we want to encrypt communication sessions to avoid eavesdropping.

But in cloud environments, elasticity, easy replication, and manage-from-anywhere interfaces mean we have the added responsibility to validate the application before allowing the instance to access a database and provide service. We need to approve new images or recovered snapshot to ensure we have control of the environment. We still need monitor activity, and use obfuscation and rights management tools to provide fine-grained access controls avoid data leakage. The good news is there are lots of options at our disposal. Implementation can be trivial to complex depending upon the threats you want to address.

So keep in mind the goal here is to validate data use, filling in with security features that are absent from the database or application.

* Credentials & Authorization: For users, all cloud services provide access control services or support systems. SaaS and IaaS providers include support as part of your basic service. For PaaS you have both support from the vendor as well whatever additional credentialing systems you choose to deploy; external validation, database internal access controls or a hybrid model. Use of external LDAP services remains the most popular choice. Authenticating the database images on startup is where things get more difficult.

Most customers require unattended database startup because you can't count on an administrator being present whenever you want to spin up a new database instance. Embedding credentials into the database images of IaaS/PaaS is the common method to address this problem. While this is really handy to allow databases images to start up and run on demand by grabbing a credential file, it's extremely difficult to do safely as the credentials can be stolen by anyone who can access the image files. I suggest using encryption and key management to validate the instances/hosts as discussed below.

* Key Management:Some encryption providers are using key management to help validate instances. For example, data volumes are encrypted, and before an application can access that data volume, you authenticate the instance before providing keys that allow access to data archives. In this way you can guard against rogue instances being used to steal database contents or fool users into submitting sensitive data to the unauthorized instance. Not every key management server has this capability, and by default 'unattended mode' of key managers that support transparent database encryption do not protect you. Verify that the service can both validate the credentials as well as the instances allowed. Use of application layer encryption - to encrypt data prior to storing it in the database, is another strategy; that way the application decides proper use cases.

* Encryption: You will want to encrypt the data volume, or use transparent encryption, to protect data archives. This option only exists in PaaS environments as it's up to the service provider for IaaS/SaaS.

* Monitoring: Database Activity Monitoring remains an important part of validating database usage for cloud deployments. You will need to verify that your IaaS/SaaS vendor will allow you to install agents to collect activity. Depending upon the vendors deployment architecture, they can't conceal other customers information in a multi-tenant environment, and therefore cannot provide activity data to you. Still others virtualize the application itself, making it impossible to install a protocol stack agent. Verify with your provider what they allow and see if that matches your DAM deployment options. For PaaS environments you can deploy virtual appliances or software, with the agent feeding events into the server. Selected PaaS providers allow configuration of network 'nodes', so you can route database requests betwee

* Labeling & Masking: These obfuscation technologies help conceal sensitive information. Labeling is a method of tagging rows that are to be read by members of select groups, offering fine grained restriction to data access. In cases where it's not possible to fully trust the user, masking returns a facsimile of the original data in the query results. The result set has the same look and format, but it's random or scrambled - to conceal the actual data.

Object-level controls -- for schemas, tables, columns --- function the same.

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

Quick reference: Part 1 Intro, Part 2 Cloud Database Models, Part 3 Data Security Lifecycle, Part 4 Create and Part 5 Store. 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
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web