Research

Introduction Our entire profession is called “information security”, but surprisingly few of our technologies focus on actually protecting the data itself, as opposed to the infrastructure surrounding it. Data Loss Prevention emerged nearly 10 years ago to address exactly this problem. By peering inside files, network traffic, and other sources – and understanding both content and context – DLP provides new capabilities comparable to when we first started looking inside network packets. The Data Loss Prevention market is split into two broad categories of tools – full suites dedicated to DLP, and what we call “DLP Light”. There is lots of confusion about the differences between these approaches… and even their definitions. In this series we will focus on DLP Light – what it is, how it works, and how to rapidly take advantage of it. (For more information on full-suite Data Loss Prevention, see our white paper Understanding and Selecting a Data Loss Prevention Solution. Defining DLP Light We are talking about a subset of Data Loss Prevention, so we need to start with our definition of DLP: Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use, through deep content analysis. A full DLP suite includes network, storage, and endpoint capabilities; as well as a range of deep content analysis techniques such as document fingerprinting. DLP Light tools include a subset of those capabilities; they are generally features of, or integrated with, other security products – such as endpoint protection platforms, email security gateways, and next-generation firewalls. DLP Light tools tend to have some or all the following characteristics: Focused on a subset of ‘channels’. A DLP Light tool might focus on portable storage, email, web traffic, other channels, or a combination. Fewer/simpler content analysis techniques. Rather than providing a wide range of deep content analysis techniques, many of which are resource-intensive, DLP Light products tend to include a smaller set of techniques, or even a single method. The most common is pattern matching, which is the most commonly used technique in both full and Light DLP deployments. Less dedicated workflow. DLP Light tools are often integrated with, or features of, other security tools. As such, they lack the full self-contained workflow found in full DLP suites. You might ask, “So how is this still DLP?” The key defining characteristic of both full DLP and DLP Light is content analysis. If a tool can peer into network traffic or a file and sniff out something like a credit card number, it’s DLP. If all it does is rely on tagging/labeling, metadata, or contextual information… it isn’t DLP. The Role of DLP Light DLP Light plays an important role in a few different use cases: Organizations that already use the product the DLP Light tool integrates with – such as email security gateways – often want to start protecting sensitive data while constraining costs. Organizations that don’t require dedicated DLP tools. This is often due to less stringent or more circumscribed data security requirements. Organizations that want to scope out their DLP problem before investing in a dedicated tool. DLP Light can play a valuable role in helping assess data security risk. Organizations that want to start small and grow into full DLP. There is a bit of overlap between these cases, but they reflect the most common reasons we see people using DLP Light. Dedicated Data Loss Prevention is extremely powerful, but not appropriate for everyone. Next we will cover the technology side of DLP Light, and then we will finish with the Quick Wins process for rapidly deriving value from your implementation. Share:

At Securosis we tend to be passionate about security. We have the luxury of time (and lack of wingnuts yelling at us all day) to think about how security should work, and make suggestions for how to get there. We also have our own pet projects – areas of research that get us excited. We usually focus on ‘hot’ topics, because they pay the bills. We rarely get to step back and think outside the box about a security process that really needs to change. That’s why I’m very excited to be starting a new research project called Security Benchmarking, Going Beyond Metrics – interestingly enough, on security metrics and benchmarking. This topic is near and dear to my heart. I have been writing about metrics for years, and I broached the subject of benchmarking in my security methodology book (The Pragmatic CSO) back in 2007. To be candid, talking about security metrics – and more specifically security benchmarking – was way ahead of the market. Four years later, we still struggle to decide what we should count. Forget about comparing our numbers to other organizations to understand relative performance – which is how we would define a benchmark. It has been like trying to teach a toddler quantum physics. But we believe this idea’s time has come. In this series and the resulting white paper, I will revisit many of the ideas in The Pragmatic CSO, including updates based on industry progress since 2007. Ultimately, at Securosis we focus on practical (even pragmatic) application of research, so there won’t be any fluff or pie-in-the-sky handwaving. Just things you can start thinking about right now, with some actionable information to both rejuvenate your security metrics program and start comparing yourself against your peers. Before we jump in, thanks to our friends at nCircle for sponsoring this research. The rest of this series will appear on the complete (‘heavy’) side of our site and our heavy RSS feed. Introduction: Security Metrics As long as we have been doing security, we have been trying to count different aspects of our work. The industry has had vert limited success so far (yes – we are being very kind), so we need a better way to answer the question: “How effective are you at security?” The fundamental problem is that security is a nebulous topic, and at the end of the day the only important question is whether you are compromised or not – that is the ultimate measure of your effectiveness. But that doesn’t help communicate value to senior management or increase operational efficiency. The problem is further complicated by the literally infinite number of things to count. You can count emails and track which ones are bad – that’s one metric. So is the number of network flows, compared to how many of them are ‘bad’. If you can count it, it’s a metric. It may not be a good metric, but it is a metric. You can spend as much time as you like modeling, and counting, and correlating, and trying to figure out your “coverage” percentage, comparing the controls (always finite) to every conceivable attack (always infinite). But ultimately we have found that most security professionals do best keeping two sets of books. No, not like Worldcom did in the good old days, but two distinct sets of metrics: Important to senior management: Folks like the CIO, CFO, and CEO want to know whether you are ‘secure’ and how effective the security team is. They want to hear about the number of ‘incidents’, how much money you spend, and whether you hit the service levels you committed to. They tend to focus on those for ‘overhead’ functions – and whether you like it or not, security is overhead. Important to running your business: Distinct from business-centric numbers, you also need to measure the efficiency of your security processes. These are the numbers that make senior management eyes glaze over. Things like AV updates, time to re-image a machine or deploy a patch, number of firewall rule changes, and a host of other metrics that track what your folks are doing every day. The point of these numbers isn’t to gauge security quality overall, but to figure out how you can do your work faster and better. Of course, it’s almost impossible to improve things you don’t control. So we will focus on activities that can be directly impacted by the CSO and/or the security team. As we work through this series we will look at logical groupings of metrics that can be used for both operational and benchmarking purposes. But before we get ahead of ourselves, let’s define security benchmarking at a high level. Security Benchmarking Given our general failure to define and collect a set of objective, defendable measures of security effectiveness, impact, etc., a technique that can yield very interesting insight into your security environment is to compare your numbers to others. If you can get a fairly broad set of consistent data (both quantitative and qualitative), then compare your numbers to the dataset, you can get a feel for relative performance. This is what we mean by security benchmarking. Benchmarks have been used in other IT disciplines for decades. Whether for data center performance or network utilization, companies have always felt compelled to compare themselves to others. This hasn’t happened in security to date, mostly because we haven’t been sure what to count. If we can build some consensus on that, and figure out a way to collect and share that data safely, then benchmarking becomes much more feasible. Let’s discuss some metrics and why they would be interesting to compare to others: Number of incidents: Are you overly targeted? Or less effective at stopping attacks? The number of incidents doesn’t tell the entire story, but knowing how you fare relative to other is certainly interesting. Downtime for security issues: How effective you are at stopping attacks? And how severe is their impact? The downtime metric doesn’t capture everything, but it does get at the most visible impact of an attack. Number of activities: By tracking activity at a high level, you

Driven by the continued noise about the RSA and Comodo breaches, we have spent a lot of time stating the obvious this week. But then I remember that what is obvious to us may not be to everyone else. And even if it is obvious to you, sometimes you need a reminder because you are probably too busy fighting fires and answering questions from senior management (like “Don’t I take dumps in a Comodo?”) to remember the obvious stuff. So, once again, it is time to don the Captain Obvious suit and talk about layered security models. Rich reminded everyone about Crisis Communications yesterday and earlier this week; Adrian ranted about people fail trumping process fail regarding development every day of the week. Now it’s my turn. If you only have one line of defense, such as strong authentication (either two-factor or even a digital certificate) – you are doing it wrong. Yes, we still need layers in our security models. You cannot assume that any specific control will be effective, so you need a variety of controls to ensure critical information is adequately protected. That’s the underlying concept of the vaults idea balloon I have been working on. Depending on the sensitivity of the information, you layer additional controls until it’s sufficiently difficult to compromise that information. Note that I said sufficiently hard – Captain Obvious reminds us that everything can be broken. When you are building your threat models, you don’t assume your user is trusted, even after they authenticate, right? Remember, a device can be compromised after authenticating just as easily as before. Or someone could be holding a gun to your user’s head, which makes most folks pretty well willing to provide access to anything the attacker wants. That’s another reason the RSA and Comodo breaches should be business as usual. Factor in that you now have a bit less trust in the authentication layer. How does that change what you do? This is why we also advocate monitoring everything, looking for not normal, and being able to react faster and better to any situation. Yes, your controls will fail. Even when you layer them. So constantly checking for out-of-the-ordinary behavior may give you early warning that something has been pwned. In a post earlier this week, Rob Graham linked to a South Park clip where Captain Hindsight points out that BP’s critical error was not having a backup valve for the backup valve for the regular valve. Of course. And you know that in your shop Captain Hindsight will make an appearance when you get compromised. That’s part of the job, but you can make sure you are doing all you can to reduce the likelihood that one control failure will provide open access. That means don’t outside without your layers on. Photo Credit: “Captain Obvious” originally uploaded by Gareth Jones Share:

I realize that I have a tendency to overplay my emergency services background, but it does provide me with some perspective not common among infosec professionals. One example is crisis communications. While I haven’t gone through all the Public Information Officer (PIO) training, basic crisis communications is part of several incident management classes I have completed. I have also been involved in enough major meatspace and IT-related incidents to understand how the process goes. In light of everything from HBGary, to TEPCO, to RSA, to Comodo, it’s worth taking a moment to outline how these things work. And I don’t mean how they should go, but how they really play out. Mostly this is because those making the decisions at the executive level a) have absolutely no background in crisis communications, b) think they know better than their own internal experts, and c) for some strange reason tend to think they’re different and special and not bound by history or human nature. You know – typical CEOs. These people don’t understand that the goal of crisis communications is to control the conversation through honesty and openness, while minimizing damage first to the public, then second to your organization. Reversing those priorities almost always results in far worse impact to your organization – eventually, of course, the public eventually figures out you put them second and will make you pay for it later. Here’s how incidents play out: Something bad happens. The folks in charge first ask, “who knows” to figure out whether they can keep it secret. They realize it’s going to leak, or already has, so they try to contain the information as much as possible. Maybe they do want to protect the public or their customers, but they still think they should keep at least some of it secret. They issue some sort of vague notification that includes phrases like, “we take the privacy/safety/security of our customers very seriously”, and “to keep our customers safe we will not be releasing further details until…”, and so on. Depending on the nature of the incident, by this point either things are under control and there is more information would not increase risk to the public, or the attack was extremely sophisticated. The press beats the crap out of them for not releasing complete information. Competitors beat the crap out of them because they can, even though they are often in worse shape and really just lucky it didn’t happen to them. Customers wait and see. They want to know more to make a risk decision and are too busy dealing with day to day stuff to worry about anything except the most serious of incidents. They start asking questions. Pundits create more FUD so they can get on TV or in the press. They don’t know more than anyone else, but they focus on worst-case scenarios so it’s easier to get headlines. The next day (or within a few hours, depending on the severity) customers start asking their account reps questions. The folks in charge realize they are getting the crap beaten out of them. They issue the second round of information, which is nearly as vague as the first, in the absurd belief that it will shut people up. This is usually when the problem gets worse. Now everyone beats the crap out of the company. They’ve lost control of the news cycle, and are rapidly losing trust thanks to being so tight-lipped. The company trickles out a drivel of essentially worthless information under the mistaken belief that they are protecting themselves or their customers, forgetting that there are smart people out there. This is usually where they use the phrase (in the security world) “we don’t want to publish a roadmap for hackers/insider threats” or (in the rest of the world), “we don’t want to create a panic”. Independent folks start investigating on their own and releasing information that may or may not be accurate, but everyone gloms onto it because there is no longer any trust in the “official” source. The folks in charge triple down and decide not to say anything else, and to quietly remediate. This never works – all their customers tell their friends and news sources what’s going on. Next year’s conference presentations or news summaries all dissect how badly the company screwed up. The problem is that too much of ‘communications’ becomes a forlorn attempt to control information. If you don’t share enough information you lose control, because the rest of the world a) needs to know what’s going on and b) will fill in the gaps as best they can. And the “trusted” independent sources are press and pundits who thrive on hyperbole and worst-case scenarios. Here’s what you should really do: Go public as early as possible with the most accurate information possible. On rare occasion there are pieces that should be kept private, but treat this like packing for a long trip – make a list, cut it in half, then cut it in half again, and that’s what you might hold onto. Don’t assume your customers, the public, or potential attackers are idiots who can’t figure things out. We all know what’s going on with RSA – they don’t gain anything by staying quiet. The rare exception is when things are so spectacularly fucked that even the collective creativity of the public can’t imagine how bad things are… then you might want them to speculate on a worst case scenario that actually isn’t. Control the cycle be being the trusted authority. Don’t deny, and be honest when you are holding details back. Don’t dribble out information and hope it will end there – the more you can release earlier, the better, since you then cut speculation off at the knees. Update constantly. Even if you are repeating yourself. Again, don’t leave a blank canvas for others to fill in. Understand that everything leaks. Again, better for you to provide the information than an anonymous insider. Always always put your customers and the public first. If not, they’ll know

Beyond the base FAM features, there are two additional functions to consider, depending on your requirements. We expect these to eventually join the base feature set, but for now they aren’t consistent across the available products. Activity Blocking (Firewall) As with many areas of security, once you start getting alerts and reports of incidents ranging from minor accidents to major breaches, you might find yourself wishing you could actually block the incident instead of merely seeing an alert. That’s where activity blocking comes into place – some vendors call this a ‘firewall’ function. Using the same kinds of policies developed for activity analysis and alerts, you can choose to block based on various criteria. Blocking may take one of several different forms: Inline blocking, if the FAM server or appliance is between the user and the file. The tool normally runs in bridge mode, so it can selectively drop requests. Agent-based blocking, when the FAM is not inline – instead an agent terminates the connection. Permission-based blocking, where file permissions are changed to prevent the user’s access in real time. This might be used, for example, to block activity on systems lacking a local agent or inline protection. Those three techniques are on the market today. The following methods are used in similar products and may show up in future updates to existing tools: TCP RESET is a technique of “killing” a network session by injecting a “bad” packet. We’ve seen this in some DLP products, and while it has many faults, it does allow real-time blocking without an inline device, and does not require a local agent or the ability to perform permission changes. Management system integration for document management systems. Some provide APIs for blocking, and others provide plugin mechanisms which can provide this functionality. All blocking tools support both alert and block policies. You could, for example, send an alert when a user copies a certain number of files out of a sensitive directory in a time period, followed by blocking at a higher threshold. DLP Integration Data Loss Prevention plays a related role in data security by helping identify, monitor, and protect based on deep content analysis. There are cases where it makes sense to combine DLP and FAM, even though they both provide benefits on their own. The most obvious option for integration is to use DLP to locate sensitive information and pass it to FAM; the FAM system can then confirm permissions are appropriate and dynamically create FAM policies based on the sensitivity of the content. A core function of DLP is its ability to identify files in repositories which match content-based polices – we call this content discovery, and it is not available in FAM products. Here’s how it might work: FAM is installed with policies that don’t require knowledge of the content. DLP scans FAM-protected repositories to identify sensitive information, such as Social Security Numbers inside files. DLP passes the scan results to FAM, which now has a list of files containing SSNs. FAM checks permissions for the received files, compares them against its policies for files containing Social Security Numbers, and applies corrective actions to comply with policy (e.g., removing permissions for users not authorized to access SSNs). FAM applies an SSN alerting policy to the repository or directory/file. This is all done via direct integration or within a single product (at least one DLP tool includes basic FAM). Even if you don’t have integration today, you can handle this manually by establishing content-driven policies within your FAM tool, and manually applying them based on reports from your DLP product. Share:

I am probably in the minority, but when I buy something I think of it as mine. I paid for it so I own it. I buy a lot of stuff I am not totally happy with, but that’s the problem with being a tinkerer. Usually I think I can improve on what I purchased, or customize my purchase to my liking. This could be as simple as adding sugar to my coffee, or having a pair of pants altered, or changing the carburetor on that rusty Camaro in my backyard. More recently it’s changing game save files or backing out ‘fixes’ that break software. It’s not the way the manufacturer designed it or implemented it, but it’s the way I want it. One man’s bug is another man’s feature. But as the stuff I bought is mine – I paid for it, after all – I am free to fix or screw things up as I see fit. Somewhere along the line, the concept of ownership was altered. We buy stuff then treat it as if it’s not ours. I am not entirely sure when this concept went mainstream, but I am willing to bet it started with software vendors – you know, the ones who write those End User License Agreements that nobody reads because that would be a waste of time and delay installing the software they just bought. I guess this is why I am so bothered by stories like Sony suing some kid – George Holtz – for altering a PlayStation 3. Technically they are not pissed off at him for altering the function of his PlayStation – they are pissed that he taught others how to modify their consoles so they can run whatever software they want. The unstated assumption is that anyone who would do such a thing is a scoundrel and criminals, out to pirate software and destroy hard-working companies (And all their employees! Personally!). These PlayStations were purchased – personal property if you will – and their owners should be able to do as they see fit with their possessions. Don’t like Sony’s OS and want to run Linux? Those customers bought the PS3s (and Sony promised support, then reneged) so they should be able to run what they want without interference. It’s not that George is trying to resell the PlayStation code, or copy the PlayStation and sell a derived work. He’s not reselling Halo or an Avatar Blu-ray; he’s altering his own stuff to suit his needs, and then sharing. This is not an issue of content or intellectual property, but of personal property. Sony should be able to void his warranty, but coming after him legally is totally off-the-charts insane IMO. Now I know Sony has better lobbyists than either George or myself, so it’s much more likely that laws – such as the Digital Millennium Copyright Act (DCMA) – reflect their interests rather than ours. I just can’t abide by the notion that someone sells me a product and then demands I use it only as they see fit. Especially when they want to prohibit my enjoyment because there is a possibility someone could run pirated software. If you take my money, I am going to add hard drives or memory of software as I like. If companies like Sony don’t like that, they should not sell the products. Cases like this call the legitimacy of the DCMA into question. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in Macworld on private browsing. Protect your privacy: online shopping. Mike’s first Macworld article. Rich quoted in the New York Times on RSA. A great response to Rich’s Table Stakes article. John Strand does a good job of presenting his own spin. Index link to Mike & Rich’s Macworld series on privacy. Adrian’s Dark Reading article on McAfee acquisition. Rich quoted on RSA breach. Adrian’s Dark Reading post on DB Security in the cloud. Favorite Securosis Posts Rich: Agile and Hammers – They Don’t Fix Stupid. I still don’t fully get how people glom on to something arbitrary and turn it into a religion. Mike Rothman: Agile and Hammers: They Don’t Fix Stupid. Rare that Adrian wields his snark hammer. Makes a number of great points about people – not process – FAIL. Gunnar Peterson: The CIO Role and Security. Adrian Lane: Crisis Communications. Other Securosis Posts FAM: Additional Features. McAfee Acquires Sentrigo. Incite 3/23/2011: SEO Unicorns. RSA Releases (Almost) More Information. FAM: Core Features and Administration, Part 1. Death, Taxes, and M&A. How Enterprises Can Respond to the RSA/SecurID Breach. Network Security in the Age of Any Computing: Index of Posts. Favorite Outside Posts Rich: Why Stuxnet Isn’t APT. Mike Cloppert is one of the few people out there talking about APT who actually knows what he’s talking about. Maybe some of those vendor marketing departments should read his stuff. Mike Rothman: The MF Manifesto for Programming, MF. Back to basics, MFs. And that is one MFing charming pig. Adrian Lane: A brief introduction to web “certificates”. While I wanted to pick the MF Manifesto as it made me laugh out loud, Robert Graham’s post on cryptography and succinct explanation of the Comodo hack was too good to pass up. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Top News and Posts Dozens of exploits released for popular SCADA programs. Twitter, Javascript Defeat NYT’s $40m Paywall. Apple patches unused Pwn2Own bug, 55 others in Mac OS. Spam Down 40 Pecent in Rustock’s Absence. The Challenge of Starting an Application Security Program. Hackers make off with TripAdvisor’s membership list. Talk of Facebook Traffic Being Detoured. Firefox 4 Content Security Policy feature. Firefox

McAfee announced this morning its intention to acquire Sentrigo, a Database Activity Monitoring company. McAfee has had a partnership with Sentrigo for a couple years, and both companies have cooperatively sold the Sentrigo solution and developed high-level integration with McAfee’s security management software. McAfee’s existing enterprise customer base has shown interest in Database Activity Monitoring, and DAM is no longer as much of an evangelical sale as it used to be. Sentrigo is a small firm and integration of the two companies should go smoothly. Despite persistent rumors of larger firms looking to buy in this space, I am surprised that McAfee finally acquired Sentrigo. McAfee, Symantec, and EMC are the names that kept popping up as interested parties, but Sentrigo wasn’t the target discussed. Still, this looks like a good fit because the core product is very strong, and it fills a need in McAfee’s product line. The aspects of Sentrigo that are a bit scruffy or lack maturity are the areas McAfee would want to tailor anyway: workflow, UI, reporting, and integration. I have known the Sentrigo team for a long time. Not many people know that I tried to license Sentrigo’s memory scanning technology – back in 2006 while I was at IPLocks. Several customers used the IPLocks memory scanning option, but the scanning code we licensed from BMC simply wasn’t designed for security. I heard that Sentrigo architected their solution correctly and wanted to use it. Alas, they were uninterested in cooperating with a competitor for some odd reason, but I have maintained good relations with their management team since. And I like the product because it offers a (now) unique option for scraping SQL right out of the database memory space. But there is a lot more to this acquisition that just memory scraping agents. Here are some of the key points you need to know about: Key Points about the Acquisition McAfee is acquiring a Database Activity Monitoring (DAM) technology to fill out their database security capabilities. McAfee obviously covers the endpoints, network, and content security pieces, but was missing some important pieces for datacenter application security. The acquisition advances their capabilities for database security and compliance, filling one of the key gaps. Database Activity Monitoring has been a growing requirement in the market, with buying decisions driven equally by compliance requirements and response to escalating use of SQL injection attacks. Interest in DAM was previously to address insider threats and Sarbanes-Oxley, but market drivers are shifting to blocking external attacks and compensating controls for PCI. Sentrigo will be wrapped into the Risk and Compliance business unit of McAfee, and I expect deeper integration with McAfee’s ePolicy Orchestrator. Selling price has not been disclosed. Sentrigo is one of the only DAM vendors to build cloud-specific products (beyond a simple virtual appliance). The real deal – not cloudwashing. What the Acquisition Does for McAfee McAfee responded to Oracle’s acquisition of Secerno, and can now offer a competitive product for activity monitoring as well as virtual patching of heterogeneous databases (e.g., Oracle, IBM, etc). While it’s not well known, Sentrigo also offers database vulnerability assessment. Preventative security checks, patch verification, and reports are critical for both security and compliance. One of the reasons I like the Sentrigo technology is that it embeds into the database engine. For some deployment models, including virtualized environments and cloud deployments, you don’t need to worry about the underlying environment supporting your monitoring functions. Most DAM vendors offer security sensors that move with the database in these environments, but are embedded at the OS layer rather than the database layer. As with transparent database encryption, Sentrigo’s model is a bit easier to maintain. What This Means for the DAM Market Once again, we have a big name technology company investing in DAM. Despite the economic downturn, the market has continue to grow. We no longer estimate the market size, as it’s too difficult to find real numbers from the big vendors, but we know it passed $100M a while back. We are left with two major independent firms that offer DAM; Imperva and Application Security Inc. Lumigent, GreenSQL, and a couple other firms remain on the periphery. I continue to hear acquisition interest, and several firms still need this type of technology. Sentrigo was a late entry into the market. As with all startups, it took them a while to fill out the product line and get the basic features/functions required by enterprise customers. They have reached that point, and with the McAfee brand, there is now another serious competitor to match up against Application Security Inc., Fortinet, IBM/Guardium, Imperva, Nitro, and Oracle/Secerno. What This Means for Users Sentrigo’s customer base is not all that large – I estimate fewer than 200 customers world wide, with the average installation covering 10 or so databases. I highly doubt there will be any technology disruption for existing customers. I also highly doubt this product will become shelfware in McAfee’s portfolio, as McAfee has internally recognized the need for DAM for quite a while, and has been selling the technology already. Any existing McAfee customers using alternate solutions will be pressured to switch over to Sentrigo, and I imagine will be offered significant discounts to do so. Sentrigo’s DAM vision – for both functionality and deployment models – is quite different than its competitors, which will make it harder for McAfee to convince customers to switch. The huge upside is the possibility of additional resources for Sentrigo development. Slavik Markovich’s team has been the epitome of a bootstrapping start-up, running a lean organization for many years now. They deserve congratulations for making it this less than $10M $20M in VC funds. They have been slowly and systematically adding enterprise features such as user management and reporting, broadening platform support, and finally adding vulnerability assessment scanning. The product is still a little rough around the edges; and lacks some maturity in UI and capabilities compared to Imperva, Guardium, and AppSec – those products have been fleshing out their capabilities for years more. In a

It seems blog popularity is a double edged sword. Yes, thousands of folks read our stuff every day. But that also means we are a target for many SEO Experts, who want to buy links from us. No, we don’t sell advertising on the site. But that doesn’t stop them from pummeling us with a bunch of requests each week. Most of the time we are pretty cordial, but not always. Which brings us to today’s story. It seems Rich was a little uppity yesterday and decided to respond to the link request with a serious dose of snark. Rich: Our fee is $10M US. Cash. Non-sequential bills which must be hand delivered on a unicorn. And not one of those glued-on horn jobs. Must be the real thing with a documented pedigree. I guess Rich thought that it was yet another bot sending a blind request and that his list of demands would disappear into the Intertubes, but alas, it wasn’t a bot at all. This SEO fellow and Rich then proceeded to debate the finer issues of unicorn delivery. Interestingly enough, the $10MM fee didn’t seem to be an issue. SEO Guy: Thanks for getting back. I may have some issues fulfilling your request. The $10M will not be a problem, however I don’t know if you’ve noticed, but unicorns are a heavily-endangered species. Even to rent one would require resources that exceed my nearly limitless budget. Do you know how much a unicorn pilot charges by the hour? Rich: African or European unicorn? SEO Guy: How far do you live from Ireland? Rich: About 7000 miles, but my wife has unknown ancestors still living there and I have red hair. Not sure if that will get a discount. SEO Guy: Would it be okay if the unicorn itself delivered the (what I am assuming is a golden satchel of) money instead? I know you want it hand-delivered (mind out of the gutter) and that unicorns lack hands. Rich: Excellent point and I see that will save on the piloting fees. Yes, but only if we can time delivery for my daughter’s birthday and you also include a frosted cupcake with a candle on it for her. I think she’d like that. You can deduct the cost of the cupcake from the $10M, if that helps…but not the cost of the candle. So yes, as busy as we are with launching our super sekret project, polishing the CCSK training course, and all our client work, we still have time to give a hard time to a poor sap trying to buy a few links for his SEO clients. So every time I’m grumpy because QuickBooks Online is down, the EVDO service in my favorite coffee shop is crap, and I have to restructure a white paper – I can just appreciate the fact that I’m not the SEO guy. Yes, I do have to deal with asshats every day. But they are asshats of my own choosing. This guy doesn’t get to choose who he solicits and I’m sure a debate about unicorns was the highlight of his day of drudgery. Yes, I’m a lucky guy, and sometimes I need an SEO unicorn to remind me. -Mike Photo credits: “Unicorns!” originally uploaded by heathervescent Incite 4 U Testing my own confirmation bias: There are many very big-brained folks in security. Errata’s Rob Graham is one of them. Entering a debate with Rob is kind of like fighting a lion. You know you don’t have much of a chance; you can only hope Rob gets bored with you before he mauls your arguments with well-reasoned responses. So when Rob weighed in on Risk Management and Fukushima, I was excited because Rob put into words many of the points I’ve been trying (unsuccessfully) to make for years about risk management. But to be clear, I want to believe Rob’s arguments, because I am no fan of risk metrics (at least the way we practice them today). His ideas on who is an expert (and how that changes), and what that expert needs to do (have the most comprehensive knowledge of all the uncertainties) really resonated with me. Maybe you can model it out, maybe you can’t. But ultimately we are playing the odds and that’s a hard thing to do, which is why we focus so heavily on response. Now Alex Hutton doesn’t back down and has a well reasoned response as well. Though it seems (for a change) that both Rob and Alex are talking past each other. Yes, my appreciation of Rob’s arguments could be my own biases (and limited brainpower) talking, which wouldn’t be the first time. – MR Careful with that poison: Some days the security industry is like cross-breeding NASCAR with one of those crappy fashion/cooking/whatever reality shows. Everyone’s waiting for the crash, and when it happens they are more than happy to tell you how they would have done it better. As analysts we get used to the poison pill marketing briefs. You know, the phishing email or press release designed to knock the competition down. And there is no shortage of them filling my inbox after the RSA breach. At least NASCAR has the yellow caution flag to slow things down until they can get the mangled cars off the track. But I have yet to see one brief that shows any understanding of what happened or customer risk/needs. So I either delete them without reading or send back a scathing response. I have yet to see one of these work with a customer/prospect, so it all comes off as little more than jealous sniping. And besides, I know RSA isn’t the first security company to be breached, just one of the first to disclose, and I doubt any of the folks sending out this poison could survive the same sort of attack. If they aren’t already pwned, that is. (No link for this one since you all are probably getting the same emails). – RM No poop in the sandbox: Good article in Macworld describing the

