Research

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.

As we discussed in the last post, detecting today’s advanced malware requires more than just looking at the file (the classic AV technique) – we now also need to leverage behavioral indicators. To make things more interesting, even suspiciuous behavior can be legitimate in certain circumstances. So for accurate and effective detection you need better context on what the code does, where it came from, and who it came from, in order to reach a reasonable verdict on whether to allow or block execution. What happens when you don’t have that context? Let’s jump into the time machine and harken back to the early days of host intrusion prevention (HIPS) and HIPS-like products. They ran on devices and scanned for both attack signatures and behaviors that indicated malware. Without proper context, these controls blocked all sorts of things – involving scads of false positives – and generally wreaking havoc on operations. That didn’t work out very well for organizations which actually needed their devices up and running, even if that imposed a cost in terms of security. Go figure. But the concept of watching for attacks on devices is solid. It was more of an implementation problem; nowadays additional context reduces false positives, increases accuracy, and limits disruption of operations – all worthy goals for a control to manage new attack vectors. So let’s dig into a few data sources (beyond behavioral indicators) that can help identify bad stuff. From Where: the Dropper In the last post we mentioned that malware writers use droppers to gain a presence on devices, and then download current and/or additional attacks, instead of attempting to get the entire malware on the device as part of the initial compromise. Of course droppers are malware just as much as anything else else, but they morph more frequently, which makes initial detection difficult. And as we described in Malware Analysis Quant, the only thing worse than being infected is getting re-infected by the same malware. So profiling malware droppers enables you to search for these files in your environment. By tracing the path of those droppers you can identify devices which have been compromised but not yet activated. The key to this effort is analysis of data about which files are on which devices; when a file is discovered to be bad, if you have the data and analytics in place it becomes easy to determine which devices have the bad file installed. Of course this is still a reactive effort. But the presence of a dropper (or similar known bad file), combined with any other bad behavior, is fairly damning evidence of a compromised device. Tracing the droppers back far enough points you to the origination point of the malware; eliminate any vestiges, and you can prevent reinfection. Who Dat: Reputation The other useful source for detecting advanced malware is the reputation of a file, sender, or IP address. Initially developed to improve the effectiveness of anti-spam gear, reputation has emerged as a fundamental aspect of every vendor’s threat intelligence offering. The larger security vendors have access to considerable amounts of data from hundreds of millions of installed endpoints and network devices; they mine their datasets to determine which files, devices, and network addresses tend to do bad things. This is all an inexact science – especially in light of the simplicity of morphing a file, spoofing an IP address, or fiddling with a device fingerprint. You need to expect advanced adversaries to look like something innocent, even when they aren’t. You cannot afford to rest your malware-or-clean verdict strictly on reputation – but you can use it as a supporting data source, for additional context when analyzing a possible attack. Of course malware writers don’t make it easy to figure out what they are doing. Your best bet is to assemble as much data as you can, analyze what’s going on within the device (behavioral analysis), and combine with data from outside sources to judge the nature and intent of code running (or attempting to run) on your devices – this at least gives you a fighting chance. So far we have focused on analysis and detection, but detection doesn’t help without a mechanism to actually block attacks once they are detected. So we will wrap up this series next week, with an assessment of the different classes of security controls that can leverage this context data to block specific attacks. Share:

It was bound to become blindingly obvious sometime. The ruse of anyone accurately tracking market share in any market has been a running joke for as long as I can remember. I guess some folks do argue with the so-called market share numbers, like McAfee recently did, but it is usually attributed to sour grapes for those with crappy numbers. I’d say that market share doesn’t matter for end users, but in reality it’s safer to go with a vendor with a large market share. And in today’s tough business environment, very few are willing to be unsafe. Clearly these numbers matter for vendors. Many bonuses, marketing campaigns, and marketing/sales jobs hinge on these numbers. You can bet that someone at McAfee has a ton of road rash, especially if the reported share numbers are wrong. And I feel for those folks because I have personally been on both ends of the market share reporting game, and it’s always unpleasant. Why? Because the numbers are basically made up. Okay, not totally made up – in mature markets vendors dutifully report revenues and units to the analysts. But there are times when vendors don’t tell the entire truth. Or manipulate the numbers. Or obfuscate reality. Or all of the above. Let me tell a little story. Back when I was in the email security business, these numbers mattered a lot internally to my company. Our perceived leadership allegedly got us on the short list for many deals and allowed us to claim market success, which begat more business success. So when we got a preliminary report from a number-crunching firm showing our main competitor gaining share rapidly, alarm bells sounded everywhere. And it was my job to fix it. But I couldn’t make our product sell faster. Nor could I combat unsavory sales tactics by the competition. But I could manipulate the market share reporting process. Or at least try. The statute of limitations is up on this deal and none of the folks involved in the travesty are still in their current jobs, so I finally feel comfortable spilling the beans. Basically I made a call to the analyst wondering if he considered that the competitor sold both email sending devices and anti-spam devices. I mentioned that we had heard 1/3 of the competitor’s business was the spam cannons, and the remainder email security gear. When I said “I heard,” I really meant “I hoped” because it wasn’t like the competitor sent me their quarterly numbers. I didn’t turn the screws or threaten or anything like that. I just mentioned it in a simple conversation. Just food for thought for the analyst. I was pleasantly surprised when the final report came out and the competitors’ alleged revenue was reduced by 1/3. Really! I couldn’t believe it worked, but it did. To be fair, there is a chance I was right about the competitor’s revenue mix. Maybe the analyst figured out a way to confirm the sales data. Maybe the vendor came clean when the analyst pressed (assuming they did). No, I don’t think so either. Why do I tell this story, especially given that it doesn’t make me shine? Like most folks, I have done things I’m not exactly proud of. So part of this is cathartic, but I also tell the story because you need to keep these numbers in context. If you buy a product because you think a company is a market share leader, you aren’t too bright. If you don’t buy a product because the vendor is a niche player, same deal. Market share reporting is a game, just like vendor ranking quadrants. Some genius figured out how to extort money from the participants in a market to prove they are good companies. And it’s not just technology markets where these shenanigans happen. It’s pretty much every market. Don’t think that public companies play fair in this game either. Revenue allocation games can be played to make certain products look better. We all know some vendors give away products they want to look better in market share rankings as part of much bigger deals. As Adrian said when I floated a draft of this post by our extended team, “when bullsh** meets bad math, it’s the customers that lose.” That’s really the point. Do the work and figure out what makes sense for your environment. Tools like quadrants and market share grids can be used to justify a decision you have already made. But they shouldn’t be the basis for decisions you haven’t made yet. Share:

A while back we ran a show-of-hands survey at a conference of senior IT security pros. Nearly none of them wanted to support iOS, but nearly all of them needed to support iOS. Which did seem odd, considering how many were using iPhones. The good news is that although we can’t manage iOS the way we have traditionally managed most of our other employee systems, the platform itself is a lot more secure than most of the other things you are using. I know, you don’t believe me, so just read this paper. We also have plenty of options for protecting data going to the device, and once it’s on the device. This is the part that tends to be a bit more complicated, with a very wide range of tools and approaches, but all the things we review in this report are realistic and working in production environments. Hopefully this report simplifies things a bit, and as far as we know it is the only place someone has compiled all the options in one place, plus provided a neutral perspective on capabilities and usefulness. So take a look: Landing Page Direct link to the PDF: Defending Data on iOS (v 1.0) Special thanks to Watchdox for licensing this content so I can feed my kids (well, the one who bothers to eat). As always the research was developed completely independently and published on this blog for peer review throughout the entire process, in accordance with our Totally Transparent Research process. Share:

It’s easy to think that the main contribution of social media tools like Twitter and Facebook is to connect you more tightly to your friends, colleagues, and family. Which is true. But don’t underestimate the immediacy of using networks like Twitter to interact directly with the companies you do business with. I have two recent examples which highlight this trend. Those of you who follow me on the Tweeter (@securityincite) know I don’t tweet a lot. I’m not going to tell you where I am. Most of the time I’m not going to tell you what I’m doing. But I lurk, ready to pounce when an interesting discussion presents itself, or to whore out something we’ve written or a speaking gig. As the boy told me this week when I asked him why he was uncharacteristically quiet earlier this week, “I only talk when I have something to say.” I’m like that on Twitter. So when I had a pretty negative experience on a recent flight, my first thought was to Tweet. I did, and got an almost immediate response from Delta, apologizing for the issue. Wait, what? Because anyone bitching on Twitter isn’t just having a one-on-one conversation – they are venting to all their followers, and anyone searching for the terms (hashtags) mentioned in the tweet. So many companies have become much more responsive to customers venting, and those Tweets get higher visibility. You have heard the stories of high-profile CEOs responding directly to nasty tweets about their companies. Delta had a good response. It didn’t take the sting out of my crappy experience with their gate agent but at least I knew someone was listening. On the other hand, Barnes and Noble had a total #FAIL Monday, a stark example of how some companies are unlikely to make it in this age of Internet commerce. We were packing the kids up for sleepaway camp, and wanted to send them with a bunch of books to not read while they are away. Normally I buy from Amazon, but they had one of the Big Nate books backordered. B&N had it in stock for the same price. There is a store right where I was, so I figured I’d just pick it up at the store. But when I got the confirmation, the price listed was different than the online price. Huh? I figured maybe it was just some idiotic system problem and they’d honor the price they offered me online. That’s what every other retailer with stores and an online presence does, right? Evidently not – B&N charges full price for books you buy at the store, even if you can get them at 40% off on their website. They also provide free shipping on website orders. And you wonder why that company is struggling. I figured if I cannot avoid being inconvenienced to order online, I’ll just order two of the books from Amazon. Voting with my dollars, as I should. I did need the other book (backordered at Amazon), so I ordered that from B&N and took advantage of their free shipping. Of course I was perplexed, so I tweeted my frustration at B&N. They would respond and try to explain their idiotic policy, right? They couldn’t have their heads up their asses that badly, right? Wrong. Crickets in my timeline. So when you hear about B&N following Borders into bankruptcy don’t be surprised. Companies that don’t understand the direct feedback customers expect through social media nowadays aren’t long for this world anyway. –Mike Photo credits: B&N tombstone created by Mike Rothman with the help of Tombstone Builder Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can see all our content in its unabridged glory. And you can get all our research papers too. Understanding and Selecting Data Masking Management and Advanced Features Technical Architecture Pragmatic Key Management Understanding Data Encryption Systems Introduction Evolving Endpoint Malware Detection Behavioral Indicators Control Lost Understanding and Selecting a Database Security Platform Final Paper Available Malware Analysis Quant Final Paper Incite 4 U Which came first: the chicken or the Flame? Evidently the folks at Kaspersky have definitively proven that Flame was a pre-cursor to Stuxnet. Bully for them. What came first isn’t really important, rather highlighting what you already know. Adversaries are very good, if you are their target. They use advanced crypto and pretty much any other tactics to achieve their mission. The interesting thing about Flame, regardless of when it appeared, is how it gamed Windows Update. Most folks, even if they do harden detection, give patching a free pass, as patches update and change executables, config settings, and registry values. But if you can’t trust the patches? Ruh-roh. I’m doing a lot of research into evolving endpoint malware detection, as with attacks like Flame you don’t know what the malware looks like, so you need to watch what it does and block bad behavior. – MR LinkedOut: I’m not going to pick on LinkedIn for losing a bunch of passwords and then mishandling their public response. That’s pretty much par for the course with this sorts of breach, and considering how often they happen it’s obvious no one listens to us anyway. I won’t even slam them for neglecting to make clear to users that if they allowed the iPhone app to read their calendar, LinkedIn would grab their data. While it is incredibly obvious to anyone with an understanding of technology that linking your calendar to a social networking app might, you know, leak the data, folks seem to enjoy being shocked more than thinking for themselves. But I will suggest that these privacy issues are starting to really grow in the public consciousness as the overlap of cloud, mobility, and services begins to enhance the personal connection people have with things they stuff in their pants every day. If

In this post we will examine many of the features and functions of masking that go beyond the basics of data collection and transformation. The first, and most important, is the management interface for the masking product. Central management is the core addition that transforms masking from a simple tool into an enterprise data security platform. Central management is not new; but capabilities, and maturity, and integration are evolving rapidly. In the second part of today’s post we will discuss advanced masking functions we are beginning to see, to give you an idea of where these products are heading. Sure, all these products provide management of the basic functions, but the basics don’t fully encompass today’s principal use cases – the advanced feature set and management interfaces differentiate the various products, and are likely to drive your choice of product. Central Management This is the proverbial “single pane of glass” for management of data, policies, data repositories, and task automation. The user interface is how you interact with data systems and control the flow of information. A good UI can simplify your job, but a bad one will make you want to never use the product! Management interfaces have evolved to accommodate both IT management and non-technical stakeholders alike, allowing them to set policy, define workflows, understand risk, and manage where data goes. Some products even provide the capability to manage endpoint agents. Keep in mind that each masking platform has its own internal database to store policies, masks, reports, user credentials, and other pertinent information; and some offer visualization technologies and dashboards to help you see what exactly is going on with your data. The following is a list of management features to consider when evaluating the suitability of a masking platform: Policy Management: A policy is nothing more than a rule on how sensitive data is to be treated. Policies usually consist of a data mask – the thing that transforms data – and a data source the mask is applied to. Every masking platform comes with several predefined masks, as well as an interface to customize masks to your needs. But the policy interfaces go one step further, associating a mask with a data source. Some platforms take this one step further – allowing a policy to be automatically applied to specific data types, such as credit card numbers, regardless of source or destination. Policy management is typically simplified with predefined policy sets, as we will discuss below. Discovery: For most customers discovery has become a must-have feature – not least because it is essential for regulatory compliance. Data discovery is an active scan to first find data repositories, and then scan them for sensitive data. The discovery process works by scanning files and databases, matching content to known patterns (such as 9-digit Social Security numbers) or metadata (data that describes data structure) definitions. As sensitive data is discovered, the discovery tool creates a report containing both the location and a list of the sensitive data types found. Once data is discovered there are many options for what to do next. The report can be sent to interested parties, archived for compliance, or even fed back into the masking product for automatic policy enforcement. The discovery results can be used to build a catalog of metadata, physically map locations within a data center, and even present a risk score based on location and data type. Discovery can be tuned to look in specific locations, refined to look for as few or as many data types as the user is interested in, and automated to find preselected patterns on a regular schedule. Credential Management: Selection, extraction, and discovery of information from different data sources all require credentialed access (typically a user name and password) to the file or database in question. The goal is to automate masking as much as possible, so it would be infeasible to expect users to provide a user name and password to begin every masking task. The masking platform needs to either securely store credentials or use credentials from an access management system like LDAP or Active Directory, and supply seamlessly them as needed. Data Set Management: For managing test data sets, as well as for compliance, you need to track which data you mask and where you send it. This information is used to orchestrate moving data around the organization – managing which systems get which masked data, tracking when the last update was performed, and so on. As an example, think about the propagation of medical records: an insurance company, a doctor’s office, a clinical trial organization, and the federal government, all receive different subsets of the data, with different masks applied depending on which information each needs. This is the core function of data management tools, many of which have added masking capabilities. Similarly, masking vendors have added data management capabilities in response to customer demand for complex data orchestration. The formalization of how data sets are managed is also key for both automation and visualization, two topics we will discuss below. Data Subsetting: For large enterprises, masking is often applied across hundreds or thousands of databases. In these cases it’s incredibly important to be as efficient as possible to avoid overtaxing databases or saturating networks with traffic. People who manage data define the smallest data subset possible that still satisfies application testers’ needs for production quality masked data. This involves cutting down the number of rows exported/viewed, and possibly reducing the number of columns. Defining a common set of columns also helps clone a single masked data set for multiple environments, reducing the computational burden of creating masked clones. Automation: Automation of masking, data collection, and distribution tasks are core functions of every masking platform. The automated application of masking policies, and integration with third party systems that rely on masked data, drastically reduce workload. Some systems offer very rudimentary automation capabilities, such as UNIX cron jobs, while others have very complex features to manage remote jobs and work