Some of my friends (and maybe myself) will be teaching the NIST Framework for FISMA in May and June with Potomac Forum.   This really is an awesome program.  Some highlights:

• Attendance is limited to Government employees only so that you can talk openly with your peers.
• Be part of a cohort that trains together over the course of a month.
• The course is 5 Fridays so that you can learn something then take it back to work the next week.
• We have a Government speaker ever week, from the NIST FISMA guys to agency CISOs and CIOs.
• No pitching, no marketing, no product placement (OK, maybe we’ll go through DoJ’s CSAM but only as an example of what kinds of tools are out there) , no BS.

See you all there!

• Security Automation Developers Conference Slides
• C&A Seminar, October 15th and 16th
• Comments on SCAP 2008
• New SP 800-60 is Out, Categorize Yerselves Mo Better
• The “Off The Record” Track

In a surprise move, the Obama administration is expected to announce abandonment of NIST’s Framework for FISMA in lieu of adopting the Payment Card Industry Data Security Standard (PCI-DSS).

In information leaked to the Guerilla-CISO staff, an undisclosed source deep inside the 60-day cybersecurity review made the following observations:

• Since everybody is complaining that FISMA is failing, the time for change is now while the Government is still in transition chaos.
• The leading metrics support the fact that the Payment Card Industry standards do work.
• There exists a large, relatively inexpensive and certified workforce focused around PCI-DSS.  This is preferrable to the expensive, non-certified FISMA compliance workforce.
• Billions of credit card transactions occur every day.  How could Visa and MasterCard be wrong?
• WAFs and code review are all we need in a web-enabled Government 2.0 world.
• PCI flip-flops on data encryption and the use of DLP solutions, so do we.
• Since one compliance framework is as good as another, we might as well pool our resources.
• A significant amount of money is spent on FISMA compliance.  That would all be eliminated under a PCI compliance framework.
• Technologies such as Scanless PCI can reduce the audit burden on the agencies to a couple bottles of beer and a handshake.
• The House testimony on the effectiveness of PCI-DSS was convincing that it is a viable standard.

In the interests of due diligence in reporting, the Guerilla-CISO staff tried to contact NIST’s Computer Security Resource Center and gained the following unofficial opinion:

“Screw those Obama guys.  Where were they when we were trying to create Government 1.0 and the FISMA Framework?  They haven’t put in the all-nighters because some yahoo at an agency lost a USB drive full of classified documents–they don’t have the experience to make this call.  I bet the administration thinks that they can outsource all responsibility to the cloud and get some ‘security through abstraction’.  Talk about gratitude for you, I’m going to go work for the International Standards Organization.”

PCI Plug-and-Play photo by ryan_franklin_az.

• Inside the Obama Administration’s Cyber Security Agenda
• Opportunity Costs and the 20 Critical Security Controls
• Beware the Cyber-Katrina!
• Why We Need PCI-DSS to Survive
• Random Thoughts on “The FISMA Challenge” in eHealthcare

In the words of one of my twitter buddies… it will be a good thing when this conficker business is over so I don’t have to worry about saying obscene words in meetings anymore.

• IKANHAZFIZMA Does Awareness Training
• Hackers, Protesters, Iran, Twitter, and Lolcats
• LOLCATS, Eric Schmidt, and Privacy
• Noms and IKANHAZFIZMA
• IKANHAZFIZMA and Transparency

So I like reading about what people think about security and the Government.  I know, you’re all surprised, so cue shock and awe amongst my reader population.

Anyway, this week it’s Fortify and a well-placed article in NextGov.  You remember Fortify, they are the guys with the cool FUD movie about how code scanning is going to save the world.  And oh yeah, there was this gem from SC Magazine: “Fortify’s Rachwald agrees that FISMA isn’t going anywhere, especially with the support of the paper shufflers. ‘It’s been great for people who know how to fill out forms. Why would they want it to go away?'”  OK, so far my opinion has been partially tainted–somehow I think I’m supposed to take something here personal but I’m not sure exactly what.

Fortify has been trying to step up to the Government feed trough over the past year or so.  In a rare moment of being touch-feely intuitive, from their marketing I get the feeling that Fortify is a bunch of Silicon Valley technologists who think they know what’s best for DC–digital carpetbagging.  Nothing new, all y’alls been doing this for as long as I’ve been working with the Government.

Now don’t get me wrong, I think Fortify makes some good products.  I think that universal adoption of code scanning, while not as foolproof as advertised, is a good thing.  I also think that software vendors should use scanning tools as part of their testing and QA.

Fortified cité of Carcassonne photo by http2007.

Now for a couple basic points that I want to get across:

• Security is not a differentiator between competing products unless it’s the classified world. People buy IT products based on features, not security.
• The IT industry is a broken market because there is no incentive to sell secure code.
• In fact, software vendors are often rewarded market-wise because if you arrive first to market with the largest market penetration, you become the defacto standard.
• The vendors are abstracted from the problems faced by their customers thanks to the terms of most EULAs–they don’t really have to fix security problems since the software is sold with no guarantees.
• The Government is dependent upon the private sector to provide it with secure software.
• It is a conflict of interest for the vendors to accurately represent their flaws unless the Government is going to pay to have them fixed.
• It’s been proposed numerous the Government use its “huge” IT budget to require vendors to sell secure projects.
• How do you determine that a vendor is shipping a secure product?

Or more to the point, how do I as a software vendor reasonably demonstrate that I have provided a secure product to the government without a making the economics infeasible for smaller vendors, creating an industry of certifiers ala PCI-DSS and SOX, or dramatically lengthening my development/procurement schedules?  Think of the problems with common criteria, because that’s our previous attempt.

We run into this problem all the time in Government IT security, but it’s mostly at the system integrator level.  It’s highly problematic to make contract requirements that are objective, demonstrable, and testable yet still take into account threats and vulnerabilities that do not exist today.

I’ve spent the past month writing a security requirements document for integrated special-purpose devices sold to the Government.  Part of this exercise was the realization that I can require that the vendor perform vulnerability scanning, but it becomes extremely difficult to include an amount of common sense into requirements when it comes to deciding what to fix.  “That depends” keeps coming back to bite me in the buttocks time and time again.  At this point, I usually tell my boss how I hate security folks, self included, because of their indecisiveness.

The end result is that I can specify a process (Common Criteria for software/hardware, Certification and Accreditation for integration projects) and an outcome (certification, product acceptance, “go live” authorization), leave the decision-making authority with the Government, and put it in the hands of contracts officers and subject-matter experts who know how to manage security.  Problems with this technique:

• I can’t find enough contracts officers who are security experts.
• As a contractor, how do I account for the costs I’m going to incur since it’s apparently “at the whim of the Government”?
• I have to apply this “across the board” to all my suppliers due to procurement law.  This might not be possible right now for some kinds of outsourced development.
• We haven’t really solved the problem of defining what constitutes a secure product.
• We’ve just deferred the problem from a strategic solution to a tactical process depending on a handful of clueful people.

Honestly, though, I think that’s as good as we’re going to get.  Ours is not a perfect world.

And as for Fortify?  Guys, quit trying to insult the people who will ultimately recommend your product.  It’s bad mojo, especially in a town where the toes you step on today may be attached to the butt you kiss tomorrow.  =)

• Comments on SCAP 2008
• Ed Bellis’s Little SCAP Project
• Sir Bruce Mentions FDCC, World Goes Nuts
• When Standards Aren’t Good Enough
• No, FISMA Doesn’t Require That, Silly Product Pushers