I did not see the original Agile Ruined My Life post until I read Paul Krill’s An agile pioneer versus an ‘agile ruined my life’ critic response today. I wish I had, as I would have used Mr. Markham’s post as an example of the wrong way to look at Agile development in my OWASP and RSA presentations. Mr. Markham raises some very good points, but in general the post pissed me off: it reeks of irresponsibility and unwillingness to own up to failure. But rather than go off on a tirade covering the 20 reasons that post exhibits a lack of critical thinking, I’ll take the high road. Jon Kern’s quotes in the response hit the nail on the head, but did not include an adequate explanation of why, so I offer a couple examples. I make two points in my Agile development presentation which are relevant here. First: The scrum is not the same thing as Agile. Scrum is just a technique used to foster face-to-face communication. I like scrum and have had good success with it because, a) it promotes a subtle form of peer pressure in the group, and b) developers often come up with ingenious solutions when discussing problems in an open forum. Sure, it embodies Agile’s quest for simplicity and efficiency, but that’s just facility – not the benefit. Scrum is just a technique, and some Agile techniques work in particular circumstances, while others don’t. For example, I have never got pair programming to work. That could be due to the way I paired people up, or the difficulty of those projects might have made pairs impractical, or perhaps the developers were just lazy (which definitely does happen). The second point is that people break process. Mr. Markham does not accept that, but sorry, there are just not that many variables in play here. We use process to foster and encourage good behavior, to minimize poor behaviors, and to focus people on the task at hand. That does not mean process always wins. People are brilliant at avoiding responsibility and disrupting events. I couch Agile pitfalls in terms of SDL – because I am more interested in promoting secure code development – but the issues I raise cause general project failures as well. Zealots. Morons. Egoists. Unwitting newbies. People paranoid about losing their jobs. All these personality types figure into the success (or lack thereof) of Agile teams. Sometimes Agile looses to that passive-aggressive bastard at the back of the room. Maybe you need process adjustments, or perhaps better process management, or just maybe you need better people. If you use a hammer to drive a screw into the wall, don’t be surprised when things go wrong. Use the wrong tool or technique to solve a problem, and you should expect bad things to happen. Agile techniques are geared toward reducing complexity and improving communication; improvements in those two areas mean better likelihood of success, but there’s no guarantee. Especially when communication and complexity are not your problem. Don’t blame the technique – or the process in general – if you don’t have the people to support it. Share:

Ben Franklin was a pretty smart dude. My favorite quote of his is: “In this world nothing is certain but death and taxes.” For a couple hundred years, that was pretty good. But at this point, I’ll add mergers and acquisitions as the third certainty in this world. Maybe also that your NCAA bracket will get busted by some college you’ve never heard of (WTF VCU?). We saw this over the weekend. AT&T figures it’s easier and cheaper to drop $39 billion buying T-mobile than build their own network (great analysis by GigaOm) or gain market share one customer at a time. And in security, there are always plenty of deals happening or about to happen. Remember, security isn’t a standalone market over time, so pretty much all security companies will be folded into something or other. Take, for instance, WebSense trying to sell for $1 billion. And no, I’m not going to comment on whether WBSN is worth a billion. That’s another story for another day. Or the fact that given Intel’s balance sheet, McAfee will likely start taking down bigger targets. All we can count on is that there will be more M&A. But let’s take a look at why deals tend to be the path of least resistance for most companies. Outsourced R&D: Anyone who’s ever worked in a large company knows how hard it is to innovate internally. There is a lot of inertia and politics to overcome to get anything done. In many cases it’s easier to just buying some interesting technology, since the buyer has a snowball’s chance in hell of building it in-house. Distribution leverage: There are clear economies of scale in most businesses. So the more stuff in a rep’s bag and the bigger their market share, the more likely they’ll be able to sell something to someone. That’s what’s driving Big IT to continue buying everything. This also drive deals like AT&T/T-Mobile, because they are buying not just the network, but also the customers. Two drunks holding each other up: Yep, we also see deals involving two struggling companies, basically throwing a hail mary pass in hopes of surviving. That doesn’t usually work out too well. And those are just off the top of my head. I’m sure there are another 5-10 reasonable justifications, but from an end-user standpoint let’s cover some of the planning you have to make for the inevitable M&As. We will break the world up into BD (before deal) and AD (after deal). Before Deal: Assess vendor viability: First assess all your security vendors. Rank them on a scale from low viability (likely to be acquired or go out of business) to rock solid. Assess product criticality: Next look at all your security products and rate them on a scale from non-critical to “life is over if it goes down.” Group into quadrants: Using vendor viability and product criticality, you can group all your products into a few buckets. I recommend 4 because it’s easy. This chart should give you a good feel for what I’m talking about. Define contingency plans: For products in the “Get Plan B now” bucket, make sure you have clear contingency plans. For the other quadrants, think about what you’d do if there was M&A activity for those offerings, but they are less urgent than having a plan for the critical & fragile items. After Deal: Call your rep: Odds are your rep will be a pretty busy guy/gal in the days after a deal is announced. And there is a high likelihood they won’t know any more than you. But get in line and hear the corporate line about how nothing will change. Yada yada yada. Then, depending how much leverage you have, ask for a meeting with the buyer’s account team. And then extract either some pricing or product concessions. The first renewal right after a deal closes is the best time to act. They want to keep you (or the deal looks like crap), so squeeze and squeeze hard. Call the competition: Yes, the competition will be very interested in getting back in, hoping they can use the deal’s uncertainty as a wedge. Whether you are open to swapping out the vendor or not, bring the other guys in to provide additional leverage. Revisit contingency plans: You might have to pull the trigger even if you don’t want to, so it’s time to take the theoretical plan you defined before the deal, and adjust it for reality now that the deal has occurred. Evaluate what it would take to switch, assess the potential disruption, and get a very clear feel for how tough it would be to move. Don’t to share that information with vendors, but you need it. None of this stuff is novel, but it’s usually a good reminder of the things you should do, but may not get around to. Given the number of deals we have seen already this year, and the inevitably accelerating deal flow, it’s better to be safe than sorry. Share: