Luck is the residue of design

When your blog gets picked up by Mike Rothman's Security Incite, it is the infosec equivalent of being on Larry King (I think Mike counts his marriages on one hand though). Mike responded to my Go Wide and Deep post with a cynically/jaded/realworld "Good Luck With That" title but a generally positive review:

Gunnar makes a good point here that getting the process started is hard and requires specialized knowledge. The money quote is: "...to deploy any of the current cutting edge stuff in software security at scale, requires technical depth and deployment width." That is a hard to find combination, that's for sure. GP then goes on to discuss what I'll call the Tiger team approach, which swoops in to address a specific issue and then moves to the next one. He finishes with another important point, which is "executive buy in." That is absolutely critical because any software security pro worth a damn will find stuff in applications, it's the organization's commitment to fixing it and then amending the process to ensure it doesn't happen again that makes the difference between success and failure.

Yes software security is a tough sell sometimes, yes wide AND deep is hard, but context and goals are critical - and they are especially critical to getting executive buy in. (What did I just sign Radar?)

Let's take an example from a non-financial Fortune 500 type company. (Many financial companies have been working towards medium assurance for some time). Let's assume you are in a healthcare, manufacturer, or insurance Fortune 500 company and your CISO (who in between golf outings...errr..."meetings"...reads Rothman book) has successfully established a beach head on the budget for a line item for static analysis. (Security person scratching head - I wonder where the developers sit in this building anyhow?)

Let's assume a set of hypotheticals

1. You have fewer than 10 people working on static analysis

2. You have more than 500 developers

3. You have more than 1,000 applications

4. You are using a static analysis tool like Fortify or Ounce

Here is the kicker

5. You can get some limited executive buy in to fix things (more on this in a minute)

6. You start to scan some apps and you find on average 7500 security issues per application

7. Of the 7500 findings 50 are confirmed serious issues

You are going to have to make some tradeoffs. You cannot fix or scan everything.

Here is the thing, Fortify and Ounce will find things. You find thousands of possible issues (known unknowns) on every app, every time you run the tool. You find dozens of serious known known issues, and yet you cannot with a small handful fix them all and scale out to scan the rest of the portfolio. What do you do? How do you balance scanning, remediation, and oh yeah developer time?

Remember the executives? Those people in suits who sign checks? They start to care about security, because your CISO in between trips to Vegas...errr..."meetings", read Jaquith's book, had all there staff read it, and actually now has some security metrics that communicate your infosec's program's message in a meaningful way. They care about software security because someone forwarded them a random blog entry that showed they need to align security and business spending.

Here is the thing though, they care, but only to a point. There are limits. Executives like getting their bonus checks as much as anyone, maybe more. The standard infosec routine of "there's a new sherriff in town" and I am gonna make these developers code with one finger at a time - just so I can watch what they're doing - is terrifying to anyoen who likes profits. They don't want to put the brakes on everything that looks likely to grow the top line. Having said that you *do* need to scan the apps. But you need the exec buy in to have any authority to remediate what you find. I like the silver bullet approach - the CISO gets a limited set of silver bullets per year, say three. This means, the CISO has the authority to stop any project that is egregiously out of bounds and can overrule there peers to do so.

This is a good start, but its not gonna help too much in static analysis because the CISO will likely want to use their silver bullets on other stuff too and there are so many apps. So, we have a small team and tons of apps to scan. Here is the plan:

1. The static analysis team scans a limited set of apps each month. Let's say 10 apps/month

2. The static analysis team uses the reporting from Fortify or Ounce to score the findings

3. The apps are compared against their peers (the other 9 apps) each month.

4. The CISO plays golf...errr..has a meeting ( a real one this time) with the other execs and gets the following silver bullet

4a. The CISO is authorized to require remediation of all serious vulnerabilities for the worst application scanned each month.

This is important because you are scoring the apps not against some ivory tower criteria, but comparing them against their peers who have to deliver under the same constraints. It further means you are remediating each month, and developing better skill in secure coding (those developers go off and work on other projects).

It is not an all or nothing approach, so often you see things not done because infosec looks at everything through a secure/insecure lens. Instead this approach forces infosec to have skin in the game - make prioritized decisions and tradeoffs just like everyone else in the company. So yeah, you need some authority, but I think you can get some executive buy in if you position the program in a pragmatic way - compare apps to their peers, fix the worst. Repeat.

Comments

[Bruce Barondes]

"Thanks for the good article. The author points to a number of factors that will help move company for the next phase of the company's development.
If you are interested in IT and risk metrics and KPI in business, check this web-site to learn more about Metrics

http://www.business-development-metrics.com"