Research

As we wrap up our series on Security Benchmarking, we find it instructive to actually walk through a scenario and apply the process. Yes, the scenario is a bit contrived, but we’ll use it to hit the high points of the process, deciding where to start, collecting the data, establishing the peer group and communicate the findings. Keep in mind that we focus on getting quick wins, showing immediate value, building momentum and leveraging that momentum for programatic success. Scenario For our case study, let’s use a mid-tier financial company as our example. I’d say large enterprise, but in reality there are a lot of nuances and moving pieces within a large enterprise that need more detailed discussion. So let’s keep it relatively simple. Likewise, we picked the financial vertical because of 1) need and 2) availability of data. The reality of the financial industries regulatory oversight has created a general perspective of security first and data-centricity (yes, these are the folks that try to do risk management for a living) means these businesses are move likely to embrace a benchmarking mentality. In our (contrived) scenario, the Board drove the hiring a new CISO to “fix security.” As easy as it is to think this was just catering to a board directive, the senior team seems to have a commitment to fix things and do it the right way. So the CISO has a clear honeymoon period and some leeway in thinking somewhat unconventionally about how to build the security program. The new CISO still spends some time figuring out what’s installed and what’s not working, but he knows the organization has AV deployed, they use an external scanning service, and do a pretty good job of patching on internal systems. Yet, like many smaller financial institutions they use hosted applications for most of their business processing. So a lot of their data is not within their direct control. Over the past few years, the organization has had a handful of incidents, but none really resulted in major data loss. Thus the CISO was pleasantly surprised when he got the mandate to fix the security program, when it wasn’t outwardly broken. The senior team came to the conclusion they are living on borrowed time and want to act decisively to make sure they are ready when the brown stuff hits the fan (which it inevitably will). See? We told the you the scenario was contrived, but without a senior-level mandate to make changes in implement a security program, getting any kind of security metrics/benchmarking initiative going will be difficult. Where Do You Start? Now the CISO has to figure out where to start. He’s decided that he wants to figure out where his most apparent gaps are. You know, the ones you can drive a Mack Truck through. So he starts with a comprehensive risk assessment to build a baseline, but he also wants to compare his environment to other like-sized companies (both in and out of his industry) to figure out how he compares to those organizations. Keep in mind, boiling the ocean and trying to do everything at this point is a bad idea. He’d get buried in the nuances of the data and not get anything done, which could endanger his entire security program. So he needs to ask the following questions: What do you need to achieve? Where are the key operational problems? This is where you always have to start. In our case study, the CISO is looking to identify his most critical gaps, and given the luck they’ve had in not having a huge data loss even with a few breaches, he wants to start with incident response. What data do you have? Next you have to figure out if you have the data or can get it easily. With incident data, the reality is the findings from the forensics investigations exist, but haven’t been put in any kind of format for comparison. But the data exists, so it makes sense to keep pressing down this path. If the data doesn’t exist or can’t be gathered quickly, then it’s time to look at Plan B. You don’t want to hold up the effort because it’s all about getting the quick win. Where will be most impactful to show comparative data? Selecting to focus initially on incident response represents a pretty shrewd move for the new CISO. He knows the board and senior management is sensitive to not getting nailed, as well as having a set of reasonable consensus metrics available (from CIS), and having the data. This increases the chances of success. Peer Groups and Service Providers Next, our CISO has to define the peer group for analysis. This isn’t brain surgery. He’ll need to compare to other financials (duh!), but also companies in other regulated industries (like healthcare and utilities) of a similar size. The good news is there are a ton of mid-sized hospital groups, as well as many community utilities, with similarly sensitive data. But how do they get their hands on that kind of data for comparison purposes? Now we go back and revisit the selection criteria for any kind of provider you’d think about for benchmarking services. Remember, these folks have to 1) have access to the data you’d need and 2) be able to protect the data you share with them. To be clear, you may not be able to get everything done with just one provider. In our case study here, the CISO will actually pick two. The first is his regional bank ISAC, who has been gathering data from its members for a while. The second is a commercial benchmarking offering, since they have more data about other industries that aren’t the focus of the ISAC. In reality, the CISO would like to just have one provider, but until a critical mass of data for many verticals is captured, he’ll need to piecemeal the solution to solve the problem. Analyze Equipped with data regarding his first

As is (now) our custom, we post a set of links to each blog series as it wraps up. This both gives us an easy way to find all our posts, and acknowledges that not everyone wants our complete feed and may want to read posts once they’re all written. As always, we love feedback on our work in progress. Yes, it’s time consuming to take time out for comment on specific posts. But remember that pretty much all our research is available free of charge, so it’s not too much to ask for a little constructive criticism on our work, is it? Please take a look and sink your teeth in. Introduction Security Metrics (from 40,000 feet) Collecting Data Systematically Sharing Data Safely Defining Peer Groups and Analyzing Data Communications Strategies Continuous Improvement You Can’t Benchmark Everything Benchmarking in Action As always, we thank you for reading, commenting, and making our research better. Share:

The Apple-ification of my home continues, as I got an Apple TV as an early birthday present. Tinkerer that I am, I thought “Wouldn’t it be great to hardwire it with Cat5 cable to the Airport Extreme? Download speeds will be awesome”. So I changed the existing phone lines (I’ll never use a POTS land line again) to Ethernet. Which meant changing all the phone jacks, and then the wall plates. And rewiring the central connections. And putting a new router in the closet. And adding new power to the closet. And wiring in a small low-voltage fan. It was the snowball effect, but this was one of the first times I have not minded, because I have Giant Freakin’ Toolbox! It was not always this way. For many years I would find something broken around the house and attempt to fix it. I am a guy, and that’s what I do. You know, something simple like a door latch that’s not working. More often than not, the whole process would just piss me off because it always involved “The Search”. Searching for my tools. Where had they gone to? Where was the Torx wrench I needed? Where was the right screwdriver – the right size with the hardened steel tip? What happened to the beautiful German wood chisels I got for Christmas? When you don’t live in your own house for four years (which happened to me with my previous employer) tools disappear. When you don’t have kids, there are only a couple of options for who used them. As far as I can tell the dogs have no interest in carpentry or automotive repair. You know who to ask about tool storage in random locations, but the question “Have you seen… ” is just not worth asking. The answer, “No. I have no idea” just makes me angrier. On the opposite end of that equation, best case, your wife will only say “No.” – worst case she’ll be pissed at you for insinuating she lost your tools. Then you stumble upon a tool you weren’t looking for – during your desperate search for those tools you need – in the bathroom cupboard, on top of a picture frame, in a box in the attic, or in that decorative ceramic vase in the dining room. During The Search – which takes longer than the time to fix the busted stuff – I would find other broken things that had a higher priority than the stuff I originally set out to fix. More tool searching ensued. You make a trip to Home Depot right after you post missing tool flyers around the house with pictures of your orbital sander. You look at the clock and half the day is gone. Two birthdays ago, my wife got me two giant tool chests, one fitting right on top of the other. With their wonder-twin powers they form Giant Freakin’ Toolbox! When she bought them every guy in the neighborhood showed up – seeing the two boxes in the driveway – and ‘helped’ her assemble then. OK, maybe ‘help’ is the wrong word because they did all the work. And maybe her bikini and the free beer helped too, but she managed to get 6 guys over to the house and they set up the toolbox. She was miffed to discover toolboxes and beer were the main attraction, but she got over it. I was so happy with the present I spent two days going through every square inch of our home to gather up the tools and place them in their new home. Now every tool I own resides there. Every tool is clean. Every drawer is labelled. Almost every tool has been accounted for – except some of the fine German wood chisels that were destroyed by a friend while prying the heads from a small block Chevy. Now projects take 2-5 minutes – perhaps 7 with cleanup. I built a wall bracket and installed a central vacuum system in a couple hours. I can change a light switch or adjust faucets without thinking about it. The time savings and reduction in frustration are astounding. I even assembled a small set of basic tools right by the garage door so ahem – anyone else needing tools can find a hammer, a basic screwdriver and pliers and not go rummaging in the tool chest. Giant Freakin’ Toolbox has a lock! I love my Apple electronics, but they don’t compare to Giant Freakin’ Toolbox. Best. Gift. Ever. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in CIO.in. Rich quoted in ComputerWorld. Adrian’s Dark Reading post on Cloud DB Security. Favorite Securosis Posts Adrian Lane: Dropbox Should Mimic CrashPlan. Mike Rothman: How to Read and Act on the 2011 Verizon DBIR. This is a gold mine, and you could get buried alive. Rich deciphers it. Rich: Categorizing FUD. My prediction: everyone else also chooses this one. Other Securosis Posts Oracle CVSS: ‘Partial+’ is ‘Useful-‘. Software vs. Appliance: Appliances. Incite 4/20/2011: Family Parties. New White Paper: React Faster and Better: New Approaches for Advanced Incident Response. Weekend Reading: Security Benchmarking Series. Security Benchmarking, Going Beyond Metrics: Continuous Improvement. Security Benchmarking, Beyond Metrics: You Can’t Benchmark Everything. Favorite Outside Posts Adrian Lane: My favorite line in the CSA Guidance. Rich: The Science of Why We Don’t Believe Science. In security we need to constantly assess our own cognitive biases. This is a good article that can help you understand risk responses, even though it isn’t about risk. Yes, politics are mentioned, but if you can’t get past that you need to re-evaluate your biases. Mike Rothman: Be wary of the well-certified IT pro. “Certification only goes so far.” What Kevin Beaver said… Project Quant Posts DB Quant: Index. 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. NSO Quant: Manage Metrics–Process Change Request and Test/Approve. Research Reports and Presentations React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing

We have spent much of this series on why benchmarking is important. But we also need to point out some situations where benchmarking may not be appropriate. There are clearly situations where you can’t benchmark, particularly is on granular operational data, which I call Ninja Metrics. Dependency: Peer Group Data Most organizations have ‘nascent’ metrics programs, which may actually be too kind. But not all. Some have embraced detailed programs that gathers all sorts of data, mostly focused on operations. This represents the next step of a metrics program, and can be represented by some of the ideas put forth through our Quant research projects. We have created highly granular process maps (with associated metrics) for Patch Management, Network Security Operations, and Database Security. Each report specifies 50+ distinct metrics you can measure for that discipline. Yes, they are comprehensive. But there is a clear issue regarding benchmarking at this level. You will have a hard time finding similarly granular data from other companies for comparison. So the key dependency in implementing a benchmarking effort is the availability of peer group data for comparison. Compare to Yourself What do world class athletes do when they reach the top of the heap? You know, folks like Michael Phelps, who has basically shattered every record there is to shatter. They start comparing themselves to their past performance. Improvement is measured internally rather than externally. Even if no one else has ever done better, you know you can. And this is what you will likely need to do the most granular operational functions. When you take a step back this makes a lot of sense. The reality is that you aren’t necessarily trying to ‘win’ relative to operational excellence. You want to improve. That said, it is important to have an idea of where you stand in comparison to everybody else, at least on the high-level operational metrics. But for the most granular metrics, not so much. We hope that over time enough companies will start tracking granular operational metrics, and become comfortable enough with benchmarking, to share their data. But that’s not going to happen tomorrow or even the day after. In the meantime you can (and should) continue to push your metrics program forward – just understand your comparisons may need to be internal. As we wrap up the Benchmarking series, we’ll look at how to get some Quick Wins and see the process in action. Share:

I love it when people froth at the mouth once they finally realize the blazingly obvious! For today’s example let’s look at the big Dropbox data privacy controversy. There are a few serious problems with Dropbox, such as not requiring a password after a host is added, making it super easy for someone to pretend to be you (if they get your host ID) and access your data. That’s not great, but there are far worse things out there I worry about. But the big controversy is that… ghasp… Dropbox employees could access your data! But if you know anything about security you know that if you get a nice, pretty web interface; then somewhere, somehow, the odds are an admin at the service provider can access your data. There are techniques around this using creative programming, but one look at the Dropbox code in your browser makes it clear they aren’t using anything like that. This is because the Dropbox web servers need to see your data to show you the web interface. Ergo, the servers can decrypt your data. Ergo, someone at Dropbox can see it. Now this doesn’t need to be true – they could have restricted the web UI to metadata and still encrypted file contents, then used a browser plugin (or maybe even JavaScript) to decrypt the files. But both options entail usability and security tradeoffs. A great example of how to manage issues like these is the CrashPlan backup service. CrashPlan offers a cascade of security options, each with usability tradeoffs, and all available to users. (All these options protect your symmetric encryption key, not the data itself): Protect with your account password. CrashPlan can access and see your data if needed. Protect with a separate data password stored locally. CrashPlan admins can’t access your data (even to restore it). You need to keep and secure an extra password. Set your own encryption key. Can be on a per-machine basis. Very secure, requiring more management. There is, of course, much more to their encryption scheme – this is just the user-controllable portion. Dropbox could do something similar: Standard (perhaps the only option on their free plan): Basic account username/password as they have now. Enhanced Security: Set a personal password, with metadata in the clear. You can manipulate your files, but they can only be downloaded by the local agent (not via a browser) and you need to remember the password (no password restore capability). You can still share public files, which are stored in a separate directory using your account password as on the old system. High Security: Metadata and file data encrypted using your personal passphrase, separate from your account passphrase. Web UI can only manage public files – everything else is accessible only through their client. These would require serious development effort, and I don’t want to gloss over the complexity or importance of implementing this type of security correctly and safely. This stuff is hard. But it would be manageable if they made it a priority. But seriously, people – if you want something free/cheap with a pretty web interface to manage your data, odds are you are trading off security. I use Dropbox extensively and just encrypt the things I consider too private to expose. Share:

Oracle announced the April 2011 CPU this week, with just a few moderate security issues for the database. Most DBAs monitor Oracle’s Critical Patch Updates (CPU) and are already familiar with the Common Vulnerability Scoring System (CVSS). For those of you who are not, it’s a method of calculating the relative risk of software and hardware vulnerabilities, resulting in a score that describes the potential severity of the vulnerability if an attacker were to exploit the problem. The scores are provided to help IT and operations teams decide what to patch and when. Vendors are cagey about providing vulnerability information – under the belief that any information helps attackers create exploits – so CVSS is a compromise to help customers without overly helping adversaries. Oracle uses CVSS scoring to categorize vulnerabilities, and publishes the scores with the quarterly release of their CPUs. When Oracle database vulnerabilities are found, they provide the raw data fed into the scoring system to generate the score included with the patch announcement. Most of the DBA community is not happy with the CVSS system, as it provides too little information to make informed decisions. The scoring methodology of assembling ‘base metrics’ with time and environmental variables is regarded as fuzzy logic, intended to obfuscate the truth more than to help DBAs understand risk. The general consensus is that risk scores have low value, but anything with a high score warrants further investigation. Google and 3rd party researchers become catalysts for patching decisions. Still, it’s better than nothing, and most DBAs are simply too busy to make much fuss about it, so there is little more that quiet grumbling in the community. Things seem a bit different with the April 2011 CPU. One of the bugs (CVE-2010-0903) was very similar in nature and exploit method to the last Oracle patch release (CVE-2011-0806), but had a dramatically lower risk score. The modification to the CVSS security score was based on Oracle’s modification to the CVSS scoring system to include a ‘Partial+’ impact metric. I have not spoken to anyone at Oracle about this, so maybe they have a threat model that demonstrates an attacker cannot get out of the compromised database, but I doubt it. It looks like an attempt to “game the system” by producing lower risk scores. Why do I say that? Because a ‘Partial’ reference makes sense if the scope of a vulnerability is localized to a very small part of the database. If it’s the entire database – which is what ‘Partial+’ indicates – pwnage is complete. Lowering of CVSS scores by saying the compromise is ‘Partial+’, instead of ‘Complete’ deliberately(?) misunderstands the way attackers work. Once they get a foot in the door they will automatically start looking for what to attack next. To reduce the risk score you would need to understand what else would be exposed by exploiting this vulnerability. Most people in IT – if they do a threat analysis at all – do it from the perspective of before the exploit. Few fully consider the scope of potential damage if the database were compromised and used against you. I can’t see how ‘Partial+’ makes things better or provides more accurate reporting, but it’s certainly possible the Oracle team has some rationale for the change I have not thought of. To me, though Partial+ means a database is an attacker platform for launching new attacks. And if you have been following any of the breach reports lately, you know most involve a chain of vulnerabilities and weaknesses strung together. Does this change make sense to you? Share:

I want to discuss deployment tradeoffs in Database Activity Monitoring, focusing on advantages and disadvantages of hardware appliances. It might seem minor, but the delivery model makes a big first impression on customers. It’s the first difference they notice when comparing DAM products, and it’s impressive – those racks of blinking whirring 1U & 2U machines, neatly racked, do stick with you. They cluster in groups in your data center, with lots of cool lights, logos, and deafening fans. Sometimes called “pizza boxes” by the older IT crowd, these are basic commodity computers with 1-2 processors, memory, redundant power supplies, and a disk drive or two. Inexpensive and fast, appliances are more than half the world’s DAM deployments. When choosing between solutions, first impressions make a huge difference to buying decisions, and this positive impression is a big reasons appliances have been a strong favorite for years. Everything is self-contained and much of the monitoring complexity can be hidden from view. Basic operation and data storage are self-contained. System sizing – choosing the right processor(s), memory, and disk are the vendor’s concern, so the customer doesn’t have to worry about it or take responsibility (even if they do have to provide all the actual data…). Further cementing the positive impression, the initial deployment is easier for an average customer, with much less work to get up and running. And what’s not to like? There are several compelling advantages to appliances, namely: Fast and Inexpensive: The appliance is dedicated to monitoring. You don’t need to share resources across multiple applications (or worry another application will impact monitoring), and the platform can be tailored to its task. Hardware is chosen to fit the requirements of the vendor’s code; and configuration can be tuned to well-known processor, memory, and disk demands. Stripped-down Linux kernels are commonly used to avoid unneeded OS features. Commodity hardware can be chosen by the vendor, based purely on cost/performance considerations. When given equal resources, appliances performed slightly better than software simply because they have been optimized by the vendor and are unburdened by irrelevant features. Deployment: The beauty of appliances is that they are simple to deploy. This is the most obvious advantage, even though it is mostly relevant in the short term. Slide it into the rack, connect the cables, power it up, and you get immediate functionality. Most of the sizing and capacity planning is done for you. Much of the basic configuration is in place already, and network monitoring and discovery are available without little to no effort. The box has been tested; and in some cases the vendor pre-configures policies, reports, and network settings before to shipping the hardware. You get to skip a lot of work on each installation. Granted, you only get the basics, and every installation requires customization, but this makes a powerful first impression during competitive analysis. Avoid Platform Bias: “We use HP-UX for all our servers,” or “We’re an IBM shop,” or “We standardized on SQL Server databases.” All the hardware and software is bundled within the appliance and largely invisible to the customer, which helps avoid religious wars configuration and avoids most compatibility concerns. This makes IT’s job easier and avoids concerns about hardware/OS policies. DAM provides a straightforward business function, and can be evaluated simply on how well it performs that function. Data Security: The appliance is secured prior to deployment. User and administrative accounts need to be set up, but the network interfaces, web interfaces, and data repositories are all set up by the vendor. There are fewer moving parts and areas to configure, making appliances more secure than their software counterparts when they are delivered, and simplifying security management. Non-relational Storage: To handle high database transaction rates, non-relational storage within the appliance is common. Raw SQL queries from the database are stored in flat files, one query per line. Not only can records be stored faster in simple files, but the appliance itself avoids have the burden of running a relational database. The tradeoff here is very fast storage at the expense of slower analysis and reporting. A typical appliance-based DAM installation consists of two flavors of appliances. The first and most common is small ‘node’ machines deployed regionally – or within particular segments of a corporate network – and focused on collecting events from ‘local’ databases. The second flavor of appliance is administration ‘servers’; these are much larger and centrally located, and provide event storage and command and control interfaces for the nodes. This two-tier hierarchy separates event collection from administrative tasks such as policy management, data management, and reporting. Event processing – analysis of events to detect policy violations – occurs either at the node or server level, depending on the vendor. Each node sends (at least) all notable events to its upstream server for storage, reporting, and analysis. In some configurations all analysis and alerting is performed at the ‘server’ layer. But, of course, appliances are not perfect. Appliance market share is being eroded by software and software-based “virtual appliances”. Appliances have been the preferred deployment model for DAM for the better part of the last decade, but may not be for much longer. There are several key reasons for this shift: Data Storage: Commodity hardware means data is stored on single or redundant SATA disks. Some compliance efforts require storing events for a year or more, but most appliances only support up 90 days of event storage – and in practice this is often more like 30-45 days. Most nodes rely heavily on central servers for mid-to-long-term storage of events for reports and forensic analysis. Depending on how large the infrastructure is, these server appliances can run out of capacity and performance, requiring multiple servers per deployment. Some server nodes use SAN for event storage, while others are simply incapable of storing 6-12 months of data. Many vendors suggest compatible SIEM or log management systems to handle data storage (and perhaps analysis of ‘old’ data). Virtualization: You can’t deploy a physical appliance in a virtual network. There’s no TAP or SPAN

The last two nights, we have celebrated Passover. Basically, we have a big dinner commemorating the escape of our forefathers from bondage and slavery in Egypt. At least that’s how the story goes, although I wasn’t there, so I maintain a healthy skepticism regarding burning bushes, parting seas, and plagues. But the point remains whether or not the stories are true. It’s really an excuse to party with friends and family, and enjoy some time together outside the craziness of day-to-day existence. I’m not unique in having a pretty hectic existence. For instance, the twins play baseball/softball, which means we were at the field both Saturday and Sunday, for a total of 5 games. Combined with the oldest one preparing for a dance show in a few weeks, we hardly had time to hit the head all weekend. But a close friend had a birthday party to celebrate her 40th Friday, so we had to take a break and celebrate. I did not squander the opportunity, and got rather festive with the help of some vanilla rum. OK, it might have been a lot of vanilla rum. If you find my liver, feel free to mail it back to Securosis Central. Adrian the mailman likes that kind of care package. Many of us don’t intentionally party enough. So I actually appreciate the religious holidays interspersed throughout the year. For me it’s not about the dogma, or whether what we are celebrating actually happened or not. And most of the time we don’t spontaneously start throwing food at each other. It’s about turning off the distractions and focusing on family and friends, if only for a night or two. We actually talk, as opposed to planning the next day’s activities. We eat (too much) and until you’ve experienced it, you can’t appreciate a Manischewitz Concord Grape hangover. A lot of our personal history is tied to these holiday celebrations, providing stories we tell for a lifetime. Like when – despite Mom’s stern warning not to get dirty – I fell into a stream behind my babysitter’s house, fancy corduroy pants and all. It was great fun but Mom was not amused. I think she’s still fuming. And it didn’t even involve Concord Grape. We can even make the wacky traditions fun. For instance, on Passover the kids hunt for a piece of Matzoh hidden in the house (it’s called the Afikomen), and if they find it they get a couple bucks. Which is huge progress, because I was lucky to get a piece of chocolate from my grandfather back in the day. Given this year’s bounty ($2 for each kid), and my oldest daughter’s big spending plans, she was very concerned that I wouldn’t make good on my financial obligations. I’m afraid I didn’t help the situation when I mentioned my new policy of charging $2 per month for rent. Imagine that – I can be difficult sometimes. Obviously I made good on the gift, but not before I had her unknowingly play back one of my favorite movie scenes. I asked her to say “I want my $2” about 10 times, and she didn’t understand why I was rolling on the floor. Too bad it was a school night, or I would’ve made her get on her bike and chase me around the neighborhood screaming “I want my $2.” Really, that’s not bad parenting, is it? Some folks figure they are Better Off Dead than suffering through yet another family holiday. But not me – I can make almost any occasion a big party. And I do. -Mike Photo credits: “La Tomatina / Spain, Bunol” originally uploaded by flydime I would be negligent if I didn’t call attention to a major milestone that one of us hits today. That’s right, the baby of the bunch, the rich mogul turns 40. Today. I’d say that’s old, but I still have 2+ years on him, and a lot more gray hair. Rich is taking a vacation day (as he should) and my hope is that he’ll take a step back to appreciates all he has and has done over the past 4 decades. He has a great wife and kids, he’s building a great business, and he’s one of the top dogs in this little game we play. So when you have your nightcap, after a typically hard day in the trenches of security, raise your glass to Rich and know that the next 40 will be better than the last. Incite 4 U Understand the real threat: Given all the (justified) bluster around the Verizon Data Breach Report, we can’t forget the need to understand what’s really at risk and how it is most likely to be compromised. Ax0n does a great job of reminding us by talking about the real insider threat, reminiscing about the hoops he’s had to jump through in order to remotely manage a server (legitimately, apparently). Then he contrasts that against the fact that other folks take the company’s most sensitive data outside on laptops and USB keys, posing a much more serious risk than a conscientious admin trying to fix things from home. Especially when the internal controls make life hard for people who don’t care about security. His point is that we need to match the controls (and security rhetoric) to the threat, and make sure it’s not onerous to drive creative folks to find a way around security. Remember, most folks believe security is not their job – it’s yours. You can make the case that it’s everyone’s job and you wouldn’t be wrong. But sales guys have to meet their quota each quarter, and that’s more important than meeting your rules. – MR DBIR poop commences: It took about a nanosecond, but as Rich predicted, the Verizon Data Breach Investigations Report is already being misquoted and misinterpreted. More breaches being investigated does not necessarily mean there were more breaches, but that’s the poop already hitting the wire. I understand the rush to get an article live, but they should at least read some of the report before editorializing. The general public

Today Verizon released the 2011 Data Breach Investigations Report: our single best source of actual incident data in the security industry, based on comprehensive metrics gathered during hundreds of incident investigations. In the coming weeks there won’t be any shortage of stories on, and analysis of, the DBIR. Rather than rehashing all the talking points we expect other sources to cover well, we will instead focus on actionable guidance based on the report. We will focus on how to read the DBIR, what it teaches us, and how should it change what you do. How to read the DBIR With so much data it’s all too easy to get lost in the numbers. It’s also very easy to lose context and misinterpret what’s in there. First let’s cover the four most important trends: The industrialization of attacks: There is an industry encompassing many actors, from coders to attackers to money launderers. They use automated tools and manage themselves and their operations as businesses – including use of independent contractors. Like any other business, these folks want to maximize profits and minimize risk, and the results of the 2011 DBIR show their work towards these goals – especially compared with the 2009 and 2010 DBIRs. Financial attacks focused on leveraged activities such as credit card skimming, point of sale attacks, and ACH fraud: This ties in with the first point: instead of spending massive resources for high risk/high gain (Gonzalez-style attacks), attackers are hammering the financial system’s weak points with significant automation to broaden scope and expand their scale. All forms of attack are up by all threat actors: If someone writes (or tweets) that APT is a myth or IP loss isn’t a problem based on this report, kick them in the nuts. Hard. Twice. Law enforcement really does catch some of the bad guys: 1,200 arrests over the past several years by the Secret Service alone. Many of these bad guys/gals attack small business. We could use more, given the scale of the problem, but law enforcement is having an impact. I will add my own interpretation, which I have separated from the direct DBIR trends: Successful financial attacks (more often than not) target smaller organizations, whereas complex IP (intellectual property) attacks focus (more often than not) on larger or specialized organizations. So for the first time we see a type of market segmentation by attackers. Using automated systems against weak targets and riding the associated economies of scale can be very lucrative, and it’s not surprising to see these targets multiply. But that doesn’t mean bigger companies, more sophisticated about security, are in the clear. We also see an increase in sophisticated attacks focusing on IP, although these numbers are not as obvious in the DBIR data. And now highlights and where to focus your reading, in no particular order: There was a large increase in the number of incidents investigated in 2010. Even accounting for sampling bias, this is still significant. 141 breaches were evaluated in 2009, and 761 in 2010. Yes, sports fans, that’s a 5x multiple. Such a massive increase skews the trend data, so you need to understand that percentage increases and decreases may obscure important information. For example, there was a significant decline in the percentage of attacks involving SQL injection, yet the actual quantity of reported SQL injection attacks actually increased dramatically. There are more small and medium businesses in the world than large ones. So we should see more attacks against them, and the data skews in that direction this year. As stated clearly in the report and in our briefing, the increased number of incidents is mostly due to massive growth in two attack forms: compromise of remote management tools for point of sale (POS) systems in hospitality and retail, and ATM and credit card skimmers (including employees using handheld skimmers). This data came from the Secret Service and we don’t know if it is means the bad guys have found a new focus, or the Secret Service is paying more attention to these attacks. Either way, the increase is significant. Anecdotal evidence from other sources does seem to indicate attackers are increasingly focused on these areas, especially against smaller companies and outlets. Most of the headlines will focus on the massive drop in lost records from 361 million in 2008, to 144 million in 2009, to 4 million in 2010. You should mostly ignore this. The large numbers were highly likely due to a small number of incidents involving massive quantities of records. As the DBIR itself states, Albert Gonzales alone was responsible for tens (possibly hundreds) of millions of records lost over this time period. Pull out those few distorting large campaigns, and the general trend in lost records evens out. The trend shows more bad guys hitting smaller targets. Your risk of being attacked successfully is greater if you are in a targeted industry, such as hospitality and retail. Each incidence of lost intellectual property was typically counted as a single lost record. So IP theft is inherently ranked much lower in studies like the DBIR than credit card breaches, which always involve more records per incident. But the F-14’s avionics schematics probably command a slightly higher value than a single credit card… The VERIS framework used to collect the data uses a multiple-select system. So if 5 attack methods were used in an single attack, each method is counted. They try to make this clear in the report and don’t misinterpret these findings like most of the armchair analysts (including vendors pushing their own agendas) probably will. For example, SQL injection dropped considerably as an overall percentage of attacks… but if you normalize the data to factor in the large number of skimmers and remote management breaches, injection probably climbs back to the top 3. Figure 6 on page 15 is the most important in the entire report. It shows that most attacks involve hacking and malware against user devices. Network sniffing is barely a blip. Physical attacks are also a major vector (mostly skimming, according to our briefing and the report), but

In a world full of TLAs (three letter acronyms), none resonates for security people as strongly as FUD. Or Fear, Uncertainty, and Doubt for you n00bs. Many of us rail at the offensive use of FUD in security sales. But let’s take a step back and acknowledge that security is like insurance. With very rare exceptions, security doesn’t help anyone sell more stuff. It doesn’t really help companies operate more efficiently. It’s basically about controlling downside risk. So it’s like insurance. You don’t buy health insurance because you want to. It doesn’t add anything to your life. It prevents you from going belly up if you have some catastrophic issue. It can maybe cut your medical bills if you are chronically ill or injury prone. But clearly you buy insurance because you feel you need to, not because you want to. Insurance brokers (at least all those I’ve dealt with) also leverage FUD in their sales cycle. They paint the picture of downside risk, which always involves preying on some fear of getting hurt, sick, etc. If I had a crystal ball and knew I (or anyone in my family) wouldn’t get sick, I’d drop health insurance like a hot potato. And your senior management is in exactly the same boat. If they thought there was no risk of losing protected data or intellectual property, you’d be out on your ass. So there will always be some level of FUD in our activities as security folks. I talked about using FUD as an end user a few years back, as well as more recently. So there can be legitimate uses of FUD to create urgency and provide a catalyst for funding. But let’s stay focused on security vendors using FUD to get you to buy their stuff. I realize it’s part of the game and I have accepted that. I don’t like it, but I accept it. But that doesn’t mean all FUD is created equal. So let’s attempt to break FUD down into a couple categories and (with your help) understand the impact of each type of FUD on the sales cycle. In this post, I’ll break down the categories of FUD we see most frequently. I started this discussion last week on Twitter, and got some great feedback. Hopefully we’ll get some more feedback on the blog (You! Yes, you! Get over to the blog and add some comments!) and come to some consensus about which kinds of FUD are common in practice. Then we’ll put together a survey to see if we can get some level of understanding about what is acceptable FUD vs. unacceptable. Dare I say it – maybe even useful FUD. In a perfect world, all our friends in the vendor community would take this feedback to heart and stop slinging bad FUD. Oy, such optimism. So here goes (in no particular order): Attack du jour press release: You know what I’m talking about here because these press releases show up in your inbox just about every day. This is the “you can stop StuxNet with our box” type release, where the vendor is trying to capitalize on some external event to get you to answer the phone. Similar to getting a call for travel insurance just after an airliner goes down. Threat reports: Almost every vendor has some kind of research capability now, so these reports basically list out which attacks and/or vulnerabilities they are seeing. Maybe they throw in some trend analysis as well. The idea is to keep your attention on common attacks, which are then addressed by the vendor’s widget or service. Breach reports: These reports are different from threat reports in that the objective is to actually study breaches – in an attempt to pinpoint both the breach’s impact and root causes. With this analysis a vendor/service provider hopes to educate potential customers on what causes breaches and how to address the risks (hopefully with their own products/services). Of course, the Verizon Data Breach report is the granddaddy of this kind of analysis. Check out Rich’s analysis of the 2010 report. Vendor surveys/peer group FUD: If you are a CISO, you get probably a dozen calls/emails a week to fill out one survey or another. Do you do this? Have you suffered from that? The vendors and researchers (like Ponemon) then assemble the data to build a case about what the masses are doing, or more likely aren’t doing. James McGovern accurately called this peer group FUD because it tries to trigger action by pointing out that either buddies friends are (or aren’t) doing something specific, and therefore you should. This also applies to the Security Benchmarking research I’m doing right now. Making security/compliance easy: One of my personal favorites: you still see vendors market events and position products with promises that using their gear will make either security or compliance (or both!) easy. And if you aren’t using their gear, your life is unnecessarily hard. Sponsored lab tests: You tend to see this kind of FUD during the sales cycle, when a vendor tries to convince you they are great and the competitor is crap, because the vendor paid some guy in a lab to run a test to which demonstrated something attractive about the vendor’s product or service. Some publications also run lab tests which straddle the line. It’s rare for money to directly change hands, but there can be backroom ad-buying hijinx. Our legal budget is rather limited so I won’t name names – these folks tend to be rather litigious – but you know who I’m talking about. Competitor sniping: Don’t you love it when vendors come in, and spend more time talking about why their competitors suck than about why they are good and how they can help you? Yeah, I hate that too. That’s competitor sniping in all its seedy glory. Cost of breach/attack analysis: We also see folks (like Larry Ponemon) who have built great businesses doing more targeted surveys, trying to understand what these security/compliance/breach issues actually cost companies. Clearly the idea is to derive an objective number that you (the practitioner) can use internally to talk about how bad it would be if something unfortunate were to happen. Yes, this