Research

I have not been blogging much this week, as I have been up to my eyeballs in a couple different research projects. But as with any research effort, I always learn a lot and it alters my perceptions and recommendations on the security subjects I cover. Sometimes the revelations are not revelatory at all, but because I misunderstood the vendor solution (d’oh!), or I was unable to keep pace with the continuous advancements across the 125+ vendors I attempt to track. Regardless, I wanted to share a couple observations concerning database encryption I think are worth mentioning. Misconception #1: Microsoft’s Approach to Database Encryption I believed Microsoft wanted SQL Server to leverage BitLocker and the associated Encrypted File System (EFS). It seemed to me that their strategy was going to be similar to what IBM does with Vormetic: leveraging a generic file system encryption system to secure both database and generic files on disk. They have lots invested in the OS, so why not? Looking at SQL Server 2008, that really does not seem to be the focus – instead Transparent Database Encryption, performed at the block level, is the preferred method for database encryption. Block level encryption is pretty fast, and as it is applied to all the data files, you cannot accidently miss one and leave data exposed. This option seems more appropriate for compliance, as you are moving key management and encryption policy decisions out of IT and into the database. In practice this may be academic, but it’s easier and offers less room for mistakes. All told, that can be the difference in making an auditor happy. If you look at the SQL Server portfolio of encryption options, they offer the API level ‘cell encryption’, block level TDE, and BitLocker OS level encryption. Coupled with the DPAPI key manager, this means Microsoft’s approach is closer to Oracle’s, with their corresponding dbms_crypto API, block level Tablespace Transparent Encryption (TTE or TDE depending on your reference), wallet key manager, and column level TDE that provides intra-block protection. It’s not surprising that IBM focuses more on storage, Microsoft more on the OS, and Oracle on the application layer, but Oracle and Microsoft now have more similarities than differences. Misconception #2: Oracle Key Management I have been known to lock myself in a server lab for a week or more, testing a product every which way, until I am confident I know how a product works. Blue fingered and frozen, I emerge with knowledge of how a product stands up to its competition and how it solves customer problems. I did this with Oracle 10G encryption a few years ago, and came away with the impression that is was very easy to use, with more than acceptable performance, but storing the keys in the database remains an issue. I seem to remember the keys being stored raw in the systems tables. What shocked me is that I learned that the external key server (what Oracle calls a ‘wallet’), is mandatory, not optional. This means that all the keys stored in the database are encrypted by the master key stored in the wallet. I have absolutely no recollection of that being the case, and while I vividly remember setting up keys, I have no memory of installing, configuring or using a wallet. Maybe I had a beta version – who knows? But I was so shocked by this I asked Rich if he knew about it and he said ‘no’. So if both of us can totally misunderstand this requirement, it’s a fair bet others have as well. The wallet as a required external key management service is important, as it encrypt the keys used to encrypt / decrypt data within the database. Encryption by a master key external to the database makes it virtually impossible for the DBA to get the keys, as they are not sitting around in cleartext on disk. Accessing the master key is a process between the database and the wallet, where the database must securely authenticate itself before it can be provided the master key it needs to decrypt data encryption keys. The master key is in turn secured in the wallet through RSA’s PKCS #5 v2.0 secure password methodology, so the master key never resides in the clear on disk either. You need to make sure the wallet is properly secured and backed up, but these minor management tasks pale in comparison to the extra key security provided. I am happy to be wrong as this is a really solid security choice on their part. Misconception #3: Application Level Security I have been saying for years, rather emphatically, that application level encryption is more secure that database encryption. You have the flexibility of what data to encrypt, external key management, the ability to decouple keys from access controls, certificate verification, and the option to double encrypt for certain types of workflow and policy enforcement. While this came at great expense in development time, you at least had the option to be as secure as you needed to be. With the database vendors offering external key managers or even hardware security modules, key hierarchies, and more flexible application of encryption, the gap has closed. While I still believe that the application level can offer a small degree of added security depending upon how well the implementation is done, it’s now splitting hairs. Compromising key security, undermining the cryptography, gaining access to keys in memory, or any attack is going to be pretty much the same regardless of the solution. The database is no longer really easier to hack, as many of the common ways to subvert the system have since been closed. Do I still think that application level encryption is a bit better than database level encryption? Yes, but only because of what’s possible, and not because of inherent design issuess with the approaches database vendors took. Share:

In our last post in this series, we covered the cloud implications of the Share phase of Data Security Cycle. In this post we will move on to the Archive and Destroy phases. Archive Definition Archiving is the process of transferring data from active use into long-term storage. This can include archived storage at your cloud provider, or migration back to internal archives. From a security perspective we are concerned with two controls: encrypting the data, and tracking the assets when data moves to removable storage (tapes, or external drives for shipping transfers). Since many cloud providers are constantly backing up data, archiving often occurs outside customer control, and it’s important to understand your provider’s policies and procedures. Steps and Controls Control Structured/Application Unstructured Encryption Database Encryption Tape Encryption Storage Encryption Asset Management Asset Management Encryption In the Store phase we covered a variety of encryption options, and if content is kept encrypted as it moves into archived storage, no additional steps are needed. Make sure your archiving system takes the encryption keys into account, since restored data is useless if the corresponding decryption keys are unavailable. In cloud environments data is often kept live due to the elasticity of cloud storage, and might just be marked with some sort of archive tag or metadata. Database Encryption: We reviewed the major database encryption options in the Store phase. The only archive-specific issue is ensuring the database replication/archiving method supports maintenance of the existing encryption. Another option is to use file encryption to secure the database archives. For larger databases, tape or storage encryption is often used. Tape Encryption: Encryption of the backup tapes using either hardware or software. There are a number of tools on the market and this is a common practice. Hardware provides the best performance, and inline appliances can work with most existing tape systems, but we are increasingly seeing encryption integrated into backup software and even tape drives. If your cloud provider manages tape backups (which many do), it’s important to understand how those tapes are protected – is any existing encryption maintained, and if not, how are the tapes encrypted and keys managed? Storage Encryption: Encryption of data archived to disk, using a variety of techniques. Although some hardware tools such as inline appliances and encrypted drivesxist, this is most commonly performed in software. We are using Storage Encryption as a generic term to cover any file or media encryption for data moved to long-term disk storage. Asset Management One common problem in both traditional and cloud environments is the difficulty of tracking the storage media containing archived data. Merely losing the location of unencrypted media may require a breach disclosure, even if the tape or drive is likely still located in a secure area – if you can’t prove it’s there, it is effectively lost. From a security perspective, we aren’t as concerned with asset management for encrypted content – it’s more of an issue for unencrypted sensitive data. Check with your cloud provider to understand their asset tracking for media, or implement an asset management system and procedures if you manage your own archives of cloud data. Cloud SPI Tier Implications Software as a Service (SaaS) Archive security options in a SaaS deployment are completely dependent on your provider. Determine their backup procedures (especially backup rotations), any encryption, and asset management (especially for unencrypted data). Also determine if there are any differences between backups of live data and any long-term archiving for data moved off primary systems. Platform as a Service (PaaS) Archive security in PaaS deployments is similar to SaaS when you transition data to, or manage data with, the PaaS provider. You will need to understand the provider’s archive mechanisms and security controls. If the data resides in your systems, archive security is no different than managing secure archives for your traditional data stores. Infrastructure as a Service (IaaS) For completely private cloud deployments, IaaS Archive security is no different than managing traditional archived storage. You’ll use some form of media encryption and asset management for sensitive data. For cloud storage and databases, as with PaaS and SaaS you need to understand the archival controls used by your provider, although any data encrypted before moving to the cloud is clearly still secure. Destroy Definition Destroy is the permanent destruction of data that’s no longer needed, and the use of content discovery to validate that it is not lingering in active storage or archives. Organizations commonly destroy unneeded data, especially sensitive data that may be under regulatory compliance requirements. The cloud may complicate this if your provider’s data management infrastructure isn’t compatible with your destruction requirements (e.g., the provider is unable to delete data from archived storage). Crypto-shredding may be the best option for many cloud deployments, since it relies less on complete access to all physical media, which may be difficult or impossible even in completely private/internal cloud deployments. Steps and Controls Control Structured/Application Unstructured Crypto-Shredding Enterprise Key Management Secure Deletion Disk/Free Space Wiping Physical Destruction Physical Destruction Content Discovery Database Discovery DLP/CMP Discovery Storage/Data Classification Tools Electronic Discovery Crypto-Shredding Crypto-shredding is the deliberate destruction of all encryption keys for the data; effectively destroying the data until the encryption protocol used is (theoretically, some day) broken or capable of being brute-forced. This is sufficient for nearly every use case in a private enterprise, but shouldn’t be considered acceptable for highly sensitive government data. Encryption tools must have this as a specific feature to absolutely ensure that the keys are unrecoverable. Crypto-shredding is an effective technique for the cloud since it ensures that any data in archival storage that’s outside your physical control is also destroyed once you make the keys unavailable. If all data is encrypted with a single key, to crypto-shred you’ll need to rotate the key for active storage, then shred the “old” key, which will render archived data inaccessible. We don’t mean to oversimplify this option – if your cloud provider can’t rotate your keys or ensure key deletion, crypto-shredding isn’t realistic. If you manage your own keys, it should be an important part of your strategy. Disk/Free Space Wiping and Physical

Well, this is interesting: the FCC Chairman announced that they do not believe wireless carriers should be able to block certain types of Internet traffic, according to the AP release a few hours ago. The thrust of the comments seems to be that they want to extend Internet usage rights over the wireless carrier networks. The chairman is now proposing to make it a formal rule that Internet carriers cannot discriminate against certain types of traffic by degrading service. That expands on the principle that they cannot “block” traffic, as articulated in a 2005 policy statement. It’s unclear how the rules would apply in practice to wireless data. For instance, carriers officially restrict how Internet-access cards for laptops are used, but rarely enforce the rules. The government also has been investigating Apple Inc.’s approval process for iPhone applications, but Genachowski isn’t directly addressing manufacturers’ right to determine which applications run on their phones. It does highlight that if you can control the applications used (available) on the devices, you can in turn control the content. Unless of course you break the protection on the phone. But still, this would appear to put the handset providers in the driver’s seat as far as what applications are acceptable. How long will it be before the carriers try to dictate acceptable applications when they negotiate deals? How will the carriers attempt to protect their turf and their investment? Could users say “screw both of you” and encrypt all of their traffic? Personally I like the idea, as it does foster invention and creativity outside the rigorous use models the carriers and phone providers support today. This is going to be a complex and dynamic struggle for the foreseeable future. Share:

Thanks to the opportunity to be the Securosis Contributing Analyst, I’m back to blogging here on Securosis even though Rich isn’t off getting bits of his body operated on. I’ve decided to revive an old Identity and Access Management (IDM) research project of mine to kick off my work here at Securosis. Once you get past compliance, one of the biggest recent concerns for CIOs and CISOs has been IDM. This isn’t really that surprising when you consider that IDM is a key aspect of any successful security or compliance program. After all, how can you say with confidence whether or not you’ve had a breach, if you don’t know who has access to what data, or don’t have a process for granting and revoking that access? In principle this should be pretty straightforward, right? Keep a database of users with what applications they have access to and whenever they change roles, re-evaluate that access and make the appropriate changes for their new (or now non-existent) role. Unfortunately, simple doesn’t mean easy. Many large enterprises have hundreds if not thousands of applications that they need to track and in many (most?) cases these applications are not centrally controlled, even if you just count the ‘critical’ ones. This disparate control will continue to get worse as corporations continue to embrace “The Cloud.” Realistically, companies are in a situation where IDM is not only a difficult problem to solve, but also a fairly complex one as well. IDM is a large enough problem for enough companies that an entire market has sprung up over the last ten years to help organizations deal with it. In the beginning, IDM solutions were all about managing Moves, Adds and Changes (MAC) for accounts. There are several products to help with this issue, but by all reports many of them just make the situation even more complicated then it already was. Since these initial products hit the market, vendors who sell directory services, single sign on/federated identity, and entitlement services (to name just a few) have jumped onto the IDM bandwagon with claims to solve your woes. This has just caused even more confusion and made customers’ jobs even more difficult, causing many to ask: “Just what is IDM anyway?” As a result, I’m planning on breaking up my project into two major pieces. One part of the larger project will be to evaluate the IDM space in order to make recommendations on what security practitioners should look for in such products, to the extent that they choose to go that route. From my investigations to date, many companies (especially SMBs) don’t have a technology problem to solve, but rather one of process. As a result, the other part of this project will be to create a series of recommendations for companies to implement to make their IDM efforts more successful. In the meantime, feel free to treat the comments here as an open thread for your thoughts on IDM and how to do it better. Share:

In our last post in this series, we covered the cloud implications of the Use phase of our Data Security Cycle. In this post we will move on to the Share phase. Please remember that we are only covering technologies at a high level in this series on the cycle; we will run a second series on detailed technical implementations of data security in the cloud a little later. Definition Share includes controls we use when exchanging data between users, customers, and partners. Where Use focuses on controls when a user interacts with the data as an individual, Share includes the controls once they start to exchange that data (or back-end data exchange). In cloud computing we see a major emphasis on application and logical controls, with encryption for secure data exchange, DLP/CMP to monitor communications and block policy violations, and activity monitoring to track back-end data exchanges. Cloud computing introduces two new complexities in managing data sharing: Many data exchanges occur within the cloud, and are invisible to external security controls. Traditional network and endpoint monitoring probably won’t be effective. For example, when you share a Google Docs document to another user, the only local interactions are through a secure browser connection. Email filtering, a traditional way of tracking electronic document exchanges, won’t really help. For leading edge enterprises that build dynamic data security policies using tools like DLP/CMP, those tools may not work off a cloud-based data store. If you are building a filtering policy that matches account numbers from a customer database, and that database is hosted in the cloud as an application or platform, you may need to perform some kind of mass data extract and conversion to feed the data security tool. Although the cloud adds some complexity, it can also improve data sharing security in a well-designed deployment. Especially in SaaS deployments, we gain new opportunities to employ logical controls that are often difficult or impossible to manage in our current environments. Although our focus is on cloud-specific tools and technologies, we still review some of the major user-side options that should be part of any data security strategy. Steps and Controls Control Structured/Application Unstructured Activity Monitoring and Enforcement Database Activity Monitoring Cloud Activity Monitoring/Logs Application Activity Monitoring Network DLP/CMP Endpoint DLP/CMP Encryption Network/Transport Encryption Application-Level Encryption Email Encryption File Encryption/EDRM Network/Transport Encryption Logical Controls Application Logic Row Level Security None Application Security see Application Security Domain section Activity Monitoring and Enforcement We initially covered Activity Monitoring and Enforcement in the Use phase, and many of these controls are also used in the Share phase. Our focus now switches from watching how users interact with the data, to when and where they exchange it with others. We include technologies that track data exchanges at four levels: Individual users exchanging data with other internal users within the cloud or a managed environment. Individual users exchanging data with outside users, either via connections made from the cloud directly, or data transferred locally and then sent out. Back-end systems exchanging data to/from the cloud, or within multiple cloud-based systems. Back-end systems exchanging data to external systems/servers; for example, a cloud-based employee human resources system that exchanges healthcare insurance data with a third-party provider. Database Activity Monitoring (DAM): We initially covered DAM in the Use phase. In the Share phase we use DAM to track data exchanges to other back-end systems within or outside the cloud. Rather than focusing on tracking all activity in the database, the tool is tuned to focus on these exchanges and generate alerts on policy violations (such as a new query being run outside of expected behavior), or track the activity for auditing and forensics purposes. The challenge is to deploy a DAM tool in a cloud environment, but an advantage is greater visibility into data leaving the DBMS than might otherwise be possible. Application Activity Monitoring: Similar to DAM, we initially covered this in the Use phase. We again focus our efforts on tracking data sharing, both by users and back-end systems. While it’s tougher to monitor individual pieces of data, it’s not difficult to build in auditing and alerting for larger data exchanges, such as outputting from a cloud-based database to a spreadsheet. Cloud Activity Monitoring and Logs: Depending on your cloud service, you may have access to some level of activity monitoring and logging in the control plane (as opposed to building it into your specific application). To be considered a Share control, this monitoring needs to specify both the user/system involved and the data being exchanged. Network Data Loss Prevention/Content Monitoring and Protection: DLP/CMP uses advanced content analysis and deep packet inspection to monitor network communications traffic, alerting on (and sometimes enforcing) policy violations. DLP/CMP can play multiple roles in protecting cloud-based data. In managed environments, network DLP/CMP policies can track (and block) sensitive data exchanges to untrusted clouds. For example, policies might prevent users from attaching files with credit card numbers to a cloud email message, or block publishing of sensitive engineering plans to a cloud-based word processor. DLP can also work in the other direction: monitoring data pulled from a cloud deployment to the desktop or other non-cloud infrastructure. DLP/CMP tools aren’t limited to user activities, and can monitor, alert, and enforce policies on other types of TCP data exchange, such as FTP, which might be used to transfer data from the traditional infrastructure to the cloud. DLP/CMP also has the potential to be deployed within the cloud itself, but this is only possible in a subset of IaaS deployments, considering the deployment models of current tools. (Note that some email SaaS providers may also offer DLP/CMP as a service). Endpoint DLP/CMP: We initially covered Endpoint DLP/CMP in the Use phase, where we discussed monitoring and blocking local activity. Many endpoint DLP/CMP tools also track network activity – this is useful as a supplement when the endpoint is outside the corporate network’s DLP/CMP coverage. Encryption In the Store phase we covered encryption for protecting data at rest.

In our last post in this series, we covered the cloud implications of the Store phase of Data Security Cycle (our first post was on the Create phase). In this post we’ll move on to the Use phase. Please remember we are only covering technologies at a high level in this series – we will run a second series on detailed technical implementations of data security in the cloud a little later. Definition Use includes the controls that apply when the user is interacting with the data – either via a cloud-based application, or the endpoint accessing the cloud service (e.g., a client/cloud application, direct storage interaction, and so on). Although we primarily focus on cloud-specific controls, we also cover local data security controls that protect cloud data once it moves back into the enterprise. These are controls for the point of use – we will cover additional network based controls in the next phase. Users interact with cloud data in three ways: Web-based applications, such as most SaaS applications. Client applications, such as local backup tools that store data in the cloud. Direct/abstracted access, such as a local folder synchronized with cloud storage (e.g., Dropbox), or VPN access to a cloud-based server. Cloud data may also be accessed by other back-end servers and applications, but the usage model is essentially the same (web, dedicated application, direct access, or an abstracted service). Steps and Controls Control Structured/Application Unstructured Activity Monitoring and Enforcement Database Activity Monitoring Application Activity Monitoring Endpoint Activity Monitoring File Activity Monitoring Portable Device Control Endpoint DLP/CMP Cloud-Client Logs Rights Management Label Security Enterprise DRM Logical Controls Application Logic Row Level Security None Application Security see Application Security Domain section Activity Monitoring and Enforcement Activity Monitoring and Enforcement includes advanced techniques for capturing all data access and usage activity in real or near-real time, often with preventative capabilities to stop policy violations. Although activity monitoring controls may use log files, they typically include their own collection methods or agents for deeper activity details and more rapid monitoring. Activity monitoring tools also include policy-based alerting and blocking/enforcement that log management tools lack. None of the controls in this category are cloud specific, but we have attempted to show how they can be adapted to the cloud. These first controls integrate directly with the cloud infrastructure: Database Activity Monitoring (DAM): Monitoring all database activity, including all SQL activity. Can be performed through network sniffing of database traffic, agents installed on the server, or external monitoring, typically of transaction logs. Many tools combine monitoring techniques, and network-only monitoring is generally not recommended. DAM tools are managed externally to the database to provide separation of duties from database administrators (DBAs). All DBA activity can be monitored without interfering with their ability to perform job functions. Tools can alert on policy violations, and some tools can block certain activity. Current DAM tools are not cloud specific, and thus are only compatible with environments where the tool can either sniff all network database access (possible in some IaaS deployments, or if provided by the cloud service), or where a compatible monitoring agent can be installed in the database instance. Application Activity Monitoring: Similar to Database Activity Monitoring, but at the application level. As with DAM, tools can use network monitoring or local agents, and can alert and sometimes block on policy violations. Web Application Firewalls are commonly used for monitoring web application activity, but cloud deployment options are limited. Some SaaS or PaaS providers may offer real time activity monitoring, but log files or dashboards are more common. If you have direct access to your cloud-based logs, you can use a near real-time log analysis tool and build your own alerting policies. File Activity Monitoring: Monitoring access and use of files in enterprise storage. Although there are no cloud specific tools available, these tools may be deployable for cloud storage that uses (or presents an abstracted version of) standard file access protocols. Gives an enterprise the ability to audit all file access and generate reports (which may sometimes aid compliance reporting). Capable of independently monitoring even administrator access and can alert on policy violations. The next three tools are endpoint data security tools that are not cloud specific, but may still be useful in organizations that manage endpoints: Endpoint Activity Monitoring: Primarily a traditional data security tool, although it can be used to track user interactions with cloud services. Watching all user activity on a workstation or server. Includes monitoring of application activity; network activity; storage/file system activity; and system interactions such as cut and paste, mouse clicks, application launches, etc. Provides deeper monitoring than endpoint DLP/CMF tools that focus only on content that matches policies. Capable of blocking activities such as pasting content from a cloud storage repository into an instant message. Extremely useful for auditing administrator activity on servers, assuming you can install the agent. An example of cloud usage would be deploying activity monitoring agents on all endpoints in a customer call center that accesses a SaaS for user support. Portable Device Control: Another traditional data security tool with limited cloud applicability, used to restrict access of, or file transfers to, portable storage such as USB drives and DVD burners. For cloud security purposes, we only include tools that either track and enforce policies based on data originating from a cloud application or storage, or are capable of enforcing policies based on data labels provided by that cloud storage or application. Portable device control is also capable of allowing access but auditing file transfers and sending that information to a central management server. Some tools integrate with encryption to provide dynamic encryption of content passed to portable storage. Will eventually be integrated into endpoint DLP/CMF tools that can make more granular decisions based on the content, rather than blanket policies that apply to all data. Some DLP/CMF tools already include this capability. Endpoint DLP: Endpoint Data Loss Prevention/Content Monitoring and Filtering tools that monitor and restrict usage of data through content

Last week, a friend loaned me his copy of Emergency, by Neil Strauss, and I couldn’t put it down. It’s a non-fiction book about the author’s slow transformation from wussy city dweller to full-on survival and disaster expert. And I mean full on; we’re talking everything from normal disaster preparedness, to extensive training in weapons, wilderness and urban survival, developing escape routes from his home to other countries, planting food and fuel caches, and gaining dual citizenship… “just in case”. There’s even a bit with a goat, but not in the humorous/deviant way. I’ve never considered myself a survivalist, although I’ve had extensive survival training and experience as part of my various activities. When you tend to run towards disasters, or engage in high risk sports, it’s only prudent to get a little extra training and keep a few spare bags of gear and supplies around. After I got back from helping out with the Hurricane Katrina response I went through a bit of a freak out moment when I realized all my disaster plans were no longer effective. When I was single in Boulder I didn’t really have to worry much – as a member of the local response infrastructure, I wouldn’t be sitting at home if anything serious happened. I kept the usual 3-day supply of food and water, not that I expected to need it (since I’d be in the field), and my camping/rescue gear would take care of the rest. I lived well above the flood-line, and only had to grab a few personal items and papers in case of a fire. By the time I deployed to Katrina I was living in a different state with a wife (well, almost, at the time), pets, and an extended family who weren’t prepared themselves. The biggest change of all was that I was no longer part of the local response infrastructure – losing access to all of the resources I’d grown used to having available. The only agency I still worked for was based hundreds of miles away in Denver. Oops. Needless to say the complexities of planning for a family with children, pets, and in-laws is far different than holing up in the mountains for a few days. Seriously, do you know how hard it is to plan on bugging out with cats who don’t get along? (Yes, of course I’m taking them – I care more about my cats than I do about most people). I still don’t feel fully prepared, although the range of disasters we face in Phoenix is smaller than Colorado. I fully recognize the odds of me ever needing any of my disaster plans are slim to none, but I’ve been involved in far too many real situations to think the effort and costs aren’t worth it. Nearly all of the corporate disaster planning I’ve seen is absolute garbage (IT or otherwise). The drills are scripted, the plans fatally flawed, and the people running them are idiots who took a 2 day class and have no practical experience. If you have a plan that hasn’t been practiced under realistic conditions on a regular basis, there’s no chance it will work. Oh – and most of the H1N1 advice out there is rubbish. Just tell sick people to stay home at the first sign of a fever, and don’t count it against their vacation hours. Anyway, I highly recommend the book. It’s an amusing read with a good storyline and excellent information. And a goat. With that, it’s time for our weekly update: -Rich Webcasts, Podcasts, Outside Writing, and Conferences Rich and Adrian presented at the Data Protection Decisions in DC. Rich had a full schedule with “Understanding and Selecting a DLP Solution”, “Understanding and Selecting a Database Activity Monitoring Solution”, “and Pragmatic Data Security”. Adrian got to lounge around after presenting “Truth, Lies and Fiction about Encryption”. We’ll be doing another one in Atlanta on November 19th. Rich was quoted in SC Magazine on the acquisition of Vericept by Trustwave. Don’t forget that you can subscribe to the Friday Summary via email. Favorite Securosis Posts Rich: Adrian’s new definition: Vendor Myopia Adrian: Going back in time as it was lost in the shuffle: Format and Datatype Preserving Encryption Mortman: XML Security Overview Meier: Cloud Data Security: Store (Rough Cut). Just read it! Other Securosis Posts Google and Micropayment There Are No Trusted Sites: New York Times Edition Project Quant Posts Raw Project Quant Survey Results Favorite Outside Posts Adrian: Top security risks, per SANS. Rich: Dancho’s Ultimate Guide to Scareware. Meier: Everything (and then some) you wanted to know about Zeus/Zbot. Mortman: Not strictly a security post, but this post talks about the general reactions that many of us have to dealing with new technologies or regulations. Top News and Posts Intelligence Analyst charged with hacking. C’mon, it’s just research! Tenable Nessus 4.0.2 released. RBS WorldPay hacked: full database access. Remote Exploit Released for Vista SMB2 Vulnerability. The New School of Information Security requests performance data from the federal government. Drive-by power grid takedown. Lovely. Blog Comment of the Week This week’s best comment comes from Dave in response to Format and Data Preserving Encryption: Ok, First let me start out by admitting I am almost entirely wrong 😉 Now we have that out of the way… I was correct in asserting the resulting reduced cypher is no more secure than a native cypher of that blocksize, but failed to add that the native cypher must have the same keyspace size as the cypher being reduced – for this reason, DES was a bad example (but 128 bit DESX, which is xor(k1,DES(k2,XOR(k1,Plaintext))) would be a good one. I was in error however asserting that, in practical terms, this in any way matters – in fact, the size of the keyspace (not the blocksize) is the overwhelming factor due to the physical size of another space – the space of all possible mappings that could result from the key schedule. it is

In our last post in this series, we covered the cloud implications of the Create phase of the Data Security Cycle. In this post we’re going to move on to the Store phase. Please remember that we are only covering technologies at a high level in this series on the cycle; we will run a second series on detailed technical implementations of data security in the cloud a little later. Definition Store is defined as the act of committing digital data to structured or unstructured storage (database vs. files). Here we map the classification and rights to security controls, including access controls, encryption and rights management. I include certain database and application controls, such as labeling, in rights management – not just DRM. Controls at this stage also apply to managing content in storage repositories (cloud or traditional), such as using content discovery to ensure that data is in approved/appropriate repositories. Steps and Controls Control Structured/Application Unstructured Access Controls DBMS Access Controls Administrator Separation of Duties File System Access Controls Application/Document Management System Access Controls Encryption Field Level Encryption Application Level Encryption Transparent Database Encryption Media Encryption File/Folder Encryption Virtual Private Storage Distributed Encryption Rights Management Application Logic Tagging/Labeling Tagging/Labeling Enterprise DRM Content Discovery Cloud-Provided Database Discovery Tool Database Discovery/DAM DLP/CMP Discovery Cloud-Provided Content Discovery DLP/CMP Content Discovery Access Controls One of the most fundamental data security technologies, built into every file and management system, and one of the most poorly used. In cloud computing environments there are two layers of access controls to manage – those presented by the cloud service, and the underlying access controls used by the cloud provider for their infrastructure. It’s important to understand the relationship between the two when evaluating overall security – in some cases the underlying infrastructure may be more secure (no direct back-end access) whereas in others the controls may be weaker (a database with multiple-tenant connection pooling). DBMS Access Controls: Access controls within a database management system (cloud or traditional), including proper use of views vs. direct table access. Use of these controls is often complicated by connection pooling, which tends to anonymize the user between the application and the database. A database/DBMS hosted in the cloud will likely use the normal access controls of the DBMS (e.g., hosted Oracle or MySQL). A cloud-based database such as Amazon’s SimpleDB or Google’s BigTable comes with its own access controls. Depending on your security requirements, it may be important to understand how the cloud-based DB stores information, so you can evaluate potential back-end security issues. Administrator Separation of Duties: Newer technologies implemented in databases to limit database administrator access. On Oracle this is called Database Vault, and on IBM DB2 I believe you use the Security Administrator role and Label Based Access Controls. When evaluating the security of a cloud offering, understand the capabilities to limit both front and back-end administrator access. Many cloud services support various administrator roles for clients, allowing you to define various administrative roles for your own staff. Some providers also implement technology controls to restrict their own back-end administrators, such as isolating their database access. You should ask your cloud provider for documentation on what controls they place on their own administrators (and super-admins), and what data they can potentially access. File System Access Controls: Normal file access controls, applied at the file or repository level. Again, it’s important to understand the differences between the file access controls presented to you by the cloud service, vs. their access control implementation on the back end. There is an incredible variety of options across cloud providers, even within a single SPI tier – many of them completely proprietary to a specific provider. For the purposes of this model, we only include access controls for cloud based file storage (IaaS), and the back-end access controls used by the cloud provider. Due to the increased abstraction, everything else falls into the Application and Document Management System category. Application and Document Management System Access Controls: This category includes any access control restrictions implemented above the file or DBMS storage layers. In non-cloud environments this includes access controls in tools like SharePoint or Documentum. In the cloud, this category includes any content restrictions managed through the cloud application or service abstracted from the back-end content storage. These are the access controls for any services that allow you to manage files, documents, and other ‘unstructured’ content. The back-end storage can consist of anything from a relational database to flat files to traditional storage, and should be evaluated separately. When designing or evaluating access controls you are concerned first with what’s available to you to control your own user/staff access, and then with the back end to understand who at your cloud provider can see what information. Don’t assume that the back end is necessarily less secure – some providers use techniques like bit splitting (combined with encryption) to ensure no single administrator can see your content at the file level, with strong separation of duties to protect data at the application layer. Encryption The most overhyped technology for protecting data, but still one of the most important. Encryption is far from a panacea for all your cloud data security issues, but when used properly and in combination with other controls, it provides effective security. In cloud implementations, encryption may help compensate for issues related to multi-tenancy, public clouds, and remote/external hosting. Application-Level Encryption: Collected data is encrypted by the application, before being sent into a database or file system for storage. For cloud-based applications (e.g., public or private SaaS) this is usually the recommended option because it protects the data from the user all the way down to storage. For added security, the encryption functions and keys can be separated from the application itself, which also limits the access of application administrators to sensitive data. Field-Level Encryption: The database management system encrypts fields within a database, normally at the column level. In cloud implementations you will generally want to encrypt data at the application

As part of the interview process for our intern program, we asked candidates to prepare a couple slides and write a short blog post on a technical subject. Rich and I debated different subjects for the candidates to research and report on, but we both chose “XML Security”. It is a very broad subject that gave the candidates some latitude, and there was not too much research out there to read up on. It also happened to be a subject that neither Rich nor I had researched prior to the interviews. We did not want to bring biases to the subject, and we wanted to focus on presentation rather than content, to see where the candidates led us. This was not to be a full-blown research effort where we expected the candidate to take a month to dig into the subject, but rather meant a cursory effort to identify the highlights. We figured it would take between 2-10 hours depending upon the candidate’s background. Listening to the presentations by the candidates was fun as we had no idea what they would focus on or what viewpoint they would present. Each brought a different vision of what constituted XML security. Some focused on one aspect of the problem space, such as web security. Some provided an academic overview of XML issues, while others offered depth on seemingly random aspects. All of the presentation were different from each other, and far different than what I would have created, plus some of their statements were counter to my understanding of XML security issues. But the quality of the research was not really what was important – rather how they approached the task and communicated their findings. I cannot share those with you, but I found the subject interesting enough that I thought Securosis should provide some coverage on this topic, so I decided to go through the process myself. The slide deck is in the research library for you to check out if it interests you. It’s not comprehensive, but I think it covers the basics. I probably would come in second if I had been part of the competition, so it’s lucky I have already been vetted. Per my Friday Summary comment, I may learn more from this process than the interns! Share:

Vendor Myopia (ven.dor my.o.pi.a) n. Inability to perceive competitive objects clearly. Abnormality in judgement resulting from drinking one’s own kool-aid. Suspect reasoning due to lack of broader perspective or omission of external facts. Distant objects may appear blurred due to strong focus on one’s own widget. Perception that new color and font define a new market. Symptoms may also include the sensation of being alone in a crowded space, or feelings of product-induced euphoria. Happy Monday! Share: