Analyzing Fortify’s Plan to “Fix” the Government’s Security Problem

Posted April 1st, 2009 by

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.  =)

Similar Posts:

Posted in Outsourcing, Technical, What Doesn't Work, What Works | 2 Comments »

2 Responses

  1.  Top 3 NoVA Infosec Blog Posts of the Week | Says:

    […] #3 – Fortify to Save Security: Known as “the guys with the cool FUD movie about how code scanning is going to save the world,” according to rybolov, he had a lot to say about why Fortify is good, and why it needs improvement. Rybolov’s biggest problem with Fortify? “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.” And that’s just the beginning of the post. You can read the rest of Rybolov’s commentary about Fortify and what they are—and aren’t—doing to “fix” the government security problem on the The Guerilla CISO blog. […]

  2.  Andre Gironda Says:

    There is no ideal secure product. Every product is insecure, or will be very very soon.

    The idea is to avoid the risk of vulnerabilities in products that an organization can demonstrate are highest to that organization. The best way to do this is to choose the most complete and affordable control(s). Both the risks and the controls are always unique/custom to the organization due their own purposes – the data and security classifications they employ and the assets that they seek to protect.

    The only time you have to worry about what to buy product-wise is when you know that it can’t be integrated securely into your custom and unique environment. Usually this is a resource and capital planning problem, because anything can be made secure enough with enough money and people thrown at the problem. Oppositely, anything can be made to be insecure with enough money and people thrown at the problem.

    Fortify, Veracode, Ounce, Checkmarx, Parasoft, HP SPI Dynamics, IBM Rational Watchfire, Parasoft, Coverity, Klocwork, and GrammaTech are unique in that they can work at the CWE level instead of the CVE level. However, manual intervention/preemption of these tools is critical to proper analysis. Some would say it’s easier to verify all known CWEs without the above tools, simply because they add so much confusion to the process.

    The process for analysis of either CVE or CWE is fairly identical – match control(s) to risk(s). The CWE/SANS Top 25 is only half the battle… clearly there is more work to do here.

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

Visitor Geolocationing Widget: