Management

The CIS Consensus Metrics and Project Quant

By Rich

Just before release, the Center for Internet Security sent us a preview copy of the CIS Consensus Metrics. I'm a longtime fan of the Center, and, once I heard they were starting on this project, was looking forward to the results.

Overall I think they did a solid job on a difficult problem. Is it perfect? Is it complete? No, but it's a heck of a good start. There are a couple things that stand out:

• They do a great job of interconnecting different metrics, and showing you how you can leverage a single collected data attribute across multiple higher-level metrics. For example, a single "technology" (product/version) is used in multiple places, for multiple metrics. It's clear they've designed this to support a high degree of automation across multiple workflows, supporting technologies, and operational teams.
• I like how they break out data attributes from security metrics. Attributes are the feeder data sets we use to create the security metrics. I've seen other systems that intermix the data with the metrics, creating confusion.
• Their selected metrics are a reasonable starting point for characterizing a security program. They don't cover everything, but that makes it more likely you can collect them in the first place. They make it clear this is a start, with more metrics coming down the road.
• The metrics are broken out by business function -- this version covering incident management, vulnerability management, patch management, application security, configuration management, and financial.
• The metric descriptions are clear and concise, and show the logic behind them. This makes it easy to build your own moving forward.

There are a few things that could also be improved:

• The data attributes are exhaustive. Without automated tool support, they will be very difficult to collect.
• The document suggests prioritization, but doesn't provide any guidance. A companion paper would be nice.

This isn't a mind-bending document, and we've seen many of these metrics before, but not usually organized together, freely available, well documented, or from a respected third party. I highly recommend you go get a copy.

Now on to the CIS Consensus Metrics and Project Quant...

I've had some people asking me if Quant is dead thanks to the CIS metrics. While there's the tiniest bit of overlap, the two projects have different goals, and are totally complementary. The CIS metrics are focused on providing an overview for an entire security program, while Quant is focused on building a detailed operational metrics model for patch management. In terms of value, this should provide:

1. Detailed costs associated with each step of a patch management process, and a model to predict costs associated with operational changes.
2. Measurements of operational efficiency at each step of patch management to identify bottlenecks/inefficiencies and improve the process.
3. Overall efficiency metrics for the entire patch management process.

CIS and Quant overlap for the last goal, but not for the first two. If anything, Quant will be able to feed the CIS metrics. The CIS metrics for patch management include:

• Patch Policy Compliance
• Patch Management Coverage
• Mean Time to Patch

I highly suspect all of these will appear in Quant, but we plan on digging into much greater depth to help the operational folks directly measure and optimize their processes.

–Rich

The Pragmatic Data (Information-Centric) Security Cycle

By Rich

Way back when I started Securosis, I came up with something called the Data Security Lifecycle, which I later renamed the Information-Centric Security Cycle. While I think it does a good job of capturing all the components of data security, it's also somewhat dense. That lifecycle was designed to be a comprehensive outline of protective controls and information management, but I've since realized that if you have a specific data security problem, it isn't the best place to start.

In a couple weeks I'll be speaking at the TechTarget Financial Information Security Decisions conference in New York, where I'm presenting Pragmatic Data Security. By "pragmatic" I mean something you can implement as soon as you get home. Where the lifecycle answers the question, "How can I secure all my data throughout its entire lifecycle?" pragmatic data security answers, "How can I protect this specific data at this point in time, in my existing environment?"

It starts with a slimmed down cycle:

1. Define what information you want to protect (specifically, not general data classification)
2. Discover where it's located (various tools/techniques, preferably automated, like DLP, rather than manual)
3. Secure the data where it's stored, and/or eliminate data where it shouldn't be (access controls, encryption)
4. Monitor data usage (various tools, including DLP, DAM, logs, SIEM)
5. Protect the data from exfiltration (DLP, USB control, email security, web gateways, etc.)

For example, if you want to protect credit card numbers you'd define them in step 1, use DLP content discovery in step 2 to locate where they are stored, remove it or lock the repositories down in step 3, use DAM and DLP to monitor where they're going in step 4, and use blocking technologies to keep them from leaving the organization in step 5.

All too often I'm seeing people get totally wrapped up in complex "boil the ocean" projects that never go anywhere, vs. defining and solving a specific problem. You don't need to start your entire data security program with some massive data classification program. Pick one defined type of data/information, and just go protect it. Find it, lock it down, watch how it's being used, and stop it from going where you don't want.

Yeah, parts are hard, but hard != impossible. If you keep your focus, any hard problem is just a series of smaller, defined steps.

–Rich

Announcing Project Quant: New Security Metrics Project (with Microsoft)

By Rich

We spend a lot of time talking about security metrics over here, and I've been pretty critical of both overly-broad initiatives that don't help people get their day to day jobs done, and "fluffy" models that try to put hard numbers on risks/threats and such. Well, it looks like it's time for me to put up or shut up.

I'm pleased to announce our latest metrics project, which we're currently calling Project Quant. (Yes we need a better name). We were approached by Jeff Jones at Microsoft to help build an independent model to measure the costs and effectiveness of patch management. This will be a hard metrics model, focused on measuring the operational processes associated with patch management. The goal is to provide IT organizations a tool they can use to measure how effective they are, and track that over time.

I'm excited about this project for two main reasons:

1. We get to focus on hard, practical metrics people can use to improve operations.
2. We are following a "radical" version of our Totally Transparent Research process to ensure objectivity.

We've set up a dedicated landing area for the project at http://securosis.com/projectquant where we will be posting all the materials. Here are the bits you might care about:

1. We are soliciting as much participation in the project as possible- including competing vendors, end users of all sizes, consultants, whoever.
2. The project has a deadline of late June, so this won't drag out indefinitely. The first version may not be perfect, but come the end of June there will be a first version.
3. We really need you to get involved. We'll be asking for survey participants, reviewers, and just plain 'ol grumpy commenters to keep us honest, and help produce a useful result.
4. The results will be released under a Creative Commons license in an open format.

We have the first two posts up at the landing site. The first, Introducing Project Quant, provides an overview of the project and the research process. The second, Project Quant: Goals delves into the project goals in more detail.

This is a pretty huge project, even though it's laser focused on one single operational area. Hopefully you like the idea, and are interested in participating.

–Rich

Security Inevitabilities

By Rich

Despite my intensive research into cryonics, I have to accept that someday I will die. Permanently. I don't know when, where, or how, but someday I will cease to exist. Heck, even if I do manage to freeze myself (did you know one of the biggest cryonincs companies is only 20 minutes from my house?), get resurrected into a cloned 20-year-old version of myself, and eventually upload my consciousness into a supercomputer (so I can play Skynet, since I don't really like most people) I have to accept that someday Mother Entropy will bitch slap me with the end of the universe.

There are many inevitabilities in life, and it's often far easier to recognize these end results than the exact path that leads us to them. Denial is often closely tied to the obscurity of these journeys; when you can't see how to get from point A to point B (or from Alice to Bob, for you security geeks), it's all too easy to pretend that Bob Can't Ever Happen. Thus we find ourselves debating the minutiae, since the result is too far off to comprehend.

(Note that I'd like credit for not going deep into an analogy about Bob and Alice inevitably making Charlie after a few too many mojitos).

Security includes no shortage of inevitabilities. Below are just a few that have been circling my brain lately, in no particular order. It's not a comprehensive list, just a few things that come to mind (and please add your own in the comments). I may not know when they'll happen, or how, but they will happen:

• Everyone will use some form of NAC on their networks.
• Despite PCI, we will move off credit card numbers to a more secure transaction system. It may not be chip and PIN, but it definitely won't be magnetic strips.
• Everyone will use some form of DLP, we'll call it CMP, and it will only include tools with real content analysis.
• Log management and SIEM will converge into single products. Completely.
• UTM will rule the day on the perimeter, and we won't buy separate boxes for every function anymore.
• Virtualization and information-centric security will totally fuck up network security, especially internally.
• Any critical SCADA network will be pulled off the Internet.
• Database encryption will be performed inside the database with native functionality, with keys managed externally.
• The WAF vs. secure development debate will end as everyone buys/implements both.
• We'll stop pretending web application and database security are different problems.
• We will encrypt all laptops. It will be built into the hardware.
• Signature AV will die. Mostly.
• Chris Hoff will break the cloud.

–Rich

A Very Revealing Statement by the PCI Council

By Rich

I was getting a little excited when I read this article over at NetworkWorld about how the PCI council will be releasing a prioritized roadmap for companies facing compliance. It's a great idea- instead of flogging companies with a massive list of security controls, it will prioritize those controls and list specific milestones.

Now before I get to the fun part, I want to quote myself from one of my posts on PCI:

Going back to CardSystems, a large majority of major breaches involve companies that were PCI compliant, including (probably) Hannaford. TJX is an open question. In many cases, the companies involved were certified but found to be non-compliant after the breach, which indicates a severe breakdown in the certification process.

Now on to the fun (emphasis added by moi):

Businesses that are compliant with PCI standards have never been breached, says Bob Russo, general manager of the PCI Security Standards Council, or at least he's never seen such a case. Victims may have attained compliance certification at some point, he says, but none has been in compliance at the time of a breach, he says.

What a load of shit. With the volume of breaches we've seen, this either means the standard and certification process are fundamentally broken, or companies have had their certifications retroactively revoked for political reasons after the fact. As I keep saying, PCI is really about protecting the card companies first, with as little cost to them as possible, and everyone else comes a distant second. It could be better, and the PCI Council has the power to make it so, but only if the process is fixed with more accountability of assessors, a revised assessment/audit process (not annual), a change to real end-to-end encryption, and a real R&D effort to fix the fundamental flaws in the system, instead of layering on patches that can never completely work.

You could also nominate me for the PCI Council Board of Advisors. I'm sure that would be all sorts of fun.

Seriously -- we can fix this thing, but only by fixing the core of the program, not by layering on more controls and requirements.

–Rich

The Business Justification for Data Security- Version 1.0

By Rich

We've been teasing you with previews, but rather than handing out more bits and pieces, we are excited to release the complete version of the Business Justification for Data Security.

This is version 1.0 of the report, and we expect it to continue to evolve as we get more public feedback. Based on some of that initial feedback, we'd like to emphasize something before you dig in. Keep in mind that this is a business justification tool, designed to help you align potential data security investments with business needs, and to document the justification to make a case with those holding the purse strings. It's not meant to be a complete risk assessment model, although it does share many traits with risk management tools.

We've also designed this to be both pragmatic and flexible- you shouldn't need to spend months with consultants to build your business justification. For some projects, you might complete it in an hour. For others, maybe a few days or weeks as you wrangle business unit heads together to force them to help value different types of information.

For those of you that don't want to read a 38 page paper we're going to continue to post the guts of the model as blog posts, and we also plan on blogging additional content, such as more examples and use cases.

We'd like to especially thank our exclusive sponsor, McAfee, who also set up a landing page here with some of their own additional whitepapers and content. As usual, we developed the content completely independently, and it's only thanks to our sponsors that we can release it for free (and still feed our families). This paper is also released in cooperation with the SANS Institute, will be available in the SANS Reading Room, and we will be delivering a SANS webcast on the topic on March 17th.

This was one of our toughest projects, and we're excited to finally get it out there. Please post your feedback in the comments, and we will be crediting reviewers that advance the model when we release the next version.

And once again, thanks to McAfee, SANS, and (as usual) Chris Pepper, our fearless editor.

–Rich

The Business Justification For Data Security: Data Valuation

By Rich

Man, nothing feels better than finishing off a few major projects. Yesterday we finalized the first draft of the Business Justification paper this series is based on, and I also squeezed out my presentation for IT Security World (in March) where I'm talking about major enterprise software security. Ah, the thrills and spills of SAP R/3 vs. Netweaver security!

In our first post we provided an overview of the model. Today we're going to dig into the first step- data valuation. For the record, we're skipping huge chunks of the paper in these posts to focus on the meat of the model- and our invitation for reviewers is still open (official release date should be within 2 weeks).

We know our data has value, but we can"t assign a definitive or fixed monetary value to it. We want to use the value to justify spending on security, but trying to tie it to purely quantitative models for investment justification is impossible. We can use educated guesses but they"re still guesses, and if we pretend they are solid metrics we"re likely to make bad risk decisions. Rather than focusing on difficult (or impossible) to measure quantitative value, let"s start our business justification framework with qualitative assessments. Keep in mind that just because we aren"t quantifying the value of the data doesn't mean we won"t use other quantifiable metrics later in the model. Just because you cannot completely quantify the value of data, that doesn't mean you should throw all metrics out the window.

To keep things practical, let"s select a data type and assign an arbitrary value to it. To keep things simple you might use a range of numbers from 1 to 3, or "Low", "Medium", and "High" to represent the value of the data. For our system we will use a range of 1-5 to give us more granularity, with 1 being a low value and 5 being a high value.

Another two metrics help account for business context in our valuation: frequency of use and audiences. The more often the data is used, the higher its value (generally). The audience may be a handful of people at the company, or may be partners & customers as well as internal staff. More use by more people often indicates higher value, as well as higher exposure to risk. These factors are important not only for understanding the value of information, but also the threats and risks associated with it -- and so our justification for expenditures. These two items will not be used as primary indicators of value, but will modify an "intrinsic" value we will discuss more thoroughly below. As before, we will assign each metric a number from 1 to 5 , and we suggest you at least loosely define the scope of those ranges. Finally, we will examine three audiences that use the data: employees, customers, and partners; and derive a 1-5 score.

The value of some data changes based on time or context, and for those cases we suggest you define and rate it differently for the different contexts. For example, product information before product release is more sensitive than the same information after release.

As an example, consider student records at a university. The value of these records is considered high, and so we would assign a value of five. While the value of this data is considered "High" as it affects students financially, the frequency of use may be moderate because these records are accessed and updated mostly during a predictable window -- at the beginning and end of each semester. The number of audiences for this data is two, as the records are used by various university staff (financial services and the registrar"s office), and the student (customer). Our tabular representation looks like this:

In our next post (later today) we'll give you more examples of how this works.

–Rich

The Business Justification For Data Security

By Rich

You've probably noticed that we've been a little quieter than usual here on the blog. After blasting out our series on Building a Web Application Security Program, we haven't been putting up much original content.

That's because we've been working on one of our tougher projects over the past 2 weeks. Adrian and I have both been involved with data security (information-centric) security since long before we met. I was the first analyst to cover it over at Gartner, and Adrian spent many years as VP of Development and CTO in data security startups. A while back we started talking about models for justifying data security investments. Many of our clients struggle with the business case for data security, even though they know the intrinsic value. All too often they are asked to use ROI or other inappropriate models.

A few months ago one of our vendor clients asked if we were planning on any research in this area. We initially thought they wanted yet-another ROI model, but once we explained our positions they asked to sign up and license the content. Thus, in the very near future, we will be releasing a report (also distributed by SANS) on The Business Justification for Data Security. (For the record, I like the term information-centric better, but we have to acknowledge the reality that "data security" is more commonly used).

Normally we prefer to develop our content live on the blog, as with the application security series, but this was complex enough that we felt we needed to form a first draft of the complete model, then release it for public review. Starting today, we're going to release the core content of the report for public review as a series of posts. Rather than making you read the exhaustive report, we're reformatting and condensing the content (the report itself will be available for free, as always, in the near future). Even after we release the PDF we're open to input and intend to continuously revise the content over time.

The Business Justification Model

Today I'm just going to outline the core concepts and structure of the model. Our principle position is that you can't fully quantify the value of information; it changes too often, and doesn't always correlate to a measurable monetary amount. Sure, it's theoretically possible, but practically speaking we assume the first person to fully and accurately quantify the value of information will win the nobel prize.

Our model is built on the foundation that you quantify what you can, qualify the rest, and use a structured approach to combine those results into an overall business justification. We purposely designed this as a business justification model, not a risk/loss model. Yes, we talk about risk, valuation, and loss, but only in the context of justifying security investments. That's very different from a full risk assessment/management model.

Our model follows four steps:

1. Data Valuation: In this step you quantify and qualify the value of the data, accounting for changing business context (when you can). It's also where you rank the importance of data, so you know if you are investing in protecting the right things in the right order.
2. Risk Estimation: We provide a model to combine qualitative and quantitative risk estimates. Again, since this is a business justification model, we show you how to do this in a pragmatic way designed to meet this goal, rather than bogging you down in near-impossible endless assessment cycles. We provide a starting list of data-security specific risk categories to focus on.
3. Potential Loss Assessment: While it may seem counter-intuitive, we break potential losses from our risk estimate since a single kind of loss may map to multiple risk categories. Again, you'll see we combine the quantitative and qualitative. As with the risk categories, we also provide you with a starting list.
4. Positive Benefits Evaluation: Many data security investments also contain positive benefits beyond just reducing risk/losses. Reduced TCO and lower audit costs are just two examples.

After walking through these steps we show how to match the potential security investment to these assessments and evaluate the potential benefits, which is the core of the business justification. A summarized result might look like:

- Investing in DLP content discovery (data at rest scanning) will reduce our PCI related audit costs by 15% by providing detailed, current reports of the location of all PCI data. This translates to $xx per annual audit. - Last year we lost 43 laptops, 27 of which contained sensitive information. Laptop full drive encryption for all mobile workers effectively eliminates this risk. Since Y tool also integrates with our systems management console and tells us exactly which systems are encrypted, this reduces our risk of an unencrypted laptop slipping through the gaps by 90%. - Our SOX auditor requires us to implement full monitoring of database administrators of financial applications within 2 fiscal quarters. We estimate this will cost us $X using native auditing, but the administrators will be able to modify the logs, and we will need Y man-hours per audit cycle to analyze logs and create the reports. Database Activity Monitoring costs %Y, which is more than native auditing, but by correlating the logs and providing the compliance reports it reduces the risk of a DBA modifying a log by Z%, and reduces our audit costs by 10%, which translates to a net potential gain of $ZZ. - Installation of DLP reduces the chance of protected data being placed on a USB drive by 60%, the chances of it being emailed outside the organization by 80%, and the chance an employee will upload it to their personal webmail account by 70%.

We'll be detailing more of the sections in the coming days, and releasing the full report early next month. But please let us know what you think of the overall structure. Also, if you want to take a look at a draft (and we know you) drop us a line...

We're really excited to get this out there. My favorite parts are where we debunk ROI and ALE.

–Rich

The “Good Enough/Woe Is Me” Dissociation Postulate

By Rich

I don't get it. I mean I really don't get it. I can't possibly imagine why it isn't so obvious to everyone else!! Don't you see what's happening!!! Soylent Green is QSAs!!!

One of the more frustrating aspects of our profession is the apparent lack of security prioritization by the rest of the world. We feel like we see things they don't, and in that context many of their decisions make absolutely no sense. Are we just that much smarter than everyone else? Are they blindfully ignorant? Alan sums up our problem in his post on security gimmicks:

Agree or disagree with the gimmicks. You have to ask yourself why. With all that we read and see about data breaches, with all of these compliance regulations and rules around, why can't people take security seriously enough? Here is one man's opinion. Security is a bad news generator of an industry. We focus on what happens when things go wrong. We focus on adding to the process. We don't focus on the positive and the profitable. There is enough bad news in the world for people to focus on right now. They don't want the bad news that security makes them confront. If we can figure out how to make security a way of bringing a message of good news, we wouldn't need to resort to gimmicks.

My position is a little more zen.

Back in physical security/paramedic/firefighter/mountain rescue days I learned we all go through a process of dissociation with mainstream society. When all you see is nasty sh*t and dying people all day, every day, it's hard to give a rat's ass about someone getting the cold shoulder at the water cooler. The military, police, nurses, and many other professions suffer the same problem. In that world, there are two ways to handle it- shut up and deal, or isolate yourself into your chosen community. It's no accident that so many cops are married to nurses.

It's pretty much the same deal for IT security, except we don't have to wash blood off our shoes quite as often.

We see the fragility and danger of our online economy and society. Stolen elections, rampant fraud, and pwned grandmothers. No website is safe, all PCs have trojans, and those damn Macs will all be compromised next week.

We need to collectively chill out. Before we blow an aneurysm.

As Marcus Ranum said (totally pissing me off because I didn't say it first):

Will the future be more secure? It'll be just as insecure as it possibly can, while still continuing to function. Just like it is today.

We need to do our best to communicate risks to the business and cost effectively keep those risks within tolerance. Then we clean up the mess if the business, after being well informed, decides to accept that risk.

If we don't take risks, we can't possibly grow. No matter what someone tells us, we sometimes need to touch the hot stove and learn for ourselves. It's human nature; don't expect it to change. Security is only good news when it's no news.

Don't worry. When things get bad enough, we'll get the call. If you've kept your documentation and communication up, you won't get shafted with the proverbial short end.

Don't end up like I did in college- working as a full time medic on top of being a student wasn't exactly conducive to my dating life. That uniform didn't work nearly as well as I expected. (However, a black belt a few years later was very... effective).

–Rich

Policies vs. Plans vs. Procedures vs. Standards

By Rich

I was catching up with Rob Newby's blog and this post on dealing with security policies vs. standards/processes caught my eye. Although policies form the foundation for our security programs (at least they should), I find that more often than not they are completely misused by many of my clients. While I've noticed definite improvement over the past few years, I still often walk into organizations and see big 3 inch binders full of their security policies.

Rob does a great job of breaking these out, but I'd like to take it a step further. I'm going to dig into some nitty-gritty details, but feel free to skip to the end where I tell you why none of this parsing of language matters much. Here's how I like to divide up the world of security gove ance documentation:

1. Policies are high-level strategic governance with executive sponsorship. Policies should be short and to the point, since those who sign off on them don't need to know the technical details. An example might be, "we shall monitor all database activity based on the sensitivity of the data and legal or contractual requirements". Keep in mind, that since policies should be signed off by senior management you want to keep them generic enough that you don't have to go back to the CEO/CIO/CFO/COO every time you want to change a firewall configuration or AV product.
2. The next layer down are the high-level tactical documentations- plans and standards. The security plan is how you intend on achieving the policy, but it's still not at the level of specific steps. Keeping with our policy above, the plan would specify the contractual requirements, basic data classification, which activity will be monitored, and so on. While plans define how security will do things, standards define how everyone else has to do things.
3. Below that are your specific implementation documentations- processes, guidelines, and procedures. Here's where you get into the bitty-gritty of actual implementation and step by step guides. A process is a repeatable series of steps to achieve an objective, while procedures are the specific things you do at each of those steps. Keeping with out example above, the process would define how monitoring occurs (e.g. third party DAM tool), and the procedure is which bits to flip within the tool.

Yeah, I think that's a whole lot of paper and a huge time sink myself. Here's a slightly more pragmatic, and somewhat repetitive, way of looking at things:

1. Policies are still high level strategic governance with executive sponsorship; that never changes. Short and sweet since it makes it easier to get them approved, and you want o have to change them as little as possible.
2. I don't really care what you call below that, but you should have a security plan for implementing your policies. Plans are managed at the CISO or security director level (whoever is in charge) and change more frequently. You don't want to have to go to the CEO to change your plans. At this layer you also have your standards- which, if you think about it, is the next layer of gove ance. CEOs sign off on policies, and CISOs sign off on standards.
3. Below that is where you detail how the heck you'll accomplish all this gove ance. You document processes, list our procedures, and issue guidelines and configuration standards. This stuff will change all the time, and shouldn't necessarily need the CISO to sign off on it unless it breaks with the layer above.

The simpler the better, but if you don't write this stuff down in an organized way you'll eventually pay the price. By breaking it down into these three main layers, you can more easily change both the minutiae and the big picture as you adapt to changing conditions.

–Rich

The Breach Reporting Dillema

By Rich

Over at Emergent Chaos, Adam raises the question of whether we are seeing more data breaches, or just more data breach reporting. His post is inspired by a release from the Identity Theft Resource Center stating that they've already matched the 2007 breach numbers this year.

Personally, I think it's a bit of both, and we're many years away from any accurate statistics for a few reasons:

1. Breaches are underreported. As shown in the TJX case, not every company performs a breach notification (TJX reported, other organizations did not). I know of a case where a payment processor was compromised, records lost for some financial services firms that ran through them, and only 1 of 3-4 of the companies involved performed their breach notification. Let's be clear, they absolutely knew they had a legal requirement to report and that their customer information was breached, and they didn't.
2. Breaches are underdetected. I picked on some of the other companies fleeced along with TJX that later failed to report, but it's reasonable that at least some of them never knew they were breached. I'd say less than 10% of companies with PII even have the means to detect a breach.
3. Breaches do not correlate with fraud. Something else we've discussed here before. In short, there isn't necessary any correlation between a "breach" notification and any actual fraud. Thus the value of breach notification statistics is limited. A lost backup tape may contain 10 million records, yet we don't have a singe case that I can find where a lost tape correlated with fraud. My gut is that hacking attacks result in more fraud, but even that is essentially impossible to prove with today's accounting.
4. There's no national standard for a breach, never mind an international standard. Every jurisdiction has their own definition. While many follow the California standard, many others do not.

Crime statistics are some of the most difficult to gather and normalize on the planet. Cybercrime statistics are even worse.

With all that said I need to go call Bank of America since we just got a breach notification letter from them, but it doesn't reveal which third party lost our information. This is our third letter in the past few years, and we haven't suffered any losses yet.

–Rich

Don’t Sell “Compliance” If It Isn’t A Checkbox

By Rich

Perusing my blogs this morning I caught a post by Anton on DLP and compliance. That's the blogging equivalent of chaining a nice fat bunny to a stake in the middle of coyote territory here in Phoenix (in other words, the park behind our house). I, as the rabid coyote of DLP-ness, am compelled to respond.

Anton starts by wondering why he doesn't see compliance more in DLP vendor literature:

Today I was thinking about DLP again :-) (yes, I know that "content monitoring and protection" - CMF - is a better description) Specifically, I was thinking about DLP and compliance. At first, it was truly amazing to me that DLP vendors "under-utilize" compliance in their messaging. In other words, they don't push the "C-word" as strongly as many other security companies. Compliance dog doesn't snarl at you from their front pages and it doesn't bite you in you ass when you read the whitepapers, etc. Sure, it is mentioned there, but, seemingly, as an after-thought.

Then, he nails the answer:

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)! You know, DLP is newer than most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn't mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!). Also, PCI DSS directly and explicitly says "get a firewall", "deploy log management", "get scanned", "install and update AV" - but where is DLP? Ain't there...

I've spent a heck of a lot of time working with DLP vendors and users, and this is a problem that affects technologies beyond just DLP. Early on, the DLP vendors all talked about how they'd make you SOX, HIPAA, or XXX compliant. Problem was, there isn't a regulation out there that requires DLP. The customer conversations went like this:

Vendor: PCI compliance is bad. Buy DLP. User: Okay, is that section 3.1 or 3.2 that requires DLP? Vendor: It's not in there yet, but... {sales guy monkey dance} User: Ah. I see. Can you come back after we finish remediating our audit deficiencies? Say in 2012? Q3?

The truth is that DLP can help significantly with compliance with a variety of regulations, but none of them require it. As a result, vendors have softened their message and the good ones adjust it to show this value. I don't know if I really influenced this, but it's something I've spent a lot of time working on with my vendor clients over the years.

Other markets face this same challenge, and if you look back they almost always start by hitting compliance for the apparently easy cash, and are then forced to adjust messaging unless they are explicitly required. Users also face the same problem:

User: We need to do X for compliance with Y. Money Guy/Boss: Okay, where is that on the audit report? User: It's not, but {monkey dance}. Money Guy/Boss: Ah. I see. Maybe we can discuss this during your annual review.

Be it a vendor or an end user, the compliance sell is either the easiest or hardest you'll ever face. If the regulation (or your auditor) explicitly requires something, there's an immediate business justification. While there's a lot more to compliance, if it isn't on that list you can't sell it with merely the C word.

Instead, evaluate the tool or process in the context of compliance and show the business benefits. Does it reduce compliance costs? Does it reduce your risk of an exposure? For example, DLP content discovery, by identifying where credit card data is stored, can reduce both audit costs and the risk of non-compliance. Database Activity Monitoring can reduce SOX audit costs and the cost of maintaining appropriate logging on financial databases. There are a ton of internal process changes that improve audit efficiency and reduce the burden of generating compliance reports last minute every year or quarter.

When something is on the checklist, sell it as compliance. When it's off that list, sell it as cost or risk reduction. If it doesn't hit those categories, buy a monkey to do the dance- it's cuter than you are and more likely to get the banana.

–Rich

A Most Concise, Accurate Description Of The Problem With GRC

By Rich

Good post to read over at the Burton Blog. A snippet:

Of course, the elements of G, R, C are not dead. Governing, managing risk, and responding to compliance obligations are ongoing and critical organizational tasks. The problem is conflating them into a single term. As Burton Group is inclined to say, GRC is a four-letter word that shouldn't be spoken among polite company. Each function is deserving of its own, complete, and separate word. There's no organization in which compliance activities, risk management, and executive governance are rolled into a single person, group, or tool. No sense creating an acronym that implies it.

My favorite part. One of those things I'm jealous I didn't put into writing first:

If everything is "GRC," then nothing is.

Amen.

–Rich

GRC, Average Deal Size, And The Dangers Of Venture Capital

By Rich

Hot on the heels of my GRC is Dead post, an associate sent me a private rant on a past experience where the investors drove his company down a similar rathole.

Here's the thing, kids; venture capitalists aren't there to help you build a long-term business. Their entire goal is to achieve specific returns in specific time periods by driving your company into an exit (IPO or sale). You become a slave to your investors, many of whom aren't as business savvy as you might think, and most of whom don't understand your particular market.

My friend is allowing me to post this since he can't. Keep in mind that some of the biggest "GRC" pushers out there are large companies without VCs (Oracle, SAP, IBM), which thus are running under different dynamics.

The Three Magic Words (or: Why GRC won't die until the companies do) I read Mogull's post on GRC yesterday, and I found myself nodding in agreement with all of it. The basic thrust of the article: "GRC is now code for "selling stuff to the C-level". It has little to do with real governance, risk, and compliance; and everything to do with selling under-performing products at inflated prices. When a vendor says "GRC" they are saying, "Here's our product to finally get us into the Board Room and the CEO's office". The problem is, there isn"t a market for GRC." This is exactly what GRC is about. But why? Why would our vendor community spend all of their time trying so hard to get into the Board Room and the CEO's office when there's an entire market out there of businesses to whom we could sell products? Statistics say that 99% of businesses in the USA have less than 1000 employees: that's a HUGE market for security software and services that are reasonably priced and deliver value. Why are there almost no vendors looking to that market? And why are many of the ones who do (e.g., UTM vendors) mocked and ridiculed? Three magical words: "Average Deal Size". I learned these magic words when I was a relative newbie in information security, working for a vulnerability management vendor whose aim it was to sell appliances into all parts of the enterprise. They believed that vulnerability management was the kind of tool that needed to be embedded into every subnet within the entire organization, and that a huge infrastructure would be built up to manage vulnerabilities. When looking at who they wanted to be when they grew up, the names that were mentioned were SAP and PeopleSoft. That the CEO should have vulnerability reports on his desk every week. And that the CEO should be reporting vulnerability metrics to the Board at the quarterly meeting. (No, I'm not exaggerating. This is what they believed.) Unfortunately, no customer seemed to care that much about vulnerabilities. Even in the FUD-laden heyday of worms and viruses (Slammer, Blaster and Nimda, Oh My!), nobody wanted to drop vulnerability management tools on every subnet and embed vulnerability management deep into their business process. It was added cost without incremental benefit. And no CEO really cared about seeing the reports. Most CISOs didn't even want to see the reports. At the same time, another company was eating our lunch by offering to scan from the outside, on the web. They were basically giving the service away, selling little scans at $5K for anybody who wanted them. And they were rolling in cash compared to us. So, being the go-getter that I was, I put together a plan to create a competitive business within our company. Even with ridiculously conservative estimates, we were going to double revenue within a year (because it's not hard to double an infinitesimally small number). And I took it to senior management, who summarily rejected it. I didn't understand, and I fought hard, but their answer was firm: "No way." I was confused and dejected. This seemed stupid - it didn't make any business sense. The VP of sales saw this and took me aside after the meeting. He explained it to me, and it was the first time I had heard the three magic words. He would open my eyes to one of the things that makes startups do things that appear absolutely idiotic. He explained that the reason they wouldn't compete with the other vendor was that it would lower our "average deal size". That they would rather have a single $100K deal than 100 $2K deals, even if it was only half of the revenue. It didn't make sense to me (it still doesn't), so I asked him why. "Because that's one of the big things that venture capitalists care about when they're valuing your company," he said. "And our board is made up of our venture capitalists." The lights went on at that moment. Fast forward to today. The push toward GRC isn't because it makes business sense for any of the vendors (i.e., will increase revenue or reduce costs), but entirely because the vendors in the space are worshipping the gods of VC-driven boards who are using average deal size as the metric. It's why you see companies that are making good progress in mid-market or the mid-range of the small enterprise suddenly declare that their target is the C-level of the "Global 2000" companies. The problem with this is that most 100-person companies are entirely ill-suited to live in that environment. Large enterprises demand (to use Moore's term) the "whole product". A full support staff, complementary products, training, and serious hand-holding resources that a 100-person, $10M company just doesn't have. And, having worked in startups for the majority of the last 10 years, I can say that it kills more than it benefits. The burdens of supporting large, enterprise customers are burdens that, for the most part, only large, enterprise vendors are built to support. It always surprises me when a successful company (e.g., a small consulting company) that is ideally suited to selling, marketing and positively pwning the mid-market and mid-level sales decides to turn up-market (and become a "GRC company") to compete against companies that are built for that environment (e.g., E&Y, Accenture, IBM Global Services, etc.). Rather than taking the market that they have built themselves up to succeed at, they enter a market that they're entirely ill-suited for, and go through multiple VPs of sales and marketing wondering why their pipeline is weak. But the three magic words are powerful. They blind men and women to smart business decisions (mostly because they are used at board meetings). And they create companies that are willing to give anything to end up at the top end of the market, even if they have to make up acronyms (GRC) and sacrifice all actual measures of business success to get there.

–Rich

Train Like You Fight

By Rich

Ah, Monday. And not just the usual Monday, but a Monday after a perfect 5-day trip with my wife to Sonoma. A Monday where, right after we get back, the hot water heater in our old house (that we now rent) dies. Sigh. I really don't like this whole "real world" thing.

On the plus side we set two records on our wine tour: fewest wineries visited, and most time spent at a single winery. On our second stop at a small, 300 case a year winery we ended up polishing off a few bottles with the owner (and sole operator) over nearly 5 hours, making our guide late for his dinner. It was a total blast, not pretentious at all (I'm still pretty blue collar), and the wine was excellent. It did blow our stomachs for the entire next day, but that was a cost worth paying.

One of the lasts posts before I left was about the philosophy of REACT FASTER and BETTER I partially stole from Mike Rothman. In a response, Cutaway brought up a second, no less important issue, as almost a side note. He refers back to his Marine days and the importance of keeping your head up, even when you're down in the trenches responding to something else or stuck in the routine daily grind. When teaching martial arts I refer to this as situational awareness, which is what I think the military and law enforcement also call it. Know what's going on around you, even if you're bored off your rocker with tedium.

But that's not what I want to talk about today. Early in the post, Cutaway says,

All of this got me thinking about how we react to situations as a whole. I started thinking about how through training and effort we can begin to overcome hardships. I started thinking about how diligent practice can instill good habits and create muscle memory in any individual. ... "Yes, yes," you are thinking to yourself right now. We have heard this all before. Practice makes perfect. Practice your incident response. Practice your backup procedures. Practice your disaster recovery. Practice makes perfect. Practice, Practice, Practice. Blah, blah, blah. Yes, I am tell you that. But what I want to emphasize is that you can train yourselves all day long and still make mistakes.

Yep, we're absolutely going to make mistakes, and how we respond to those mistakes is just as important, maybe more important, than minimizing them. The only way we can do this is if you "train like you fight". In training, you need to run practical scenarios that emulate, as closely as possible, the chaos of the real world.

How many of you can honestly say your incident response, disaster recovery, or business continuity tests come close to emulating the real world? It's why I despise over-reliance on tabletop tests that prove nothing. It's why I really like programs like the DefCon Capture the Flag that test real attack and defense response skills.

If you are in incident response or disaster recovery/BCP, make sure you make heavy use of scenarios and practical tests as part of your training. Make them as real as possible, and throw in the unexpected to train people on how to respond to the chaotic. Tedious, rote training builds the "muscle memory" for tasks, while scenarios build the "muscle memory" for the unknown.

–Rich