Login  |  Register  |  Contact
Tuesday, September 29, 2009

Digital Ant Swarms

By Adrian Lane

A friend of mine emailed yesterday, admonishing me for not writing about the Digital Ants concept discussed on Dailytech. I think it’s because he wanted me to call B.S. on the story. It seems that some security researchers are trying to mimic the behavior of ants in computer defenses to thwart attackers. From the article:

Security researchers found inspiration in the common ant. Describes Wake Forest University Professor of Computer Science Errin Fulp, “In nature, we know that ants defend against threats very successfully. They can ramp up their defense rapidly, and then resume routine behavior quickly after an intruder has been stopped. We were trying to achieve that same framework in a computer system.”

WFU created digital “ants” – utilities that migrate from computer to computer over networks searching for threats. When one locates a threat, others congregate on it, using so-called “swarm intelligence”. The approach allows human researchers to quickly identify and quarantine dangerous files by watching the activity of the ants.

This seems like nature’s reaction du jour. Many have written about the use of ‘helpful viruses’ and viral technologies (cheese worm (PDF), anti-porn worm, wifi worm, etc.) to combat hostile computer worms and viruses. Helpful virus code finds exploits the same way a harmful virus would, but then patches the defect – curing the system instead of reproducing. But the helpful viruses tend to become an attack vector of themselves, or ‘fix’ things in very unintended ways, compounding the problem.

Ants behave very differently than viruses. Real ants fill a dual role, both gathering food and defending the hive. Besides access controls, few security products can make this claim. Second, ants can detect threats. Software and systems are only marginally effective at this, even with different pieces operating (hopefully) as a coordinated unit. Finally, ants bite. They have the ability to defend themselves individually, as well as work effectively as a group. In either case they post a strong deterrent to attack, something seldom seen in the digital domain.

Conceptually I like the idea of being able to systemically respond to a threat, with different parts of the system reacting to different threats. On the threat detection side this makes sense as well, as many subtle attacks require information gathered from different parts of the system to be able to identify them. SEM/SIEM has slowly been advancing this science for some time now, and it is a core piece of the ADMP concept for web application security, where the detection and prevention is systemic. It is not the idea of a swam that makes it effective, but holistic detection in combination with multiple, different reactions by systems that can provide a meaningful response. So I am not saying ant swarming behavior applied to computer security is B.S., but “ramping up responses” is not the real problem – detection and appropriate reactions are.

—Adrian Lane

Monday, September 28, 2009

IDM: It’s A Process

By David Mortman

IDM fascinates me, if only because it is such an important base for a good security program. Despite this, many organizations (even ones with cutting edge technology) haven’t really focused on solving the issues around managing users’ identity. This is, no doubt, in part due to the fact that IDM is hard in the real world. Businesses can have hundreds if not thousands of applications (GM purportedly had over 15,000 apps at one point) and each application itself can have hundreds or thousands of roles within it. Combine this with multiple methods of authentication and authorization, and you have a major problem on your hands which makes digging into the morass challenging to say the least.

I also suspect IDM gets ignored because it does not warrant playing with fun toys, so as a result, doesn’t get appropriate attention from the technophiles. Don’t get me wrong – there are some great technologies out there to help solve the problem, but no matter what tools you have at your disposal, IDM is fundamentally not a technology problem but a process issue. I cannot possibly emphasize this enough. In the industry we love to say that security is about People, Process, and Technology. Well, IDM is pretty much all about Process, with People and Technology supporting it. Process is an area that many security folks have trouble with, perhaps due to lack of experience. This is why I generally recommend that security be part of designing the IDM processes, policies, and procedures – but that the actual day to day stuff be handled by the IT operations teams who have the experience and discipline to make it work properly.

DS had a great comment on my last post, which is well worth reading in its entirety, but today there is one part I’d like to highlight because it nicely shows the general process that should be followed regardless of organization size:

While certainly not exhaustive, the above simple facts can help build a closed loop process.

  1. When someone changes roles, IT gets notified how.
  2. A request is placed by a manager or employee to gain access to a system.
  3. If employee request, manager must(?) approve.
  4. If approved as “in job scope” by manager, system owner approves.
  5. IT (or system owner in decentralized case) provisions necessary access. Requester is notified.

Five steps, not terribly complicated and easy to do, and essentially what happens when someone gets hired. For termination, all you really need are steps 1, 2, and 5 – but in reverse. This process can even work in large decentralized organizations, provided you can figure out (a) the notification/request process for access changes and (b) a work flow process for driving through the above cycle.

(a) is where the Info Sec team has to get outside the IT department and talk to the business. This is huge. I’ve talked in the past about the need for IT to understand the business and IDM is a great example of why. This isn’t directly about business goals or profit/loss margins, but rather about understanding how the business operates on a day to day basis. Don’t assume that IT knows what applications are being used – in many organizations IT only provides the servers and sometimes only the servers for the basic infrastructure. So sit down with the various business units and find out what applications/services are being used and what process they are using today to provision users, who is handling that process, and what changes if any they’d like to see to the process. This is an opportunity to figure out which applications/services need to be part of your IDM initiative (this could be compliance, audit, corporate mandate etc.) and which ones currently aren’t relevant. It has the added benefit of discovering where data is flowing, which is key to not only compliance mandates under HIPAA, SOX, and the European Data Directive (to name a few), but also incredibly handy when electronic discovery is necessary. One all this data has been gathered, you can evaluate the various technologies available and see if they can help. This could be anything from a web app to manage change requests, to workflow (see below), to a full-scale automated access provisioning and de-provisioning system, driven by the approval process.

Once you’ve solved (a), (b) is comparatively straightforward and another place where technology can make life easier. The best part is that your organization likely has something like this deployed for other reasons, so the additional costs should be relatively low. Once your company/department/university/etc. grows to a decent size and/or starts to decentralize, manually following the process will become more and more cumbersome, especially as the number of supported applications goes up. A high rate of job role changes within the organization has a similar effect. So some sort of software that automatically notifies employees when they have tasks will greatly streamline the process and help people get the access they need much more quickly. Workflow software is also a great source of performance metrics and can help provide the necessary logs when dealing with audit or compliance issues.

As I mentioned above, the business reality for many organizations is far from pristine or clear, so in my next post I’ll explore more those issues in more depth. For now, suffice it to say that until you address those issues, the above process will work best with a small company with fewer apps/auth methods. If you are involved in a larger more complex organization, all is not lost. In that case, I highly recommend that you not try to fix things all at once, but start with one a group or sub-group within the organization and roll out there first. Once you’ve worked out the kinks, you can roll in more and more groups over time.

—David Mortman

Friday, September 25, 2009

Friday Summary - September 25, 2009

By Rich

I get some priceless email on occasion, and I thought this one was too good not to pass along. Today’s Friday summary introduction is an anonymous guest post … if it missed any cliches I apologize in advance.

Internal Memorandum

To: Employees
From: Mega-Corp Executive Team
Subject: Messaging
Data: Friday, September 25th, 2009

Due to growing media scrutiny and misquotes in major trade publication (because you people can’t get the pitch right), we ask you to be cautious in dealing with the press and analysts. Please. All we ask is that our employees “stay on message.” We, Mega-Corp, Inc., pay (way too much) to have (young imbecilic twits at) large advertising agencies (put down their drugs and alcohol long enough to) work closely with our (also over-paid) CMO to carefully develop media strategies to effectively leverage our assets to increase consumer awareness and increase sales, thus generating a win-win situation for all. We cannot allow rogue employees to torpedo our finely crafted multi-media approach by deviating from the platforms that have been developed. This will ensure that all of our clients receive the same message. It is also designed to increase brand awareness by striking just the right balance between being edgy enough to appeal to the hipper, young crowd while at the same time conveying stability to our long-term clients. It is especially important at the present, due to current market conditions. While our competitors are focused on their competitive disadvantages, we see this current market as a great opportunity for growth. Our marketing campaign has thus placed its emphasis on all of the added benefits that the new product line now offers. We will not allow iconoclastic employees to remain fixated on their complaints that we have increased prices. We believe that the new price line is a bargain for the new features that we have added, and our marketing campaign is designed to educate our clients and potential clients about the new features that they will be receiving. It does not help when our branch-office employees continuously snipe that the clients do not want the new features. That is only true because we have failed to educate them sufficiently about the benefits of those features. We are confident that if we all work together, to remain on message and educate our clients and potential clients about what we have to offer, we can expect double-digit growth over the next eight quarters. In do so we that our competitors will not be able to catch up to our technological advances during that period of time and thus we will not be forced to offer new products for the next 30 months. In fact, we are so confident of this that we have right-sized our R&D department, thus proving once again that we can be lean and mean. I also know that many of you have seen reports that suggest we plan further layoffs of up to 30%. We have no idea where the 30% figure came from and can say without equivocation that no such reduction is currently planned. Of course we will always remain nimble enough to provide reasonable value to our shareholders but I know that all of you believe that is our most sacred obligation and would want nothing less. In concluding, I cannot stress enough the importance of staying on message and delivering a united theme to the public as we continue to unveil our marketing strategy across so many different media platforms, including the new emphasis on social media. There can be no doubt that our innovative use of Twitter will in itself dramatically increase sales over the next several quarters. I look forward to seeing those who do remain with us next year when we gather via video-conferencing for the annual employee meeting.

Thank you for your attention in this matter (or you will be part of the next 30%),

Mega-Corp Executive Team

The Death Star,
Moon of Endor,
Outer Rim

And with that, on to the Friday Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Top News and Posts

Blog Comment of the Week

This week’s best comment comes from ds in response to Incomplete Thought: Why is Identity and Access Management Hard?:

I’d argue that most companies have both technology and process problems and cannot (but try to) solve bad process with (often dubious) technology, hence they fail and assume it was the fault of their slick IDM.

I also think that there is a major difference in what a top line IDM product offers when compared to a more niche workflow powered provisioning system, and that the vendors in this market don’t highlight this well enough (e.g., Quest’s ARS may be just the trick for a SMB using only AD for AAA, but they want to sell against the big boys with virtual directories and other complex solutions). Dividing this market makes sense.

After all the dust settles, IDM is a perfect example case of a process problem that could be, but doesn’t have to be, supported by technology to be more efficient. Companies need to nail down some key challenges first:

-How do IT and HR find out about job change activities (joining, moving, leaving). Don’t assume HR will know… sometimes a job change is simply an informal promotion or an assignment to a special project. If there isn’t a solid notification route, fix that first. Doing so builds relationships, surfaces problems that support the effort and ensure buy in at all levels. Then move on.

-What is the motivation for better identity management (e.g., regulatory or commercial compliance?). Knowing this can help constrain initial scope. Without limits, the project will grow too fast and fail.

-What systems are in scope.

-Who in the business “owns” those systems.

-Who in the business “uses” those systems (and why/how).

While certainly not exhaustive, the above simple facts can help build a closed loop process.

  1. When someone changes roles, IT gets notified <how>.
  2. A request is placed by <manager or employee> to gain access to a system
  3. If employee request, manager <must?> approves
  4. If approved as “in job scope” by manager, system owner approves
  5. IT (or system owner in decentralized case) provisions necessary access. Requestor is notified.

Process for new hires, terminations and other elements in the lifecycle are just as easy to think through. Org wrinkles may make them more or less complicated, but essentially the point is to have an approval process where the right folks make the decision. Knowing and keeping track of those folks is a challenge, but not impossible.

Long story short, don’t think technology until the process is in place.

(or not so short … but well stated)


Thursday, September 24, 2009

Database Encryption Benchmarking

By Adrian Lane

Database benchmarking is hard to do. Any of you who followed the performance testing wars of the early 90’s, or the adoption and abuse of TPC-C and TPC-D, know that the accuracy of database performance testing is a long-standing sore point. With database encryption the same questions of how to measure performance rear their heads. But in this case there are no standards. That’s not to say the issue is not important to customers – it is. You tell a customer encryption will reduce throughput by 10% or more, and your meeting is over. End of discussion. Just the fear of potential performance issues has hindered the adoption of database encryption.

This is why it is incredibly important for all vendors who offer encryption for databases (OS/file system encryption vendors, drive manufacturers, database vendors, etc.) to be able to say their impact is below 10%. Or as far below that number as they can. I am not sure where it came from, but it’s a mythical number in database circles. Throughout my career I have been doing database performance testing of one variety or another. Some times I have come up with a set of tests that I thought exercised the full extent of the system. Other times I created test cases to demonstrate high and low water marks of system performance. Sometimes I captured network traffic at a customer site as a guide, so I could rerun those sessions against the database to get a better understanding of real world performance. But it is never a general use case – it’s only an approximation for that customer, approximating their applications.

When testing database encryption performance several variables come into play:

What queries?

Do users issue 50 select statements for every insert? Are the queries a balance of select, inserts, and deletes? Do I run the queries back to back as fast as I can, like a batch job, or do I introduce latency between requests to simulate end users? Do I select queries that only run against encrypted data, or all data? Generally when testing database performance, with or without encryption, we select a couple different query profiles to see what types of queries cause problems. I know from experience I can create a test case that will drop throughput by 1%, and another that will drop it by 40% (I actually had a junior programmer unknowingly design and deploy a query with a cartesian that crashed our live server instantly, but that’s another story).

What type of encryption?

Full disk? Tablespace? Column Level? Table level? Media? Each variant has advantages and disadvantages. Even if they are all using AES-256, there will be differences in performance. Some have hardware acceleration; some limit the total amount of encrypted data by partitioning data sets; others must contend for thread, memory, and processor resources. Column level encryption encrypts less data than full disk encryption, so this should be an apples to apples comparison. But if the encrypted column is used as an index, it can have a significant impact on query performance, mitigating the advantage.

What percentage of queries are against encrypted data?

Many customers have the ability to partition sensitive data to a database or tablespace that is much smaller than the overall data set. This means that many queries do not require encryption and decryption, and the percentage impact of encryption on these systems is generally quite good. It is not unreasonable to see that encryption only impacts the entire database by 1% over the entire database in a 24 hour period, while reduces throughput against the encrypted tablespace by 25%.

What is the load on the system?

Encryption algorithms are CPU intensive. They take some memory as well, but it’s CPU you need to pay attention to. With two identical databases, you can get different performance results if the load on one system is high. Sounds obvious, I know, but this is not quite as apparent as you might think. For example, I have seen several cases where the impact of encryption on transactional throughput was a mere 5%, but the CPU load grew by 40%. If the CPUs on the system do not have sufficient ‘headroom’, you will slow down encryption, overall read/write requests (both encrypted and unencrypted), and the system’s transactional throughput over time. Encryption’s direct slowdown of encrypted traffic is quite different than its impact on overall system load and general responsiveness.

How many cryptographic operations can be accomplished during a day is irrelevant. How many cryptographic operations can be accomplished under peak usage during the day is a more important indicator. Resource consumption is not linear, and as you get closer to the limits of the platform, performance and throughput degrade and a greater than linear rate.

How do you know what impact database encryption will have on your database? You don’t. Not until you test. There is simply no way for any vendor of a product to provide a universal test case. You need to test with cases that represent your environment. You will see numbers published, and they may be accurate, but they seldom reflect your environment and are so are generally useless.

—Adrian Lane

A Bit on the State of Security Metrics

By Rich

Everyone in the security industry seems to agree that metrics are important, but we continually spin our wheels in circular debates on how to go about them. During one such email debate I sent the following. I think it does a reasonable job of encapsulating where we’re at:

  1. Until Skynet takes over, all decisions, with metrics or without, rely on human qualitative judgement. This is often true even for automated systems, since they rely on models and decision trees programmed by humans, reflecting the biases of the designer.
  2. This doesn’t mean we shouldn’t strive for better metrics.
  3. Metrics fall into two categories – objective/measurable (e.g., number of systems, number of attacks), and subjective (risk ratings). Both have their places.
  4. Smaller “units” of measurement tend to be more precise and accurate, but more difficult to collect and compile to make decisions… and at that point we tend to introduce more bias. For example, in Project Quant we came up with over 100 potential metrics to measure the costs of patch management, but collecting every one of them might cost more than your patching program. Thus we had to identify key metrics and rollups (bias) which also reduces accuracy and precision in calculating total costs. It’s always a trade-off (we’d love to do future studies to compare the results between using all metrics vs. key metrics to seeing if the deviation is material).
  5. Security is a complex system based on a combination of biological (people) and computing elements. Thus our ability to model will always have a degree of fuzziness. Heck, even doctors struggle to understand how a drug will affect a single individual (that’s why some people need medical attention 4 hours after taking the blue pill, but most don’t).
  6. We still need to strive for better security metrics and models.

My personal opinion is that we waste far too much time on the fuzziest aspects of security (ALE, anyone?), instead of focusing on more constrained areas where we might be able to answer real questions. We’re trying to measure broad risk without building the foundations to determine which security controls we should be using in the first place.


Stupid FUD: Weird Nominum Interview

By Rich

We see a lot of FUD on a daily basis here in the security industry, and it’s rarely worth blogging about. But for whatever reason this one managed to get under my skin.

Nominum is a commercial DNS vendor that normally targets large enterprises and ISPs. Their DNS server software includes more features than the usual BIND installation, and was originally designed to run in high-assurance environments. From what I know, it’s a decent product. But that doesn’t excuse the stupid statements from one of their executives in this interview that’s been all over the interwebs the past couple days:

Q: In the announcement for Nominum’s new Skye cloud DNS services, you say Skye ‘closes a key weakness in the internet’. What is that weakness?

A: Freeware legacy DNS is the internet’s dirty little secret – and it’s not even little, it’s probably a big secret. Because if you think of all the places outside of where Nominum is today – whether it’s the majority of enterprise accounts or some of the smaller ISPs – they all have essentially been running freeware up until now. Given all the nasty things that have happened this year, freeware is a recipe for problems, and it’s just going to get worse.

Q: Are you talking about open-source software?

A: Correct. So, whether it’s Eircom in Ireland or a Brazilian ISP that was attacked earlier this year, all of them were using some variant of freeware. Freeware is not akin to malware, but is opening up those customers to problems.

By virtue of something being open source, it has to be open to everybody to look into. I can’t keep secrets in there. But if I have a commercial-grade software product, then all of that is closed off, and so things are not visible to the hacker.

Nominum software was written 100 percent from the ground up, and by having software with source code that is not open for everybody to look at, it is inherently more secure.

I would respond to them by saying, just look at the facts over the past six months, at the number of vulnerabilities announced and the number of patches that had to made to Bind and freeware products. And Nominum has not had a single known vulnerability in its software.

The word “bullsh**” comes to mind. Rather than going on a rant, I’ll merely include a couple of interesting reference points:

  • Screenshot of a cross-site scripting vulnerability on the Nominum customer portal.
  • Link to a security advisory in 2008. Gee, I guess it’s older than 6 months, but feel free to look at the record of DJBDNS, which wasn’t vulnerable to the DNS vuln.
  • As for closed source commercial code having fewer vulnerabilities than open source, I refer you to everything from the recent SMB2 vulnerability, to pretty much every proprietary platform vs. FOSS in history. There are no statistics to support his position. Okay, maybe if you set the scale for 2 weeks. That might work, “over the past 2 weeks we have had far fewer vulnerabilities than any open source DNS implementation”.

Their product and service are probably good (once they fix that XSS, and any others that are lurking), but what a load of garbage in that interview…


Wednesday, September 23, 2009

Database Encryption Misconceptions

By Adrian Lane

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.

—Adrian Lane

Tuesday, September 22, 2009

Cloud Data Security: Archive and Delete (Rough Cut)

By Rich

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.



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

EncryptionDatabase EncryptionTape Encryption
Storage Encryption
Asset ManagementAsset Management


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.

  1. 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.
  2. 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?
  3. 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 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

Crypto-ShreddingEnterprise Key Management
Secure DeletionDisk/Free Space Wiping
Physical DestructionPhysical Destruction
Content DiscoveryDatabase DiscoveryDLP/CMP Discovery
Storage/Data Classification Tools
Electronic Discovery


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 Destruction

These options is only available when you have low-level administrative access to the physical storage. It includes software or hardware designed to destroy data on hard drives and other media, or physical destruction of the drives. At a minimum the tool should overwrite all writable space on the media 1-3 times, and 7 times is recommended for sensitive data. Merely formatting over data is not sufficient. Secure wiping is highly recommended for any systems with sensitive data that are sold or reused, especially laptops and desktops. File-level secure deletion tools exist for when it’s necessary to destroy just a portion of data in active storage, but are not as reliable as a full media wipe.

For physical destruction (again, assuming you have access to the drives), there are two options:

  1. Degaussing: Use of strong magnets to scramble magnetic media like hard drives and backup tapes. Dedicated solutions should be used to ensure data is unrecoverable, and it’s highly recommended you confirm the efficiency of a degaussing tool by randomly performing forensic analysis on wiped media.
  2. Physical Destruction: Complete physical destruction of storage devices, focusing on shredding the actual magnetic media (platters or tape).

Due to the abstraction involved in cloud computing, these will often not be available, although your provider may include them as part of their procedures for management of their drives. When managing a private/internal cloud, you can include physical media wiping or destruction as part of your procedures for managing drives removed from active service. In IaaS deployments, you may retain the low level access to overwrite data in individual virtual machines or storage.

Content Discovery

When truly sensitive data reaches end-of-life, you need to make sure that the destroyed data is really destroyed. Use of content discovery tools helps ensure that no copies or versions of the data remain accessible in the enterprise. Considering how complex our storage, archive, and backup strategies in the cloud are today, it is impossible to absolutely guarantee the data is unrecoverable, but content discovery does reduce the risk of retrieval.

As with content discovery in the Store phase, these tools are only effective if they have access to the storage infrastructure; they cannot work through an application interface unless they are built into the application.

For details on Database Discovery and DLP/CMP please see the Store phase. There are two additional technology categories we also see used for this purpose:

  1. Storage/Data Classification and Search: These are tools typically used and managed by enterprise storage teams. Their content analysis is generally less detailed than DLP/CMP tools, but can be helpful for broad searches for stored data. Storage/Data classification tools are third-party tools which crawl a storage environment and use rule sets (usually keywords and regular expressions) to apply metadata tags to files. If your cloud storage offers standard file access, they may be helpful. Search is either built into the application or a third-party tool that indexes stored data. While these are not ideal tools for content discovery to ensure data destruction, search may be your only option in some SaaS deployments.
  2. Electronic Discovery: Tools dedicated to the electronic discovery of data for legal proceedings. Likely the same tools that will be used to search for destroyed data if there’s ever reason to attempt recovery in the future. As with most of the tools in this section, they are not cloud specific and may not be an option.

Cloud SPI Tier Implications

Software as a Service (SaaS)

As with Archive, your data destruction options are completely dependent on your provider. Typically you will be limited to some level of deletion, although in some applications crypto-shredding may be an option. What’s most important is to understand how your provider handles data destruction, and to obtain any documentation and service level agreements that are available. Search will usually be your best content discovery option.

Platform as a Service (PaaS)

For data stored with your PaaS provider, unless you have file system access of some sort you will face the same limitations as with SaaS providers. If you encrypt data on your side before sending it to the platform, crypto-shredding is a good option. Any data stored in your environment is obviously easier to destroy, since you have greater control of the infrastructure and physical media. Content discovery may be an option, but this depends completely on how your PaaS-based application is designed.

Infrastructure as a Service (IaaS)

For cloud data storage (database and file based), crypto-shredding is likely your best option. For other infrastructure deployments, particularly those with virtual machines and disks, you may be able to overwrite stored data. Content discovery using DLP/CMP will probably work, again depending on the details of your deployment.


Monday, September 21, 2009

Cloud Data Security: Share (Rough Cut)

By Rich

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.


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

Activity Monitoring and EnforcementDatabase Activity Monitoring
Cloud Activity Monitoring/Logs
Application Activity Monitoring
Network DLP/CMP
Endpoint DLP/CMP
EncryptionNetwork/Transport Encryption
Application-Level Encryption
Email Encryption
File Encryption/EDRM
Network/Transport Encryption
Logical ControlsApplication Logic
Row Level Security
Application Securitysee 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.
  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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.


In the Store phase we covered encryption for protecting data at rest. Here we expand to cover data in motion. Keep in mind that additional encryption is only needed if the data would otherwise be exchanged as plain text – there’s no reason or need to redundantly re-encrypt already encrypted network traffic.

  1. Network/Transport Encryption: As data moves between applications, databases, the cloud, and other locations, the network connections should be encrypted using a standard network-layer protocol. For larger systems where this could affect performance, hardware acceleration is recommended. Virtual Private Networks are useful for encrypting data moving in and out of clouds in certain deployment models.
  2. Application Level Encryption: As we discussed in the Store phase, data encrypted by an application on collection is ideally protected as it moves throughout the rest of the application stack. Don’t forget that at some point the data is probably decrypted to be used, so it’s important to map the data flow and determine potential weak points.
  3. Email Encryption: Email encryption isn’t cloud-specific, but since email is one of the most common ways of exchanging data, including reports and data dumps from cloud services, encryption is often relevant for cloud deployments – especially when built into the cloud application/service.
  4. File Encryption and Enterprise Digital Rights Management: These technologies were discussed in detail in the Store phase. They also apply in the Share phase since encrypted files or DRM protected documents are still protected as they are moved, not just in storage. For cloud security purposes, encryption or EDRM may be built into various data exchange mechanisms – with EDRM for user files, and encryption as a more general option.

Logical Controls

We discussed Logical Controls in the Use phase, and they can also be used to manage data exchange, not just transaction activity.

Application Security

As with logical controls, we discussed Application Security in the Use phase. Again, a full discussion of cloud application security issues is beyond the scope of this post, and we recommend you read the Cloud Security Alliance Guidance for more details.

Cloud SPI Tier Implications

Software as a Service (SaaS)

Data sharing in SaaS deployments is encapsulated within the application, is connected to back-end external applications, or involves generating data dumps to transfer the content to a local system. Application and logical controls are your best defense, combined with encryption to cover any data transfers. Once data leaves the SaaS application, DLP/CMP may be useful for tracking the content, or to protect it from leaving your managed environment. DLP/CMP is also useful to determine if the data should go to the cloud at all, and ensure that any data is transferred conforms to policy requirements. Since most SaaS solutions rely principally on HTTP for communications/access, most off-the-shelf DLP tools will work.

Platform as a Service (PaaS)

Depending on your PaaS deployment, it’s again likely that application logic will be your best security option, followed by proper use of encryption to secure communications. You may also be able to deploy monitoring in your application that connects to the PaaS provider if they don’t offer a desired level of monitoring/logging, but that will only track connections from your managed environment (someone trying to compromise the PaaS directly, without going through your application, won’t appear in your application logs).

Infrastructure as a Service (IaaS)

VPNs are commonly used to protect communications to IaaS infrastructure, both internal and external. When VPNs aren’t an option, such as with many types of cloud-based storage, SSL/TLS network encryption is usually available. Any additional Share controls rely completely on what you can deploy in the infrastructure. Any monitoring/auditing such as DLP require some sort of network traffic to analyze, or an alternative hook, such as a local agent.


FCC Wants ‘Open Internet’ Rules for Wireless

By Adrian Lane

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.

—Adrian Lane

Incomplete Thought: Why Is Identity and Access Management Hard?

By David Mortman

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.

—David Mortman

Friday, September 18, 2009

Cloud Data Security: Use (Rough Cut)

By Rich

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.


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

Activity Monitoring and EnforcementDatabase Activity Monitoring
Application Activity Monitoring
Endpoint Activity Monitoring
File Activity Monitoring
Portable Device Control
Endpoint DLP/CMP
Cloud-Client Logs
Rights ManagementLabel Security
Enterprise DRM
Logical ControlsApplication Logic
Row Level Security
Application Securitysee 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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. Endpoint DLP: Endpoint Data Loss Prevention/Content Monitoring and Filtering tools that monitor and restrict usage of data through content analysis and centrally administered policies. While current capabilities vary highly among products, tools should be able to monitor what content is being accessed by an endpoint, any file storage or network transmission of that content, and any transfer of that content between applications (cut/paste). For performance reasons endpoint DLP is currently limited to a subset of enforcement policies (compared to gateway products) and endpoint-only products should be used in conjunction with network protection in most cases (which we will discuss in the next phase of the lifecycle).

At this time, most activity monitoring and enforcement needs to be built into the cloud infrastructure to provide value. We often see some degree of application activity monitoring built into SaaS offerings, with some logging available for cloud databases and file storage. The exception is IaaS, where you may have full control to deploy any security tool you like, but will need to account for the additional complexities of deploying in virtual environments which impact the ability to route and monitor network traffic.

Rights Management

We covered the rights management options in the Create and Store sections. They are also a factor in the this phase (Use), since this is another point where they can be actively enforced during user interaction

In the Store phase rights are applied as data enters storage, and access limitations are enforced. In the Use phase, additional rights are controlled, such as data modification, export, or more-complex usage patterns (like printing or copying).

Logical Controls

Logical controls expand the brute-force restrictions of access controls or EDRM that are based completely on who you are and what you are accessing. Logical controls are implemented in applications and databases and add business logic and context to data usage and protection. Most data-security logic controls for cloud deployments are implemented in application logic (there are plenty of other logical controls available for other aspects of cloud computing, but we are focusing on data security).

  1. Application Logic: Enforcing security logic in the application through design, programming, or external enforcement. Logical controls are one of the best options for protecting data in any kind of cloud-based application.
  2. Object (Row) Level Security: Creating a ruleset restricting use of a database object based on multiple criteria. For example, limiting a sales executive to only updating account information for accounts assigned to his territory. Essentially, these are logical controls implemented at the database layer, as opposed to the application layer. Object level security is a feature of the Database Management System and may or may not be available in cloud deployments (it’s available in some standard DBMSs, but is not currently a feature of any cloud-specific database system).
  3. Structural Controls: Using database design features to enforce security. For example, using the database schema to limit integrity attacks or restricting connection pooling to improve auditability. You can implement some level of structural controls in any database with a management system, but more advanced structural options may only be available in robust relational databases. Tools like SimpleDB are quite limited compared to a full hosted DBMS. Structural controls are more widely available than object level security, and since they don’t rely on IP addresses or external monitoring they are a good option for most cloud deployments. They are particularly effective when designed in conjunction with application logic controls.

Application Security

Aside from raw storage or plain hosted database access, most cloud deployments involve enterprise applications. Effective application security is thus absolutely critical to protect data, and often far more important than any access controls or other protections. A full discussion of cloud application security issues is beyond the scope of this post, and we recommend you read the Cloud Security Alliance Guidance for more details.

Cloud SPI Tier Implications

Software as a Service (SaaS)

Most usage controls in SaaS deployments are enforced in the application layer, and depend on what’s available from your cloud provider. The provider may also enforce additional usage controls on their internal users, and we recommend you ask for documentation if it’s available. In particular, determine what kinds of activity monitoring they perform for internal users vs. cloud-based users, and if those logs are ever available (such as during the investigation of security incidents). We also often see label security in SaaS deployments.

Platform as a Service (PaaS)

Depending on your PaaS deployment, it’s likely that application logic will be your best security option, followed by activity monitoring. If your PaaS provider doesn’t provide the level of auditing you would like, you may be able to capture activity within your application before it makes a call to the platform, although this won’t capture any potential direct calls to the PaaS that are outside your application.

Infrastructure as a Service (IaaS)

Although IaaS technically offers the most flexibility for deploying your own security controls, the design of the IaaS may inhibit deployment of many security controls. For example, monitoring tools that rely on network access or sniffing may not be deployable. On the other hand, your IaaS provider may include security controls as part of the service, especially some degree of logging and/or monitoring.

Database control availability will depend more on the nature of the infrastructure – as we’ve mentioned, full hosted databases in the cloud can enforce many, if not all, of the traditional database security controls.

Endpoint-based usage controls are enforceable in managed environments, but are only useful in private cloud deployments where access to the cloud can be restricted to only managed endpoints.


Friday Summary - September 18, 2009

By Rich

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:


Webcasts, Podcasts, Outside Writing, and Conferences

  • Rich and Adrian presented at the [Data Protection Decisions](http://infosecuritydecisions.techtarget.com/dataprotectiondecisions/html/index.html conference) 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

Other Securosis Posts

Project Quant Posts

Favorite Outside Posts

Top News and Posts

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 easy to determine that, for a keyspace of n(ks) bits, there are 2^n(ks) possible keys.

correspondingly, for an input (block size) space of n(bs) bits, there are 2^n(bs) possible inputs (and hence, 2^n(bs) outputs)

by implication therefore, there are 2^n(bs) FACTORIAL possible mappings - meaning the number of mappings produced by the key schedule is very sparse indeed; a reasonable reading of even a fairly small DPE block space (for example the CC personal security code, which is three decimal digits) would be 1000 discrete values; even without expanding to the more reasonable 1024 values (10 bits) we are talking 1000! entries in the mapping space, far, far more than any sane keyspace.

as keyspace reduces therefore, the number of false positives (not true positives) will increase in the keyspace; for a given input/output known plaintext pair, one key in every ‘n’ (where n is the size of the blockspace, 1000 in this example) will be a valid match, statistically. However, as the number of keys which match a given sample block in the keyspace increases, the likelyhood of collisions in the mapping keyspace does not increase noticably - this is obviously not true if someone were to attempt a two bit mapping or something, but I will cover that in a second.

What is required then is an estimate of how many plaintext/cyphertext pairs will be required to uniquely identify a key as valid in the keyspace; as the block size goes down or the key size goes up, this value goes up (so for single DES, where the keyspace is smaller than the blocksize space, never mind the mapping space, the value is very slightly over 1 (there is a small possibility, via the birthday paradox, that two keys will generate the same mapping). For a 128 bit keyed, 64 bit cypher, this is going to be a bit over two, and so forth.

effectively therefore, until the required number of pairs approaches the size of the block itself, you are still going to have to search almost the entire keyspace (well, 50% of it on average) to find the valid key. In situations where this is not true (where the keyspace is so large compared to the input space that the number of keys which produce the same mapping is significant) the required number of pairs is equal or near equal to the input blockspace - at which point, you don’t NEED a key, you already have a comprehensive lookup table!

so, I failed to think this though sufficiently, and was wrong. At least it was a learning experience. ;)


Thursday, September 17, 2009

Cloud Data Security: Store (Rough Cut)

By Rich

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.


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

Access ControlsDBMS Access Controls
Administrator Separation of Duties
File System Access Controls
Application/Document Management System Access Controls
EncryptionField Level Encryption
Application Level Encryption
Transparent Database Encryption
Media Encryption
File/Folder Encryption
Virtual Private Storage
Distributed Encryption
Rights ManagementApplication Logic
Enterprise DRM
Content DiscoveryCloud-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).

  1. 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.
  2. 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.
  3. 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.
  4. 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.


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.

  1. 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.
  2. 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 layer, rather than within the database itself, due to the complexity.
  3. Transparent Encryption: Encryption of the database structures, files, or the media where the database is stored. For database structures this is managed by the DBMS, while for files it can be the DBMS or third-party file encryption. Media encryption is managed at the storage layer; never by the DBMS. Transparent encryption protects the database data from unauthorized direct access, but does not provide any internal security. For example, you can encrypt a remotely hosted database to prevent local administrators from accessing it, but it doesn’t protect data from authorized database users.
  4. Media Encryption: Encryption of the physical storage media, such as hard drives or backup tapes. In a cloud environment, encryption of a complete virtual machine on IaaS could be considered media encryption. Media encryption is designed primarily to protect data in the event of physical loss/theft, such as a drive being removed from a SAN. It is often of limited usefulness in cloud deployments, although may be used by hosting providers on the back end in case of physical loss of media.
  5. File/Folder Encryption: Traditional encryption of specific files and folders in storage by the host platform.
  6. Virtual Private Storage: Encryption of files/folders in a shared storage environment, where the encryption/decryption is managed and performed outside the storage environment. This separates the keys and encryption from the storage platform itself, and allows them to be managed locally even when the storage is remote. Virtual Private Storage is an effective technique to protect remote data when you don’t have complete control of the storage environment. Data is encrypted locally before being sent to the shared storage repository, providing complete control of user access and key management. You can read more about Virtual Private Storage in our post.
  7. Distributed Encryption: With distributed encryption we use a central key management solution, but distribute the encryption engines to any end-nodes that require access to the data. It is typically used for unstructured (file/folder) content. When a node needs access to an encrypted file it requests a key from the central server, which provides it if the access is authorized. Keys are usually user or group based, not specific to individual files. Distributed encryption helps with the main problem of file/folder encryption, which is ensuring that everyone who needs it gets access to the keys. Rather than trying to synchronize keys continually in the background, they are provide at need.

Rights Management

The actual enforcement of rights assigned during the Create phase.

For descriptions of the technologies, please see the post on the Create phase. In future posts we will discuss cloud implementations of each of these technologies in greater detail.

Content Discovery

Content Discovery is the process of using content or context-based tools to find sensitive data in content repositories. Content aware tools use advanced content analysis techniques, such as pattern matching, database fingerprinting, and partial document matching to identify sensitive data inside files and databases. Contextual tools rely more on location or specific metadata, such as tags, and are thus better suited to rigid environments with higher assurance that content is labeled appropriately.

Discovery allows you to scan storage repositories and identify the location of sensitive data based on central policies. It’s extremely useful for ensuring that sensitive content is only located where the desired security controls are in place. Discovery is also very useful for supporting compliance initiatives, such as PCI, which restrict the usage and handling of specific types of data.

  1. Cloud-Provided Database Discovery Tool: Your cloud service provides features to locate sensitive data within your cloud database, such as locating credit card numbers. This is specific to the cloud provider, and we have no examples of current offerings.
  2. Database Discovery/DAM: Tools to crawl through database fields looking for data that matches content analysis policies. We most often see this as a feature of a Database Activity Monitoring (DAM) product. These tools are not cloud specific, and depending on your cloud deployment may not be deployable. IaaS environments running standard DBMS platforms (e.g., Oracle or MS SQL Server) may be supported, but we are unaware of any cloud-specific offerings at this time.
  3. Data Loss Prevention (DLP)/Content Monitoring and Protection (CMP) Database Discovery: Some DLP/CMP tools support content discovery within databases; either directly or through analysis of a replicated database or flat file dump. With full access to a database, such as through an ODBC connection, they can perform ongoing scanning for sensitive information.
  4. Cloud-Provided Content Discovery: A cloud-based feature to perform content discovery on files stored with the cloud provider.
  5. DLP/CMP Content Discovery: All DLP/CMP tools with content discovery features can scan accessible file shares, even if they are hosted remotely. This is effective for cloud implementations where the tool has access to stored files using common file sharing protocols, such as CIFS and WebDAV.

Cloud SPI Tier Implications

Software as a Service (SaaS)

As with most security aspects of SaaS, the security controls available depend completely on what’s provided by your cloud service. Front-end access controls are common among SaaS offerings, and many allow you to define your own groups and roles. These may not map to back-end storage, especially for services that allow you to upload files, so you should ask your SaaS provider how they manage access controls for their internal users.

Many SaaS offerings state they encrypt your data, but it’s important to understand just where and how it’s encrypted. For some services, it’s little more than basic file/folder or media encryption of their hosting platforms, with no restrictions on internal access. In other cases, data is encrypted using a unique key for every customer, which is managed externally to the application using a dedicated encryption/key management system. This segregates data between co-tenants on the service, and is also useful to restrict back-end administrative access. Application-level encryption is most common in SaaS offerings, and many provide some level of storage encryption on the back end.

Most rights management in SaaS uses some form of labeling or tagging, since we are generally dealing with applications, rather than raw data. This is the same reason we don’t tend to see content discovery for SaaS offerings.

Platform as a Service (PaaS)

Implementation in a PaaS environment depends completely on the available APIs and development environment.

When designing your PaaS-based application, determine what access controls are available and how they map to the provider’s storage infrastructure. In some cases application-level encryption will be an option, but make sure you understand the key management and where the data is encrypted. In some cases, you may be able to encrypt data on your side before sending it off to the cloud (for example, encrypting data within your application before making a call to store it in the PaaS).

As with SaaS, rights management and content discovery tend to be somewhat restricted in PaaS, unless the provider offers those features as part of the service.

Infrastructure as a Service (IaaS)

Your top priority for managing access controls in IaaS environments is to understand the mappings between the access controls you manage, and those enforced in the back-end infrastructure. For example, if you deploy a virtual machine into a public cloud, how are the access controls managed both for those accessing the machine from the Internet, and for the administrators that maintain the infrastructure? If another customer in the cloud is compromised, what prevents them from escalating privileges and accessing your content?

Virtual Private Storage is an excellent option to protect data that’s remotely hosted, even in a multi-tenant environment. It requires a bit more management effort, but the end result is often more secure than traditional in-house storage.

Content discovery is possible in IaaS deployments where common network file access protocols/methods are available, and may be useful for preventing unapproved use of sensitive data (especially due to inadvertent disclosure in public clouds).


Tuesday, September 15, 2009

XML Security Overview

By Adrian Lane

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!

—Adrian Lane