Research

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. When someone changes roles, IT gets notified how. A request is placed by a manager or employee to gain access to a system. If employee request, manager must(?) approve. If approved as “in job scope” by manager, system owner approves. 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. Share:

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 Adrian and Rich at BusinessWeek with the Truth, Lies, and Fiction with Data Encryption video. Rich and Martin on the Network Security Podcast, Episode 167. Oh Gn0es … I am having reservations about posting this, but it is Rich Mogull and David Mortman on stage at Defcon 17 Security Jam 2. Rich may panic and delete this link later so catch it while you can! Favorite Securosis Posts Rich: Cloud Data Security: Archive and Delete. Adrian: My post on Database Encryption Benchmarking. David Meier: So it’s not new, but I thought Building a Web Application Security program was the best internal post this week. David Mortman: Database Encryption Misconceptions. Other Securosis Posts A Bit on the State of Security Metrics Stupid FUD: Weird Nominum Interview Cloud Data Security: Share (Rough Cut) FCC Wants ‘Open Internet’ Rules for Wireless Incomplete Thought: Why Is Identity and Access Management Hard? Cloud Data Security: Use (Rough Cut) Favorite Outside Posts Adrian and Rich: We have never picked the same post before, but what Star Trek Predicts About the Future of Information Security is that good. It’s not every day bloggers get to geek out to the point we bring up “gold-pressed latinum”, or make security decisions based upon subjective personality assessments of violin-playing androids with cats. Very clever post. Meier: One word: ‘awesomesauce’. Mortman: Has Technology Killed Privacy? Top News and Posts New BeEF The best AES tutorial out there… in stick figures Remote exploits available for SMB2 vulnerability Microsoft workaround for the SMB vulnerability Bank sends mail to wrong Gmail address, then sues Google. Right, I’m sure that will work. Maybe they’ll have better luck if they spill hot Google on their lap. Great NAC white paper by Jennifer Jabbusch NSS runs a good malware test Free SSO for Google Apps? 4 Dangerous Myths about Data Disposal, Debunked talking points Why a hardware security model may not be as good as you think Blam! It was like patch Tuesday on a Wednesday for Cisco. Another reason to hate lawyers Netflix is smart. Very smart. Blog Comment of

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… Share:

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: 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. This doesn’t mean we shouldn’t strive for better metrics. Metrics fall into two categories – objective/measurable (e.g., number of systems, number of attacks), and subjective (risk ratings). Both have their places. 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). 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). 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. Share:

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. Share:

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

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

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

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

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