Research

The final installment in our masking series closes with a simplified buyer’s guide for product selection. As with most security product buyer’s guides, we offer a fairly involved process to help customers identify their needs and evaluate solutions against each other. These guides address the difficulty of getting all stakeholders to agree on a set of use cases and priorities, which is harder than it sounds. We also offer guidance on avoiding pitfalls and vendor BS. Of course you still need to ensure that your requirements are identified and prioritized before you start testing, but the process with masking technologies is a bit less complicated than with other technologies. The field of vendors has dwindled rapidly for one simple reasons: Customer requirements are narrowly defined along a few principal use cases (test data management, compliance, and database security), so most masking platforms focus their solutions along these lines. Only a couple full-featured platforms provide the necessary deployment models and sufficient database coverage to compete in all cases. But we often see a full-featured platform pitted against others that focus on a single use case, because not every customer needs or wants every possible capability. So don’t focus solely on ‘leaders’ in whatever analyst reports you may read, but cast your net across a wider group of vendors to start your ‘paper’ evaluations. That should give you a better idea of what’s available before you conduct a proof of concept deployment. Define Requirements Over and over again, we see dissatisfaction with security products stemming from a failure to fully understand internal requirements before product selection. We understand that it is impossible to fully evaluate questions such as ease-of-use across an entire organization before a product is in full deployment. But unfortunately, more often the real issue is lack of understanding of both the internal expectations for the product and where the organization is headed. So defining needs and getting input from all stakeholders are necessary for a successful product evaluation and selection. Create selection team: Even small firms have at least the technically-focused security and IT operations groups cooperate during the selection process; but typically different business units, along with risk, audit, and compliance have input as well. Identify the major stakeholders and designate a spokesperson for each group. Define what needs protecting: You need to identify the systems (file servers, databases, etc.) and data types to be protected. Summarize what the data is and how the systems are used, and map desired data flow if possible. Define how data will be protected: Map your protection and compliance needs to the systems, processes, and data from the previous step. Accept input from each stakeholder on the security and compliance requirements for each data type, and the risk or criticality of that data. Design your ideal deployment: Now that you have an understanding of what needs to be protected and how, document the specifics of integration and deployment. Determine what masks are appropriate for each data type, how data flows through your systems, and where your integration points should be. Define tests: Determine how you will verify that vendors meet your requirements. Decide what samples data sources and data types need to be tested. Confirm that adequate resources are available to thoroughly test the system. Pulling an old laptop from a drawer or an older server from a closet to run tests on is a way to ensure failure. Determine and assign responsibilities for who will test and who will evaluate the results. Tier the tests so the most critical elements are tested first, to weed out unworthy products as quickly as possible. Finally, figure how you will validate the efficacy of the masks, and whether they are genuinely producing suitable results. Formalize requirements: At this point you should have a very clear picture of what you need, so it’s time to document some of your requirements for a formal Request For Information (RFI) and Request For Proposals (RFP) to identify which vendors offer appropriate solutions, and then select the ones that best match your requirements for further evaluation. You should also have a good idea of your budget by this point – it will help guide your selection, and may force a phased deployment. Vendor Selection Deployment Architecture: Architecture is key because it determines compatibility with your environment. It also directly correlates with performance, scalability, management, and ease of deployment. Centralized masking servers, distributed deployments, on-database masking, and agents are all options – but which is best depends entirely on your environment and how you want to deploy. So testing your deployment model across sufficient systems is essential for developing a good idea of how well the masking solution fits your environment. Platform coverage: Verify that the vendors support the relational and quasi-relational databases you need, as well as their ability to work with the applications and file servers you wish to integrate with. This is typically the first area where vendors “wash out” of the evaluation, when they don’t adequately support one of your critical platforms. You should review vendors’ published support matrices, but we suggest you also test your critical platforms to make sure they work to your satisfaction. How data is collected and managed varies from vendor to vendor, and how well each solution works with different database types can be an eye-opening comparison. Use, customization, and management: Test the day-to-day tasks of adding data sources, performing discovery, adding masks, and customizing reports. You will be living with this UI and workflow on a daily basis, so ease of use is a major consideration. If the product is annoying during the evaluation process, it is unlikely to become more pleasant with familiarity. Poor user interfaces make administrators less likely to tune the system, and poor workflows are more likely to cause mistakes. Ease of use is rarely listed as an evaluation criterion, but it should weigh heavily in your choice of platform. Scale and performance: Vendor reported performance and real world performance are quite distinct, so you need

I have been wanting to write a bunch of blog posts for the last few weeks. No, not the heavy research work we have been in up to our eyeballs, but about some of the strange and interesting stuff currently been reported. We used to do a lot more commentary and I miss it. I have a little time this Friday, so I though I would comment on a few of the past week’s articles I think warrant discussion – in many ways as interesting for what was not discussed. Here we go: The first was Google saying that the Internet is a Dangerous Place. OK. Why? Actually, “Why Now?” is a better question – Google has been making a lot of noise lately about security and privacy. I have been getting a dozen or so Google Safe Browsing warnings when visiting web sites, where Safe Browsing has supposedly detected ‘malicious’ or unreliable content. The problem is that every single one of the alerts was bogus! If you look at the details of why Safe Browsing thinks the site is bad, you ll find that all the checks Google lists were passed without detecting any unusual certificates, scripts or content. Take a look at the JavaScript or anything else in the page source, and everything looks sound. I instinctively tend to agree with Google’s assertion, but when I look at the basis for their claim, my own experience with Safe Browsing’s complete unreliability makes me question its validity. I don’t think their assertions are based on solid data. Amrit Williams made a similar tweet a couple weeks ago, saying “Chrome should just be called ‘Warning: We believe state-sponsored attackers may be attempting to compromise your account or computer.’”, and The New York Times ran an article on the same subject. My problem is not that I believe or disbelieve the existence of state sponsored censorship, but I don’t understand the recent hype. It appears to be all FUD, but what is the point? Why is Google being so noisy about security and data integrity? The cynic in me believes that they must be positioning security as a value add, or possibly looking for a legal angle to keep data pure – otherwise why the sudden clamor for attention? Which leads to the second post I found very interesting, on Bruce Schneier’s site, called Apple Patents Data-Poisoning. It appears that the US Patent and Trademark Office believed that poisoning profile data was novel and granted Apple’s patent request. In 2004/2005 I used to provide prospective customers for database activity monitoring a demo script to run against competitive products. The script would simply push SQL queries to both real and non-existent databases over the network. None of the queries would execute successfully because they we not actually part of an active database session. But competitors’ network monitors only looked for SQL queries on any known database port – without regard for whether they were actually going to a database – the monitor would capture all this fake activity. I could poison competitors’ logs with bogus activity, or flood it with false positives. It was a terribly effective way to demonstrate how early database monitoring products that watched network activity sucked. But I would never have tried to patent that idea – it feels like trying to patent network packets: good packets and bad packets are just normal network traffic. Similarly I would not patent my attempts to create “False Adrian” by showing non-random but totally bogus interest in products or services to see what sort of anti-profile I can create, a hobby I have been experimenting with on and off since 2006. This seems like a patent awarded for “urinating on the floor”, or anything else that occurs naturally but fails to identify genuine user intent. From an intellectual property standpoint, I hate to think someone could patent something like this. But from a product standpoint, if Google (and other marketing firms) surreptitiously capturing all your activity for profit pisses you off, would you buy an Apple product that poisons your activity trail? I would. A cloud based iRandomizer for browser traffic over an encrypted tunnel would be ideal! Finally, a post on MSNBC said some hacked firms are “fighting back” by hacking the hackers. Forgive me, but ‘Cloudstrike’ has a very Team America feel to it; well-intentioned but wide of the mark. First, there is a big difference between “active defense” and “strike-back” capabilities. Active defense is not an attack against hackers – it is an active scan of activities on the Internet for clues that someone is, or is about to, launch an attack against your site. Something like the CIA or NSA gathering intelligence to detect someone plotting a terrorist attack. Some large firms use this type of service for advance notice, and they hope to get an early start on their response, whatever it is. But “strike back” capabilities are totally different, and the goal of damaging an alleged attacker would certainly be outside the law. I doubt any of these plans will be effective – the New School blog raises the same question in Active Defense: Show Me the Money. The concept seems well intentioned – some of you are probably unaware that a handful of recent electronic attacks against major companies have been accompanied by physical threats against employees. So I get the desire to induce the same fear in hackers, but it seems unlikely to work, and it’s definitely illegal. Really, you can either locate the attacker(s) or you can’t, but if you can you have a good possibility of scaring them with law enforcement. Otherwise you’re pretty much out of luck. I know some attacked firms have conducted reconnaissance and analysis to help law enforcement locate the attacker, but that seems like the reasonable limit of effectiveness for counter-strike computer security. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on the Security Generation Gap. Mike quoted on the “Renaissance Information

Earlier this week Joseph Menn published a confusing article over at Reuters that conflated “active defense” with “strike back” technologies. As Chris Hoff said on Twitter: “active defense” is not the same as “strike back.” The first sentence is a bullshit premise. Active defense, deception, and counterattacks are things I have been interested in for a long time. The principles aren’t new – just go read the Cuckoo’s Egg – but we are seeing a small revival as the nature of attackers cycles back to data theft from the decade-plus distraction of website defacements and low-end phishing & malware. Mike and I talk a lot about reacting faster and better (see React Faster and Better: New Approaches for Advanced Incident Response). As is now being recognized more broadly, no security toolset can eliminate successful attacks, so we need to focus just as heavily on incident response. The problem? We generally lack mechanisms to identify the attacks that our tools miss. I wrote in Force Attacker Perfection that we can put in more barriers and monitors to increase our chances of detecting an attack. But my premise was a bit flawed – we still need some sort of trigger to identify real attacks, with far fewer false positives than we have come to accept from our tools. No one has time to look through every SIEM or IDS alert on a day to day basis, never mind logs. One way around this is to implement active defenses, honeypots, and tripwires. To avoid Menn’s mistake, here are some possible definitions we can work with: Active defense: Altering your environment and system responses dynamically based on the activity of potential attackers, to both frustrate attacks and more definitively identify actual attacks. Try to tie up the attacker and gain more information on them without engaging in offensive attacks yourself. A rudimentary example is throwing up an extra verification page when someone tries to leave potential blog spam, all the way up to tools like Mykonos that deliberately screw with attackers to waste their time and reduce potential false positives. Intrusion deception: Pollute your environment with false information designed to frustrate attackers. You can also instrument these systems/datum to identify attacks. DataSoft Nova is an example of this. Active defense engages with attackers, while intrusion deception can also be more passive. Honeypots & tripwires: Purely passive (and static) tools with false information designed to entice and identify an attacker. Counterstrike: Attack the attacker by engaging in offensive activity that extends beyond your perimeter. These aren’t exclusive – Mykonos also uses intrusion deception, while Nova can also use active defense. The core idea is to leave things for attackers to touch, and instrument them so you can identify the intruders. Except for counterattacks, which move outside your perimeter and are legally risky. You don’t need to be highly advanced to implement some of these ideas, and you certainly don’t necessarily need products. We are starting to integrate some of these concepts into our environment, and doing so creatively with no real budget. But my biggest fear isn’t being attacked, or even breached – I worry about finding out on Pastebin or in the morning news. I know I can’t keep all attackers out, and I can’t review our forensic logs every day, and I know that no signature-based tool can detect everything, so my only choice is to drop some tripwires to hopefully figure out when someone makes it in. I’m not saying my definitions are canonical – and they need work – but it’s important to distinguish between passive deception, active deception/defense, and offensive activity. Share:

In our last post we covered the four enterprise key management strategies. Today we will finish off Pragmatic Key Management with recommendations on how to pick the right strategy for your project or organization. To recap, there are four key management strategies: Local management Silo management Key management service Enterprise key management As much as I would like to drag this out into a long and complex assessment process, it’s actually fairly simple: You should never use local key management for anything other than development, testing, and one-off applications. About the only thing I use it for is some personal encryption, and not even much of that. Stick with silo management if it meets your needs, but this generally only works for encryption-oriented silos such as full disk encryption, email, and a couple other cases. By ‘needs’ I mean everything from basic manageability and auditing/reporting all the way through administrator separation of duties, key rotation/backup/restore, multi-location key synchronization and replication, and all sorts of other requirements beyond the scope of this series. When local and silo won’t work, a key management service is the way to go. Full enterprise key management is nice to have, but not something to focus on at the start. If you do stick with silo management but need a key manager for another project, it is often worthwhile to transition your siloed applications over to the key manager; once you have a key manager you might as well take advantage of it for backup, restore, redundancy, and other management features. The key is to think strategically. Once you start managing multiple encryption applications, you will eventually move into some sort of dedicated key manager. To build a key management service, pick a platform that will grow as you increase usage – even if the first deployment is narrowly scoped. People often start with a single application, database, or storage encryption project – a silo where key management is poor or doesn’t exist. But don’t choose purely based on immediate requirements – pick something that meets your immediate needs and can expand into other areas, for example by providing a backup key manager for disk encryption. We see two common problems when people build key management strategies. The first is that they don’t build strategically. Everyone buys or builds key management for each project, rather than offering and taking advantage of a central service whenever possible. On the other end of the spectrum, organizations obsess over implementing enterprise key management but forget to properly managing their silos and projects. We see the best success when organizations plan strategically and then grow into broader key management. Practically speaking, this typically starts with a single project using a dedicated key manager, which is then expanded and leveraged for other complementary projects. It’s fine to keep some silos, and it’s okay to have key managers in their own silos when there is no need to plug them into something larger. For example, you don’t necessarily need to have both your database encryption and full disk encryption projects report up to a single enterprise key manager. We have mentioned this before, but sweet spots which may justify moving up to a key manager include: Backup encryption Database encryption Application encryption In all three areas we tend to see strong need for encryption but weak key management. To recap: avoid local management; silos are fine when they meet your needs; step projects up to key managers when it makes sense for the project; expand coverage over time; and stick with one platform for cleaner management when feasible. Key management and how you structure your crypto system both matter more than the encryption engine itself. We haven’t discussed key manager selection criteria (fodder for a future report); but it should be obvious that deployment is easier when products support standards, include good APIs and plugins, and play well out of the box with common platforms and software. You should now have a much better idea of how data encryption systems work, the different strategies for managing encryption keys, and how to pick the best one for your organization. Share:

Most folks have sights, sounds, and smells that remind them of positive experiences. Maybe from happy childhood days or a great time of life. For me, it’s the smell of the ocean. My Dad always had a boat and I remember some great times sailing on his catamaran as I was growing up. I didn’t spend a lot of time with my Dad growing up, so I loved being out on the water. And we’d bring a bucket of KFC with us, which was also a highlight. Strange, the things you remember 35 years later, eh? But that’s not all. I met the Boss at the beach and spent many a great summer on the Delaware beaches. What I remember of those summers anyway. So when we arrive at the beach for our annual family vacation, one of the first things I do is walk down to the beach, sit on a bench, and just breathe in the air. I’m instantly relaxed. In fact, when I travel I use a sound machine to eliminate the noise of strange hotels and weirdos in adjoining rooms. Surprised that I sleep to Ocean Waves Crashing? Yeah, me neither. Of course I am surrounded by family for an entire week, so that feeling is fleeting, but the beach calms me. It’s one of the things I really miss about living in Atlanta – the lack of easily accessible beaches. But before you conclude that I don’t like my family, that’s not true. As I was explaining to some folks at last week’s Atlanta NAISG meeting, it’s hard for me to be surrounded by people for an extended period of time. I’m pretty much a textbook introvert, and that means if I don’t get my private time, it can get messy. So even if I like the people I’m around (and I do like my family, well, most of them…), I still need some time to myself. So I have set expectations over 15+ years of marriage, that I usually peel off each morning for a cup of coffee and to catch up on some work. Yes, I’m one of those guys who works on vacation. Not a lot, maybe a couple hours a day. But enough to not fall terribly behind and to get my private time. And before you start thinking about my workaholic issues, remember that I actually enjoy what I do. Most of the time it doesn’t feel like work to me. As I sit in a coffee shop, about to head down to the boardwalk with the family this afternoon, I bang out the Incite and everything is perfect. Perfect doesn’t last and it doesn’t scale, so I’ll enjoy it while it’s here. Now where’s that sunscreen again? –Mike Photo credits: What’s That Smell? originally uploaded by ambergris Heavy Research We’re back at work on a variety of series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Understanding and Selecting Data Masking Use Cases Management and Advanced Features Pragmatic Key Management The Four Enterprise Key Management Strategies Understanding Data Encryption Systems Evolving Endpoint Malware Detection Providing Context Behavioral Indicators Defending Data on iOS New Paper Malware Analysis Quant Final Paper Incite 4 U Or maybe build a cyber-guillotine: It seems the folks over in the UK did a study that concluded too much is spent on AV and not enough on prosecuting online criminals. Obviously no one is going to argue that spending more on controls with limited effectiveness is a plan for success. But will going after perpetrators with more urgency help? Will a few more midnight raids on high-profile hackers prevent the next generation of malcontents from joining fraud networks? I say it’s worth a try, though in an instant gratification environment it’ll be hard to prove the success of that approach in the average politician’s term of office. But even in places with severe consequences such as losing limbs, we still have desperate folks and bad apples committing crimes, consequences be damned. But I do think folks who could go either way might make the right decision if they have a better (and more tangible) understanding of what the wrong decision may mean. – MR Moley moley moley mole MOLE! (Apologies for the only slightly-obscure reference in the title). I hate debunking hyperbole that’s probably also true. Such as Mikko Hypponen’s assertion that the US government probably has moles in Microsoft. He doesn’t have a single shred of evidence to support his logical conclusion. Then again, I’d be shocked if various agencies from various countries haven’t placed people in all sorts of companies. Is there backdoor code hidden in products? Who knows… although places like Microsoft with strong software assurance programs are much less likely to let something get through unknowingly. This is a complex issue, and pure supposition doesn’t really advance the discussion. Let’s admit that none of us really know what we are talking about, and the people who do aren’t talking. – RM Attacks come and go, but the monoculture is eternal: Great analysis by Augusto (finally able to dig through my Instapaper archives on ‘vacation’) on the impact of Chrome becoming the most popular browser. Basically, like mobile operating systems, browsers are being built with better protection, and with 4-5 main players there is huge fragmentation. So attackers (wisely) continue to focusing on the lowest hanging fruit: widely deployed apps with huge market penetration. Right, like Adobe Flash and Reader. Augusto references Dan Geer’s seminal monoculture essay, and the point is exactly right. There will always be high market share products/devices/widgets which represent the most attractive targets. HTML 5 will provide standards and get rid of things like Flash, but to think you can’t attack the successors (including HTML5 in browsers) is naive. So the attacks will change. The motivations of attackers

Yes, folks, at long last, here is my follow-up to Understanding and Selecting a DLP Solution. As you might guess from the title, this one is focused on implementation and management. After you have picked a tool, this will help you get up and running, and then keep it running, with as little overhead as possible. I would like to thank McAfee for licensing the paper and making it possible for us to give this stuff out for free (and by now we hope you’ve figured out that all the content is developed independently and objectively). McAfee is hosting the paper and you can download it from us: Landing page PDF (direct) Share:

As we wrap up our Evolving Endpoint Malware Detection series, it’s time to take it to the next level. We spent the first three posts on why detection is challenging, the types of behavioral indicators you should look for, and some additional data sources for added context to improve effectiveness and reduce false positives. Now we need to do something with the information we have gathered – basically to provide a verdict on whether something is malware or not, and if it is to block it. Alas, this is where you need to understand the trade-offs between different controls and decide what is best for your environment. The Malware Detection ‘Cocktail’ Let’s jump back in the time machine, to the good old days on the cutting edge of spam detection. Spammers got pretty good and evolved their techniques to evade every new defense the email security folks came up with. 3-4 years in, around 2004-2005, the vendors used 15-20 different tactics to determine whether any particular email message was unsolicited. Sound familiar? Malware detection has reached a similar point. Lots of techniques, none foolproof, and severe consequences for false positives. What can we learn from how the anti-spam vendors evolved? Aside from the fact that over time the effectiveness you can achieve and maintain is limited? The best approach for dealing with a number of different detection techniques is to use a cocktail approach. This involves scoring each technique (possibly quite coarsely), feeding it into an algorithm with appropriate weighting for each technique, and then determining a threshold that indicates something bad. Obviously the secret sauce is in the algorithm, and it’s the vendor’s responsibility to handle it. Yes, a lot of this happens (and should remain) behind the curtain, but we are trying to explain how the process works so you can be an educated shopper for new devices and products that claim to detect advanced malware. But we have also learned from the anti-spam folks that you cannot be right every time. So we need to plug our research on incident response and forensics, including Incident Response Fundamentals, React Faster and Better, and Network Security Analysis, to ensure you are prepared for the inevitable failures of even the best malware detection. Let’s take a look at the components and controls you will rely on: Traditional Endpoint Protection Thanks to your friendly compliance mandate and check-box-centric auditors, you still need endpoint protection – often called anti-virus. But most endpoint security suites encompass much more than traditional anti-virus signatures, including some of the tactics we have discussed in this series. Obviously with 15-20 players remaining in this market, the quality of detection is all over the map and quite dynamic. Each vendor goes through ups and downs in detection effectiveness. So how do we recommend choosing an endpoint suite? That could be an entire series itself, but suffice it to say that the effectiveness of detection probably shouldn’t be the most important selection criteria. It is too hard to verify, and they each do a decent job of finding known malware, and a mediocre job of finding the advanced attacks we have focused this series on. You need endpoint protection for compliance; so you should minimize price, ensure that agents can be effectively managed (especially if you have thousands of endpoints), and make sure that the agents are as thin as possible. It’s bad enough having to use a control that doesn’t work as well as it needs to, but crushing device performance adds insult to injury. By all means, check the latest comparative effectiveness rankings, but understand they go out of date pretty quickly. Network-based Malware Detection We believe that the earlier you can detect malware and block it, the less mess you will inevitably have to clean up. That means working to eliminate attacks at the perimeter or even in the cloud before an attack ever gets near your desktop. How can you do this? A new type of network security device scrutinizes ingress traffic to detect malware files before they enter your corporate network. We expect this capability to become a feature of pretty much every perimeter device over time, but for now you will need to deal with specialist companies and separate devices. We published some research on this earlier in 2012; so check out Network-based Malware Detection for details on the approaches, limitations, and roles of these devices in your network security strategy. Advanced Endpoint Controls We all understand that traditional endpoint security suites leave too much attack surface exposed to advanced attackers, depending on your pain threshold (how likely you are to be targeted by an advanced attacker). An additional level of endpoint protection may be necessary. So let’s discuss some of these alternatives – which detect and block based on behavioral indicators, track file trajectories and proliferation, and/or allow authorized executables. The first category of advanced endpoint control is really next-generation host intrusion prevention (HIPS) technology. As we have mentioned, HIPS looks for funky behavior within the endpoint, but has lacked sufficient context to be truly effective. A few technologies have emerged to address these concerns, leveraging the kind of malware detection cocktail discussed above. This analytical approach to what’s happening on the endpoint, and applying proper context based on application and specific behavior can reduce false positives and improve effectiveness. These tools impact user experience by blocking things (which is usually a good thing), but need to be put through proper diligence before broad deployment. But you do that with all new technologies anyway, right? As we talked about in Providing Context, malware proliferation analytics can be very useful for tracking the spread of malware within your environment, securing the origin point, and reducing the possibility of constant reinfection. So we are fans of this kind of analysis as another layer of defense. You have two main options for gathering the information for this kind of analysis: either on the endpoint or within the network. Endpoint solutions provide a thin agent which

In our last post we covered the components of data encryption systems and ran through some common examples. Now it’s time to move on to key management itself, and dig into the four different key management strategies. We need to start with a discussion of the differences between encryption operations and key management; then we will detail the different enterprise-level strategies. The differences between key management and encryption operations As we focus on data encryption across the organization rather than isolated applications of basic encryption, it is time to spend a moment on what we mean when we discuss key management vs. encryption operations. Every data encryption operation involves a key, so there is always a key to manage, but a full-fledged management system is the most important aspect of building a multipart encryption system. Many data encryption systems don’t bother with “real” key management – they only store keys locally, and users never interacts with the key directly. For example, if you encrypt data with a passphrase using one of the many common command-line tools available, the odds are good that you don’t do anything with the key beyond choosing an encryption algorithm and key length. Super-simple implementations don’t bother to store the key at all – it is generated as needed from the passphrase. In slightly more complex (but still relatively simple) cases the key is actually stored with the data, protected by a series of other keys which are still generated from passphrases. There is a clear division between this and the enterprise model, where you actively manage keys. Key management involves separating keys from data for increased more flexibility and security. It does not require you to move to keys to an external system, but that is one of the more important options. You can have multiple keys for the same data, the same key for multiple files, key backup and recovery, and many more choices. The four key management strategies There are four main approaches to managing data encryption keys within an organization. These apply to individual cryptosystems, to various different kinds of applications, and to larger and more complicated cryptography systems. Many of them also apply to other kinds of encryption operations, such as digital signatures and certificates, but we aren’t concerned with those for this paper. Local key management This option is the closest to doing nothing at all for key management. Keys are all managed locally (on a single system or a cluster of systems), with all key functions handled within a single application. Local key management is actually quite common, even though it isn’t always the best idea. Common examples include: Full disk encryption managed by a single user (e.g., Bitlocker or FileVault without tying into a key management server) Transparent database encryption Building encryption into an application server Basic backup encryption File server or SAN/NAS encryption In each of these cases all keys can be managed locally – in which case any key rotation, backup/restore, or auditing also must be built into the local system, but more often these capabilities are simply nonexistent. Local key management isn’t necessarily bad, in particular isolated scenarios. For example, if you back up your data unencrypted, or with a system that uses its own keys, there may be no reason to worry about managing local keys. But for anything serious – including anything with compliance requirements – relying on local key management is asking for trouble. Silo key management This refers to separating the keys a the local system and managing them within a multi-system application. Whatever software stack/system you run manages its own keys for its own client software. Full disk encryption is one of the most common enterprise examples. A central management server handles configuration and keys for all encrypted laptops and desktops. This key management system is never used for anything else, such as databases, but may manage other data encryption features supported by the product (including file/folder encryption). All important key management functions, including administrative and recovery keys, rotation, backup/restore, and audit, are built into the silo key manager. Other typical uses include email encryption, some backup encryption tools, and even enterprise Digital Rights Management – DRM is implemented through cryptography. Silo key management is totally suitable when it meets the particular requirements of the situation. When encryption is the key function of a product, as with full disk encryption, this approach often works perfectly – with no need for additional key management. On the other hand, when encryption is merely a feature of an existing product, key management is often minimal at best – typified by encryption products bolted onto exiting backup systems. Key management services So far the two strategies we have discussed keep the keys within a single system or application stack. The next couple strategies introduce a new component: a dedicated key management system. When local or silo key management is inadequate, it’s time to bring in a tool specifically to address the problem. Move keys outside the silo and integrate dedicated key management with one or more applications. This used to be incredibly difficult, but more and more products (both commercial and free software / Open Source) now support key management standards that make it much easier to use external management. Before standards we had to either rely on the vendor to provide proprietary hooks, or reverse engineer the entire thing. A variety of dedicated key management options are available – including hardened hardware appliances, software, virtual appliances, and even Software as a Service (SaaS). We are focusing on key management strategies rather than products, so we won’t go into all the various features and functions, but suffice it to say they tend to have far more robust capabilities (and often stronger security) than all but the best silo tools. Aside from all the added functionality of an external service, the external service can manage keys for multiple different silos. This can be important for unifying auditing/reporting and meeting other compliance requirements. Key management services

As we approach the end of this series, it has become clear that I should really have started with use cases. Not only because they are the primary driver of interest in masking products, but also because many advanced features and deployment models really only make sense in terms of particular use cases. The critical importance of clustered servers, and the necessity for post-masking validation for some applications, are really only clear in light of particular usage scenarios. I will sort this out in the final paper, putting use cases first, which will help with the more complex later discussions. But here they are. Use Cases Test Data Management: This is, by far, the most important reason customers gave for masking. When polled, most customers say their #1 use for masking technologies is to produce test data. They want to make sure employees don’t do something stupid with corporate data, like making private data sets public, or moving production data to insecure test environments. That is technically true as far as it goes, but fails to capture the essence of what customers look for in masking products. In actuality, masking data for testing and sharing is almost a trivial subset of the full customer requirement; tactical production of test data is just a feature. The real goal is administration of the entire data security lifecycle – including locating, moving, managing, and masking data. The mature version of today’s simpler use case is a set of enterprise data management capabilities which control the flow of data to and from hundreds of different databases. This capability answers many of the most basic security questions we hear customers ask, such as “Where is my sensitive data?” “Who is using it?” and “How can we effectively reduce the risks to that information?” Companies understand that good data makes employees’ jobs easier. And employees are really crafty at procuring data to help with their day jobs, even if it’s against the rules. If salespeople can get the entire customer database to help meet their quotas, or quality assurance personnel think they need production data to test web applications, they usually find ways to get it. The same goes for decentralized organizations where regional offices need to be self-sufficient, or companies need to share data with partners. The mental shift we see in enterprise environments is to stop fight these internal user requirements, but find a way to satisfy this demand safely. In some cases this means automated production of test data on a regular schedule, or self-service interfaces to produce masked content on demand. These platforms are effectively implementing a data security strategy for fast and efficient production of test data. Compliance: Compliance is the second major reason cited by customers for why they buy masking products. Unlike most of today’s emerging security technologies, it’s not just the Payment Card Industry’s Data Security Standard (PCI-DSS) driving sales – many different regulatory controls, across various industry verticals, are driving broad interest in masking. Early customers came specifically from finance, but adoption is well distributed across different segments, including particularly retail, telecomm, health care, energy, education, and government. The diversity of customer requirements makes it difficult to pinpoint any one regulatory concern that stands out from the rest. During discussions we hear about all the usual suspects – including PCI, NERC, GLBA, FERPA, HIPAA, and in some cases multiple requirements at the same time. These days we hear about masking being deployed as a more generic control – customers cite protection of Personally Identifiable Information (PII), health records, and general customer records, among other concerns; but we no longer see every customer focused on one specific regulation or requirement. Now masking is perceived as addressing a general need to avoid unwanted data access, or to reduce exposure as part of an overall compliance posture. For compliance masking is used to protect data with minimal modification to systems or processes which use the (now masked) data. Masking provides consistent coverage across files and databases with very little adjustment. Many customers layered masking and encryption in combination; using encryption to secure data at rest and masking to secure data in use. Customers find masking better at maintaining relationships within databases; they also appreciate that it can be applied dynamically and causes fewer application side effects. In some cases encryption is deployed as part of the infrastructure, while others employ encryption as part of the data masking process – particularly to satisfy regulations that prescribe encryption. But the key difference is that masking offers full control over the data lifecycle from discovery to archival, whereas encryption is used in a more focused manner, often at multiple different points, to address specific risks. Masking platform manage the compliance controls, including which columns of data are to be protected, how they are protected, and where the data resides. Production Database Protection: The first two use cases drive the vast majority of market demand for masking. While replacement of sensitive data – specifically through ETL style deployments – is by far the dominant model, it is not the only way to protect data in a database. At some firms protection of the production database is the primary goal for masking, with test data secondary. Masking can do both, which makes it attractive in these scenarios. Production data generally cannot be fully removed, so this model redirects requests to masked data where possible. This use case centers around protecting information with finer control over user access and dynamic determination whether or not to provide access – something roles and credentials are not designed to support. Dynamic masking effectively redirects suspect queries to a masked view of the real data, along with reverse proxy servers, in a handful of cases. These customers appreciate the dual benefits of dynamically detecting misuse while also monitoring database usage; they find it useful to have a log of which view of information has been presented to which users, and when. It is worth mentioning a few use cases I

Ah, summer. That time of year where our brains naturally start checking out, even if it’s inconvenient. You have probably noticed a bit of a slowdown on the blog as we succumb to the sweet call of adventure. And by ‘adventure’ I mean the delicate balance of being way freaking behind while trying to squeeze in family vacations and a few conferences. Since my kids are too young for school I can’t really use them as the excuse for taking time off. No, in my case it is the temperatures over 100F that started a month or so ago and won’t subside until sometime close to Halloween. Phoenix is not fun in the summer if you get my drift. Today, for example, when I do my short run after my hour on the bike trainer, the temp will be somewhere around 104F. So I was super excited to spend last week in my home town of Boulder, Colorado. I grew up in New Jersey, but moved to Boulder when I was 18, spent the next 16 years there, and consider Boulder the place I really grew up. Some places just fit a person, and Boulder appealed to me on more levels that I can explain. The culture, physical environment, and social scene all aligned with that perfect cosmic center of the Universe all the new-age freaks claim is somewhere behind Pasta Jay’s. This was the first time I had been back for any length of time in about 5 years, and it was was my first time back since becoming a parent. It was sort of funny – when I lived there I didn’t think there was much for kids to do until they were old enough to climb, hike, ski, and ride. I was all worried my kids would be bored out of their gourds. Sure, I know where all 20+ bars near the Pearl St. Mall are located, but I had to email friends to find a single playground. But man, they are all over the place! And the best part? A lot are located really close to all those bars… which were coincidentally a reasonable bike ride from the house we rented. Yep, total coincidence. I mean, it isn’t like we’d plan that sort of thing. On the downside, instead of escaping from 100+ in Phoenix to Boulder’s typical 60-80F this time of year, we landed in a heat wave. As in 90F+. The technical term for that is “extreme suckage”. They always say you can’t go home, and to some extent that’s true. The life I had in Boulder is long dead. Friends have moved on, the ones who stayed got old (like me), the bars of our youth are now – if they exist at all – the bars of someone else’s youth, and if I tried to spend my leisure time doing everything I did back then I would soon be hunting for a good divorce lawyer in between those mountain rescues. In some ways it is good that I left Boulder, even if I miss it every day. I was instantly pulled out of my single/childless life and forced to drop things – like 5 martial arts classes a week, on top of dozens of mountain rescues, and ski patrol every other weekend, and all the other ways I passed my time. They were instantly severed instead of being drawn out in a long, painful process of separation and personal realizations that life changed and I need to back off. For me, life changed instantly instead of slowly. I know this because it is 100+ fracking degrees at 9am where I live, which is an excellent reminder. I have seen how most of my other friends with kids struggled to balance their lives through this transition, and ripping off the Band-Aid isn’t a bad way to do it. On the other hand, Boulder is still Boulder. Some of the buildings change, but I felt just as at home there last week as I did 6 years ago when I left. The 15 minute rain still comes in every day between 4 and 4:30, the convenience store in Jamestown is still a perfect place to stop for some coffee while riding a (rented) road bike in the hills, and the annoying-ass Rainbow Family kids – who you know have loaded parents – still camp out on the Pearl St. Mall begging for cash. You can go home. It’s just that someone else lives there now – even if you never left. With that, daycare just called and I need to go pick up a little kid with a fever and end my work day. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences We have been on vacation – nothing to see here. Favorite Securosis Posts Adrian Lane: Market Share Nonsense. Mike Rothman: Malware Analysis Quant [Final Paper]. Check out the final paper for the epic Malware Analysis Quant research. And then play a drinking game for every step in the process you don’t do. Make sure you don’t drive after that. Rich: What Adrian said. I need to write a follow-up on some of the BS vendors have tried to pull on me over the years. Like paying cash under the table for references. I tried my best, but I know at least once I was fooled… and it probably happened more than that. Other Securosis Posts Evolving Endpoint Malware Detection: Providing Context. New Paper: Defending Data on iOS. Incite 6/13/2012: Tweeting Idiocy. Understanding and Selecting Data Masking: Management and Advanced Features. Upcoming: Tokenization Webcast This Week. Evolving Endpoint Malware Detection: Behavioral Indicators. Favorite Outside Posts Adrian Lane: Mistakes Were Made: Incident Response. An informative rant on incident response and preparedness. Mike Rothman: Pre to postmortem: the inside story of the death of Palm and webOS. As a student of business, I love stories that dig into how anything can go from the top to the bottom within a few short years.