Martin and I were all over the map this week, but still managed to keep things under 30 minutes. We talk about the Dave and Buster’s hack, data exposure in Chile, and browser virtualization, among other things. The show is up over at netsecpodcast.com.

If you didn’t catch the news today, Tenable is changing the Nessus license and enabling the real-time signature/plugin feed for the free version. Martin and I managed to snag Ron Gula for a short interview we posted over at NetSecPodcast.com.

Overall I think it’s a very positive license change and it shouldn’t hurt you unless you were using the free version for commercial purposes.

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.

Last night I had this recurring dream I seem to have a few times a year. It involves a plane crash, but not one that I’m on. The dream always changes, but in every case I’m out and about someplace, I look up and see a struggling plane, it crashes, and I rush over to help. The dream almost always end before I do anything, and since I’m no longer a field medic portions of it usually involve me figuring out how I can help. Must be my overblown, currently unused hero complex or something. Never doubt the bounds of my ego.

This has absolutely nothing to do with what I want to talk about today; I just think it’s weird.

I swear I posted on this before, but I can’t find it anywhere. During a dinner with one of the Database Activity Monitoring vendors (the best DAM name in the industry) I mentioned their market size was equal to, or slightly larger than, the pure-play DLP market (that’s where we toss out peripheral products that only use DLP as a feature). I assumed this was common knowledge, but their jaws dropped. We ran through some back of the envelope calculations, and placed DLP at about $70M in 2007, with DAM right in the same range. My estimates might be off by up to $20M, but that’s basically a rounding error when we’re talking total market revenues.

Here are a few caveats. My estimates don’t include a lot of peripheral vendors, and I slice down as best I can to estimate DLP vs. DAM specific sales. For example, Orchestria launched a new DLP product in 2007, but I only include a fraction of their revenue in the market rollup since most of the revenue is still coming from their compliance product. Same for Verdasys, Proofpoint, Imperva (also has web application firewalls), and other vendors either with multiple product lines, or where DLP or DAM is a feature of something else. I work with most of the major DLP and DAM vendors, and while some share their revenues under NDA, some don’t, and these are mostly private companies. I’m also certain a couple of them are lying to me.

So there you have it. DLP is heavily hyped, but DAM is essentially the same size without as much hype. I believe this is because DAM, in some cases, directly addresses a compliance requirement, while DLP isn’t usually required (although can often really help).

I have to admit, I don’t really understand greedy desperation. Or desperate greed. For example, although I enjoy having a decent income, I don’t obsess about the big score. Someday I’d like a moderate score for a little extra financial security, but I’m not about to compromise my lifestyle or values to get it. As a business I know who my customers are and I make every effort to provide them with as much value as possible.

That’s why I don’t grok this whole GRC obsession (Governance, Risk, and Compliance) among certain sectors in the vendor community. It reeks of unnecessary desperation like the happily married drunk at the bar seething at all the fun of the singles partying around him. He’s got it good, but that’s not enough.

One of the first things I covered over at Gartner was risk management, and I even started the internal risk research community. This was before SOX, and once that hit a few of us started adding in compliance coverage. Early on I started covering the predecessors to today’s GRC tools, and was even quoted in Fortune magazine saying there was almost no market for this stuff (some were predicting it would be billions). That, needless to say, pissed off a few vendors. Most of which are out of business or on life support.

Gunnar Peterson seems to feel the same. He sees GRC as letting your company become audit-driven, rather than business-driven. He is, needless to say, not betting his career on GRC.

Now I’m about to rant on GRC, but please don’t mistake this as criticism of governance, risk management, or compliance. All are important, and tightly related, but they are tools to achieve our business goals, not goals in and of themselves.

GRC however is a beast unto itself. 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. Let’s look at the potential buyers:

1. C-Level Executives (the CEO and CFO)
2. Auditors (internal)
3. Auditors (external)
4. Business unit managers (including the CSO/security).

Before going any further let’s just knock off external auditors, since they aren’t about to spend on anything except their own internal tools, which GRC doesn’t target.

Now let’s talk about what GRC tools do. There is no consistent definition, but current tools evolved from the SOX compliance reporting tools that appeared when Sarbanes-Oxley hit. These tools evolved from a few places, but primarily a mix of risk documentation and document management. They then sprinkled in controls libraries licensed from the Final Four accounting firms. I was never enamored by these tools, since they did little more than help you document processes. That’s fine if you charge reasonable prices, but many of these things were overinflated, detached from operational realities unless you dedicated staff to them, and often just repurposed products which failed at their primary goal. Most of the tools now are focused on providing executives with a “dashboard” of risk and compliance. They can document controls, sometimes take live feeds from other applications, “soft-test” controls (e.g., send an email to someone to confirm they are doing what the tool thinks) and generate reports. Much of what we call GRC should really be features of your ERP and accounting software.

In the security world, most of what we call GRC tools are dashboard and reporting tools that survey or plug into the rest of our security architecture. Conceptually, this is fine, except we see the tools drifting away from being functional for those with operational responsibilities, and focusing more on genercising content for the “business” audience and auditors. It’s an additional, very highly priced, reporting layer.

That’s why I think this category is not only dead, it was never born. There is no one in an enterprise that will use a GRC tool on a day to day basis. The executives want their reports at the end of the quarter, and probably don’t mind a dashboard to glance at, but they’ll never drill down into all the minutiae of controls that probably aren’t what’s really being used in the first place. It’s not what they’re paid for. Internal auditors might also use reports and status checks, but they can almost always get this information from other sources. A GRC tool provides almost no value at the business unit level, since it doesn’t help them get their day to day jobs done.

The pretty dashboards and reports might be worth a certain investment, but not the six-figure plus fees most of them run for. No one really needs a GRC tool, since the tools don’t really perform productive work.

We’re seeing an onslaught of security (and other) vendors jumping on GRC because they think it will get them access to the CEO/CFO and bigger deals. But the CEO and CFO don’t give a rat’s ass how we do security, the just need to know if they are secure enough. That’s what they hire the CSO for- and it’s the CSO’s job to provide the right reports. These vendors would be better served by making great products and building in good reporting and management features to make the jobs of the security team easier.

Focus on helping security teams do their jobs and getting the auditors off their backs, rather than selling to a new audience that doesn’t care. Stop trying to sell to an audience (the CEO) that doesn’t care about you, when you have plenty of prospects out there drooling over those rare, good, functional products. Plenty of products get a boost from compliance, but they aren’t dedicated to it.

Don’t believe me? Go look at what people are really buying. Go ask your own CEO if he wants the latest GRC tool and will pay for it. Ask him if he wants to talk to any more vendors. Ask the operational guys if it will help them get their jobs done.

GRC is a feature, not a product. It’s a reporting tool, not a new paradigm for doing business.

As for the “practice” of GRC? I wouldn’t bet my career on a buzzword created by a small group of vendors to sell more product and jump on the bandwagon of yet another buzzword (compliance).

Compliance is real. Risk management is real. Governance and security are real. GRC is an unrequited wet dream leaving a rash of vendor blueballs in its wake.

This Thursday I’ll be giving a webcast for Core Security on Integrating Web Applications into Your Vulnerability Management Program.

You can register for it over here at WhiteHatWorld.com, and here’s the description:

Along with end-user systems, web applications often present the “weakest link” to attackers targeting sensitive data. However, while many security professionals conduct endpoint vulnerability assessments, fewer adequately manage their web application vulnerabilities.

Please join Core Security and Rich Mogull, founder of Securosis and former Gartner analyst, for a discussion of how to proactively assess your web applications against data breach threats.

You’ll learn:

• Which web-based attacks are posing the greatest risks to organizations today.
• When and where to integrate web apps into your broader vulnerability assessments.
• Why static analysis can miss critical exposures – and how you can fill the gaps.

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.

For the next 5 days my wife and I are heading to Sonoma to celebrate our anniversary. I am, to say the least, one lucky #&^(*&^#* to have her.

’nuff said.

I was on a client reference today learning about someone’s DLP deployment, and it highlighted one of the biggest issues we often face when moving to an information-centric model. No, it’s not a failure of content analysis techniques, data classification, or over-hyped tools, it’s that we often don’t even know who owns what, who’s supposed to have access to what, or our own infrastructure.

I often start my data security/information-centric rants by mentioning you need to have good identity management in place, but I don’t normally spend a whole lot of time talking about the details.

The truth is, this comes up all the time when I’m talking with end users who are implementing this stuff. Oftenthey don’t have a good directory infrastructure, or one that reflects the org chart, and thus they can’t do everything they want with their DLP, DAM, or other tools. Sometimes they don’t even know where all their assets/servers are, or how to access them for scanning.

Thus the tip- if you have a good directory infrastructure that accurately reflects your organizational structure, you’ll be in much better shape for any of these projects. Many of these tools can directly integrate with AD/LDAP, allowing you to build role-based policies.

You can’t inform someone’s manager they’re sending customer lists home or running weird DB queries if you don’t know who they work for.

I’ve had a bit of a weird week. As I mentioned on Monday, I was driving to physical therapy (physio for my Australian and European friends) when there was an accident in front of me and I stopped to help out. Wednesday night I was coming home from PT and there was another accident right as I was going through the intersection.

This one was far more serious. As soon as I heard the smash and saw the impact out of the corner of my eye, I pulled into the median, hit my hazard lights, and called 9-1-1. One of the advantages of working in the field for so long is that you learn an economy of words to describe a complex situation in just a sentence or two of the crucial information. My first call was:

I’m on-scene of an injury accident at the corner of [x and y]. Two vehicles, with an unconscious unresponsive patient with a compromised airway. Patient is entrapped in the passenger side of the vehicle with access through the driver’s side door. I’m a former paramedic and need to go manage her airway

There was a bit more jargon, but not much. The patient was unrestrained in the car with the airbag deployed, which probably meant she hit her head on the passenger window or strut since it was a side impact. There were a bunch of other bystanders and one came out and identified himself as a flight nurse. Her head was slumped over, which caused her difficulty breathing. The nurse jumped in the back of the car, we tilted her head to a normal position and stabilized her neck (one of the few times you’re allowed to move the neck after an accident). Her breathing got better, and she slowly started waking up, but clearly had a head injury, which we reported to 9-1-1. The fire department showed up a few minutes later, we got out of the way, and she was being loaded into the chopper as I drove off.

That might be one of the only times I’ve stopped to help at an accident where my assistance may have mattered. Truth is, unless you’re on the ambulance or have advanced equipment with you, the most useful thing you can do is calm the patient and make sure there isn’t any more damage. The kinds of injuries you sustain in a major accident are rarely something even a highly trained bystander can help with. I didn’t even bother evaluating anything more than her breathing, since nothing else mattered. All you EMTs can skip that full survey if you’re helping as a bystander in an urban area.

In this case her head position was keeping her from breathing well, making the situation worse. Just moving it so she could breathe more normally might have oxygenated her noggin a bit more and helped her wake up.

Why the heck am I talking about this on a security geek blog?

Because it’s one of those times where there are direct lessons we can apply to our world, and often forget.

I’m a big fan of Rothman’s philosophy of REACT FASTER. The idea is that it’s more about how you respond to an incident than having the incident in the first place. Truth is in IT, as in life, bad stuff will happen no matter what you do. Systems will crash, hard drives will die, and hackers will break in. David Mortman is one of the other major proponents of this philosophy- incident response is just as important, if not more important, than incident prevention. That’s why I’m adding REACT BETTER.

Emergency services are just like programming- a series of algorithms in a structured program flow. It all comes down to the A B Cs- Airway, Breathing, Circulation- in meat-space. Patient have any airway? Nope? Then nothing else matters until you fix that. Breathing? Check. Circulation okay? Then move on to spinal immobilization. It’s a recognition that you can’t jump from A to C and expect success. It’s exactly what we did to help that girl in the car, rather than focusing on the blood or other distractions.

Don’t just react- have a response plan with specific steps you don’t jump over until they’re complete. Take the most critical thing first, fix it, move to the next, and so on until you’re done. Evaluation, prioritize, contain, fix, and clean. (You OODA fans should love this).

And always remember the loudest patient is rarely the most important. If they’re screaming their head off, their airway is fine. It’s the quiet ones you have to watch out for.