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

Very nice article at Federal Times about Office of Management and Budget mandates actually interferring with agencies’ ability to provide effective security.  Of course, I think it’s well-written because it says some of the same ideas that I’ve been saying for awhile now.   =) 

So the question is, does OMB “get it” when it comes to information security?  Well, yes and no, and as a rebuttal, should they?

Let’s look at what OMB does.  In fact, go check out their web site, it has a plethora of knowledge.  It has the following mission statement:

“OMB’s predominant mission is to assist the President in overseeing the preparation of the federal budget and to supervise its administration in Executive Branch agencies. In helping to formulate the President’s spending plans, OMB evaluates the effectiveness of agency programs, policies, and procedures, assesses competing funding demands among agencies, and sets funding priorities. OMB ensures that agency reports, rules, testimony, and proposed legislation are consistent with the President’s Budget and with Administration policies.

“In addition, OMB oversees and coordinates the Administration’s procurement, financial management, information, and regulatory policies. In each of these areas, OMB’s role is to help improve administrative management, to develop better performance measures and coordinating mechanisms, and to reduce any unnecessary burdens on the public.

OK, so they are responsible for management, budget, performance, policy, and acquisition.  Hmm, sounds like the business side of the Government.  Yes, they should be in charge of security, but from the perspective of a good CFO:  that is, they know that it’s important because it’s loss reduction, but they don’t necessarily have the expertise on-hand to go into much more depth than that.

Now OMB is in a squeeze, you need to understand their pressures.  On one hand, their job is to assure compliance with all the laws, directives, policies, etc.  On the other hand, their job is to reduce the cost of the Federal budget.  In my world, these ideas are opposed to each other.

Add some political pressure and some serious security incidents into the mix, and you can easily see why OMB has been managing security by mandates and performance metrics (FISMA reporting).  The mandates are policy statements and the metrics are intended to determine how efficiently agencies are executing their compliance.  Thing is, this makes sense in a compliance-budget squeeze.

Now notice I didn’t bring up risk management anywhere in this post until now?  Well, this is where risk management comes in.  At the current burn-rate for IT security spending in the Government, the way to realize efficiencies and cost savings while still meeting the compliance drivers is to use risk management.  I’ll say this again: without risk management, everything becomes equally important and you have neither effective security nor cost-conscious security.

My big question for you is this:  who is performing true risk management for the Government as a whole?

• It’s not OMB, they just operate as the Government’s CFO
• It’s definitely not GAO, they’re just a dual-person control to keep the executive branch honest
• It’s not NIST, they just write standards and guidelines

The answer is this:  agency CISOs.  The problem with them being the highest level of risk management is the following:

• No sharing of risk with high-level stakeholders (OMB, White House)
• No sharing of risk with risk partners (Congress)
• No risk management at the national-level (strategic view)
• CISOs are given all the responsibility but none of the authority to fix things that really matter
• We all point fingers at each other when something breaks

So, how do we fix this?  That’s a hard one.  We can train OMB to do risk management.  We can extend Lines of Business so that one agency (*cough* DHS *cough*) adopts national-level risk management.  We can create a new organization that’s responsible for government-wide risk management, but then again that doesn’t make sense.

• Lines of Business, Relationships, and Trustability
• Towards Actionable Metrics
• It’s a Problem of Scale!
• An Open Letter to the Next President of the United States
• More on Georgia’s FISMA Reporting

Accreditation is the forgotten and abused poor relation to certification.

Part of the magic that makes C&A happen is this:  you have certification which is a verification that all the minimum security controls are in place, and then you have accreditation which is a formal acceptance of risk by a senior manager/executive.  You know what?  The more I think about this idea, the more I come to see the beautiful simplicity in it as a design for IT security governance.  You really are looking at two totally complete concepts:  compliance and risk management.

So far, we’ve been phenomenal at doing the certification part.  That’s easy, it’s driven by a catalog of controls and checklists.  Hey, it’s compliance after all–so easy an accountantcaveman could do it. =)

The problem we’re having is in accreditation.   Bear with me here while I illustrate the process of how accreditation works in the real world.

After certification, a list of deficiencies is turned into a Plan of Action and Milestones–basically an IOU list of how much it will cost to fix the deficiency and when you can have it done by.

Then the completed C&A package is submitted to the Authorizing Official.  It consists of the following things:

• Security Plan
• Security Testing Results
• Plan of Actions and Milestones

The accreditor looks at the C&A package and gives the system one of the following:

• Denial to Operate
• Approval to Operate
• Interim Approval to Operate (ie, limited approval)

And that’s how life goes.

There’s a critical flaw here, one that you need to understand:  what we’re giving the Authorizing Official is, more often than not, the risks associated with compliance validation testing.  In other words, audit risks that might or might not directly translate into compromised systems or serious incidents.

More often than not, the accreditation decision is based on these criteria:

• Do I trust the system owner and ISSO?
• Has my assessment staff done an adequate job at finding all the risks I’m exposed to?
• What is the extent of my political exposure?
• How much do I need this system to be up and operational right now?
• Is there something I need fixed right now but the other parts I’m OK with?

For the most part, this is risk management, but from a different angle.  We’ve unintentionally derailed what we’re trying to do with accreditation.  It’s not about total risk, it’s about audit risk.  Instead of IT security risk management, it becomes career risk management.

And the key to fix this is to get good, valid, thorough risk assessments in parallel with compliance assessments.   That requires smart people.

Smart CISOs out there in Government understand this “flaw” in the process.  The successful ones come from technical security testing backgrounds and know how to get good, valid, comprehensive risk assessments out of their staff and contractors, and that, dear readers is the primary difference between agencies that succeed and those who do not.

NIST is coming partly to the rescue here.  They’re working on an Accreditor’s Handbook that is designed to teach Authorizing Officials how to evaluate what it is they’re being given.  That’s a start.

However, as an industry, we need more people who can do security and risk assessments.  This is very crucial to us as a whole because your assessment is only as good as the people you hire to do it.  If we don’t have a long-term plan to grow people into this role, we will continually fail, and it takes at least 3-5 years to grow somebody into the role with the skills to do a good assessment, coming from a system administrator background.  In other words, you need to have the recruiting machinery of a college basketball program in order to bring in the talent that you need to meet the demand.

And this is why I have a significant case of heartburn when it comes to Alan Paller.  What SANS teaches perfectly compliments the policy, standards, regulations, and complicance side of the field.  And the SANS approach–highly-tactical and very technologically-focused–is very much needed.  Let me say that again:  we need a SANS to train the huge volume of people in order to have valid, thorough risk assessments.

There is a huge opportunity to say “you guys take care of the policy and procedures side (*cough* the CISSP side), we can give you the technical knowledge (the G.*C side) to augment your staff’s capabilities.  But for some reason, Alan sees FISMA, NIST, and C&A as a competitor and tries to undermine them whenever he can.

Instead of working with, he works against.  All the smart people in DC know this.

• The Accreditation Decision and the Authorizing Official
• Security Assessments as Fraud, Waste, and Abuse
• Some Random Thoughts on C&A SOPs
• Rebuilding C&A
• Build a Security Program

OK, let’s kick it old-sk00l-FISMA-stylie.  Back in the day, there was Special Publication 800-26.  It was part of the first set of guidance to come from NIST on information security (for those of you who can’t count, as of today we’re up to 800-115).  I guess you could say that the original 800-26 was the primordial beginnings of a catalog of controls combined with a self-assessment questionaire.

The cool thing about 800-26 that I liked was the fact that it’s a thinly-disguised version of CMMI:  5 levels of maturity, with level one being “do you have a policy that addresses this” and the plateau level being “have you integrated this control by feeding the results of testing back into all the other levels?”  Hey, sounds like fairly competent engineering and technical management practices (no, I’m not open to debate the merits and warts of CMMI today, tyvm) and is something familiar enough that we can instinctively get the idea of what we’re doing with it.

Now for the bad things:  some of the questions in 800-26 were um… I guess the phrase would be “irrelevant” or “deprecated due to time” or even “worn around the edges”.  The original 800-26 was good for a stop-gap measure, now it’s fallen into the class of “Cute, reminds me of the halcyon days of 2003 when we were so naive in our desire to rid the world of enencrypted telnet sessions”.

Our friends at NIST are going through a revision of 800-26 and have “pulled SP 800-26 off the market” for the time being.  Sometime in the future it will be a questionaire based on SP 800-53, the catalog of controls we all know and love.  The idea being that if you have a low-impact/criticality system, you can do a self-assessment using the new and improved 800-26 and it satisfies quite a few of your security controls requirements.  And hey, we all know that assessment of any IT system begins with self-assessment as some sort of gap assessment:  where are you now, where do you need to be, and how do you bridge the gap between these 2 points.

Of course, the concept of relying on self-assessment for security makes me cringe deep down inside, but keep in mind that this is only for low-criticality systems which means that they do not include PII, financial data, or classified information.  However, if you’re a FISMA-hater, you can always point to 800-26 and say “see, they think that by filling out a questionnaire, they’re making their IT more secure”.

Only here’s the problem:  I still see people on teh Intarweb still referring people to go “Read the Fine Manual” that is 800-26.  I know of at least one agency that requires a completed self-assessment to be submitted as part of their C&A package, and usually as a simple checkbox:  Have you filled one out or not?

The CISO deep down inside of me still wants to know what the value added is.  Sounds to me like we have the typical “Security Wonks Gone Wild” in that we’re so obsessed with filling out checklists and forms that we lost track of what our original intent was.

Now if you know me, you’ll remember that I usually don’t complain about something without having an alternative.  In this case, my alternative is this:  Don’t use 800-26 or recommend it to others and please do point out to people who require you to use 800-26 that its use has been rescinded by NIST and that your organization’s policy should have changed to keep up.

This is the official story from NIST, keep the link handy for the future:

• An Open Letter to NIST About SP 800-30
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• Assessment Cases for 800-53A Are Available
• It’s Not Just for the Feds Anymore
• How to Not Let FISMA Become a Paperwork Exercise

Ah yes, our favorite part of FISMA:  the ongoing reporting of metrics to OMB.  Last year’s guidance on what to report is in OMB Memo 07-19.  It’s worth the time to read, and you probably won’t follow with the rest of this blog post if you don’t at least skim it to find out what kind of items get reported.

 Still haven’t read it?  Fer chrissakes, just look at pages 24-28, it’s a fast read.

If you look through the data that OMB wants, there are 2 recurring themes:  What is the scope/extent/size of your IT systems, and how well are you doing what we told you to do to protect them?  In other words, how effectively are you, Mr CISO, executing at the operational level?

We’re missing one crucial bit of process here–what are we actually going to do with scoping metrics and operational performance metrics at the national, strategic level?  What we are collecting and reporting are primarily operational-level metrics that any good CISO should at least know or be able to guess at to do their job, but it’s not really the type of metrics that we need to be collecting at levels above the CISO unless our sole purpose is to watch over their shoulder.

As our metrics gurus will point out, the following are characteristics of good metrics:

• Easy to collect:  I think the metrics that OMB is asking for are fairly easy to collect now that people know what to expect.  Originally, they were not.
• Objective:  Um, I’ll intentionally side-step this one.  Suffice it to say that I’ve heard from several people a story where the punch line goes something like “Your security can’t be this good, we’ve already decided that you’re getting a “D”.
• Consistent:  Our consistency is inconsistent.  Look at how many times the FISMA grading scale has changed, and we still wonder why people think it’s not rooted in any kind of reality.  And yes, I’m advocating yet another change, so I’m probably more an accomplice than not.
• Relevant:  We do a fairly good job at this.  Scoping and performance metrics are fairly relevant.  I have some questions about if our metrics are relevant at the appropriate level, but I’ve already mentioned that.
• Actionable:  This is where I think we fall apart because we’re collecting metrics that we’re not really using for anything.  More on this later….

Now, as Dan Geer says in his outstanding metrics tutorial, the key to metrics is to start measuring anything you can (caveat, 6-MB PDF).  The line of though goes that if you can collect a preliminary set of data and do some analysis on it, it will tell you where you really need to be collecting metrics.

The techie version of this is that the first server install you do, you will blow it away in 6 months because you now know better how you operate and what you need the configuration really to be.

Now ain’t that special?  =)

So the question I pose is this:  after 6 years, have we reached the watershed point where we’ve outgrown our initial set of metrics and are ready to tailor our metrics based on what we now know?

I think the answer is yes, and applying our criteria for good metrics, what we need to answer is a good set of questions:

• What national-level programs can reduce the aggregate risk to the government?
• What additional support do the agencies need and how do we translate that into policy?
• As an executive branch, are we spending too much or too little on security?  Yes, I know what the analysts say, but their model is for companies, not the Government.
• What additional threats are there to government information and missions?  Yes, I’m talking about state-sponsored hacking and some of the other things specific to the government.  Is it cost-effective to blackhole IP ranges for some countries for some services?
• Is it more cost-effective to convert all the agencies to one single NSM/SIEM/$foo ala Einstein or is it better to do it on a per-agency basis?
• What is the cost of implementing FDCC, and is it more cost-effective and risk-effective to do it immediately or to wait until the next tech refresh on desktops as we migrate to Vista or upgrade Vista to the next major service pack?
• What is the cost-benefit-risk comparison for the Trusted Internet Connections initiative, and why did we come up with 50 as a number v/s 10 or 100?
• Is there a common theme in unmitigated vulnerabilities (long-term, recurring POA&Ms) across all the agencies that can be “fixed” with policy and funding at the national level?  Say, for example, the fact that many systems don’t have a decent backup site, so why not a federal-level DR “Hotel”?
• Many more that are above and beyond my ability to generate today…

In other words, I want to see metrics that produce action or at least steer us to where we need to be.  I’ve said it before, I’ll say it again:  metrics without actionability means that what we’ve ended up doing is performing information security management through public shame.  Yes, some of that is necessary to serve as a catalyst to generate public support which generates Congressional support which gets the laws on the books to initiate action, but do we still need it now that we have those pieces in place?

If I had my druthers, this is what I would like to see happen, maybe one day I’ll get somebody’s attention:

• OMB and GAO directly engage Mr Jacquith to help them build a national-level metrics program.
• We produce metrics that are actionable.
• We find a way to say what our problems are without overreacting.  I don’t know if this can happen because of cultural issues.
• We share the metrics and the corresponding results with the information security management world because we’ve just generated the largest-scale metrics program ever. 

And oh yeah, while I’m making wishes, I want a friggin’ pony for Christmas! =)

• Ack! With the Mandates!
• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• Managing Security in Large Organizations
• CSIS and Recommendations
• Been Off Teaching