Research

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.

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: