Sadly, kids, the answer is no.

In fact, it’s worse than that. I think that the DAM integrators the world over will be dateless for decades because the product class is the meta-definition of geekiness.

Let’s look at the skills you need to be the DAM God:

• You have to know security better than the security people.
• You have to know databases as well as the SOX auditors. (feel free to chortle here, mkay?)
• You have to know networks as well as the NIDS guys.
• You have to know servers and OSs as well as the HIDS people.

Talk about a complex system and a fringe sport filled with fur-toothed geeks such as myself….

Anyway, I’ve been in training all week and I keep thinking “How do I staff a DAM integration project with some of the junior staff?”  Answer is, you don’t–you need some fairly senior people with a wide variety of experience to make DAM products work.

• Guerilla CISO Tip: Get Inside the Data Center
• The “Off The Record” Track
• A Niche to a Niche is Still Hard to Staff
• Database Activity Monitoring for the Government
• Combatting Tool Creep

Some things should absolutely sell themselves. In the Mojave desert, the guy to be is the one driving the ice cream truck because everybody is happy to see you.

When it comes to the Government there is one thing that is their lifeblood: they make and trade secrets. And since 2001, every building in DC has become its own semi-autonomous nation-state with X-ray machines and armed guards.

So why is it so hard to sell Data Leakage Prevention (DLP) and Database Activity Monitoring (DAM) solutions to them? I’ve talked to vendors in both solution spaces, and they’ve found that it’s a hard sell to get product in the door.

If anybody needs DAM and DLP, it’s the Gub’mint. I try not to play this game, but if you look at the PII incidents that meet the Washington Post front page threshold, you’ll see that all of them are preventable with either DAM or DLP or both.

Photo by Dru

My thoughts on what’s up:

• Government purchasing lags behind the private sector. Government CPIC works on a 2-year cycle. Keeping in mind that the average life expectancy for a CISO is 2 years, this doesn’t bode well. This is also why it’s so hard to get strategic projects (*cough* redundant data center *cough*) completed.
• If it’s not in the control catalog, it’s hard to justify buying it. It’s the double-edged sword of compliance. Unless I have all the controls in the catalog implemented, I can’t really justify anything not in the catalog, and once I have all of the catalog done, they yank my budget for somebody who doesn’t have the catalog implemented.
• It takes approximately 2 years to get a particular technology into the catalog of controls. If the catalog (SP 800-53) is revised every year, then if NIST thinks that my technology/concept is a good idea, then I still have to wait for the next revision.
• So if you introduce a new technology today, the earliest I could expect to have it implemented is in 4 years, 3 if you’re lucky.
• Selling to the government is long and slow (can we say “heavy on bizdev investment”) but has a big payoff: remember that the Overall IT budget is just shy of $80Bazillionz.

The winning strategies:

1. Partnering up with the larger integrators who can bundle your product with an existing outsourcing contract.
2. Matching up your product description with the catalog of controls. Make it easy for the Government to select your product.
3. Let NIST and Mitre evaluate your product. Seriously. If you’ve got game, flaunt it.
4. Invest in BizDev expecting 4 years before you get a return.

• An Open Letter to the Next President of the United States
• “Machines Don’t Cause Risk, People Do!”
• CSIS and Recommendations
• What the Government Looks for in a Product
• Oooh, DITSCAP to DIACAP is SOOO Hard

I spent the last couple of weeks working on a proposal. It was the best of times, it was the worst of times. Hell, I don’t even know if the thing will even get read this year.

Anyway, on to the rants, that’s why you’re all here anyway. =)

#1 Don’t sell methodology. As a customer receiving a proposal, what I think when I get your methodology is that you don’t know my pain points enough to know how you can help me, so you give me a generic, templated proposal. As a contractor making the proposal, when I see that our proposal doesn’t have any real content, I wonder if we know the customer enough to actually pitch and win a deal.

#2 Small proposals are better as long as they’re relevant and answer what the RFP calls for. Don’t be afraid to chop out boilerplate-esque sections of the proposal.

#3 The Government wants way too much stuff in a proposal. It makes life refreshing and tasty when you cycle yourself back out into the private sector.

#4 Rybolov’s simple proposal format, blatantly lifted from the military:

• Situation and Mission: what problem does the Client have? Demonstrate that you understand what they’re asking for.
• Execution: This is what we’re trying to make the solution.  More here is better as long as it avoids being “fluffy”.
• Service and Support: Assumptions, what we need to do the job.
• Command and Control: What our management plan is, who our people are, and what our qualifications are.

• What the Government Looks for in a Product
• Some Words on Steinnon
• How I Do the “FISMA Thang”
• HR 5983–DHS Now Responsible for Contractor Security
• A Funny Thing Happened Last Week on Capital Hill

I always love it when people review the past and find out new things.

But then they cheapen the experience by something like this:  “If the SCADA system would have been 800-53-compliant, then these two deaths wouldn’t have happened”.

Well, where I come from, SSG Smith has a saying:  “If ‘if’ was a ‘fifth’, we would all be drunk”.  Now this colorful phrase basically means in polite-people-speak that you can “what-if” a past situation to death, but it doesn’t really change what happened.

Credit card breach companies, I feel your pain because you deal with this every single time:  “If they would have been PCI-compliant, this wouldn’t have happened”.    =)

• Life in a Zero Defects World
• Preliminary Findings on Cybersecurity Review Now Out
• Thought-Terminating Cliches and Infosec
• Layers Upon Layers of Oversight
• Always Behind

After a couple of years, we’re getting acquainted again.  Let’s say that ever since I got back from the “Giant Kitty-Litter Box”, I’ve been killed on traveling.  That is changing now.

Last week, it was advanced hire orientation in Atlanta, next week is Guardium training in Massachusetts.  (Yay DAM, I wonder how many “DAM” jokes I can throw in one day)
Fun, fun, fun.

• Where Have I Been?
• Got Training?
• Business Leadership Training
• Life Behind “The Great Big NAT in the Sky”
• The Wee Bonny Has a Blog

Very nice article in Military Information Technology Magazine (Online edition in case you couldn’t figure it out) about the DITSCAP to DIACAP transition.

Just looking at the concepts behind DIACAP, they’re very sound.  In some places, the article whines a bit too much.  Me, I’m glad to see DITSCAP go the way of the flesh in favor of risk registers and sharing of risk information with “business partners”.

My favorite quote this week:

“The services face a number of other challenges in implementing DIACAP, not least of which is what Lundgren called ‘significant cultural issue’ in moving from the ‘paperwork drill’ characteristic of DITSCAP, to DIACAP, ‘where you’re expected to actually go out and do the testing.'”

How can that NOT be a good thing?

Some other good quotes in the article and my random thoughts:

“Training and education of personnel is another concern faced by DoD components, according to King. ‘They must make sure they have a cadre of information assurance professionals who are in full understanding of what DIACAP is and how it differs from DITSCAP,’ he said. ‘This includes the complete realm of IA professionals, including principle certification and accreditation personnel to program managers and IA managers. There is a significant training and education tail that need to be accomplished for DIACAP to be properly implemented.'”

Well, to be very honest, I think that this was a problem with DITSCAP, is a problem with NIST 800-37, and will continue to be a problem until I work myself out of a job because everybody in the government understands risk management.

“This is going to save money and time because it allows capabilities to be put out to the field without having to be certified and accredited three or four times.”

That’s a happy thing.  Wait until DoD figures out how to do common controls, then they’ll find out how to save scads of money.

Now want to know the secret to why DIACAP will succeed?  This is a bit of brilliance that needs to be pointed out.  DIACAP became the standard in late 2007 after the DoD watched the civilian agencies go through 5 years of FISMA implementation and were able to steal the best parts and ignore the bad parts.

Future state:  civilian agencies borrowing some of the DIACAP details, like scorecards and eMASS.

Future state:  merging of DIACAP, DCID 6/3, and SP 800-37.

Future state:  adoption of the “one standard to rule them all” by anybody who trades data with the Government.

• More on Georgia’s FISMA Reporting
• Ack! With the Mandates!
• Core Belief #2 — Risk Management Uber Alles
• Where For Art Thou, 60-Day Review
• Imagine that, System Integrators Doing Security Jointly with DoD