Security > 140 Conversation with Brian Chess Part 2

Continuing the conversation with Brian Chess, in yesterday's post  Brian discussed how teams can use standards and automation to address sets of problems through grinding that free them up to do more high value work.Here is part 2

GP: I really like your point about how companies should maximize their strengths. After all, why play a losers' game? I can easily beat Michael Jordan. I just need to not play him at basketball. Instead of trying to outgun attackers, companies should look to focus on their core strengths.

 A risk equation contains assets, threats and vulnerabilities. It’s highly likely for most companies that attackers will know current threats and vulnerabilities far better than the company, but the company _should_ know their assets better than the attacker, so why not play that game instead?

For companies that are getting started with static analysis, how should they prioritize assets when getting started with static analysis?

BC:  The whole Advanced Persistent Threat thing was a real eye-opener for me last year.  I'm about a decade into this computer security gig, and all this time I thought I was primarily concerned with smart and capable attackers who think they have something to gain by going after the systems I'm protecting.  Judging by the way APT was covered in the press, most of the computer security industry was still trying to protect against Code Red.

 

But now that we're all on the same page, I think it's pretty easy to see that the attacker has a few big advantages, namely:

• Time.  You have to ship the software eventually.  The attacker gets from then on to find just one problem with what you built.
• Security knowledge.  Because the defender has to move first and because the world will know more about security tomorrow than it does today, it's reasonable to assume that your attacker will know about more vulnerabilities and attacks than you do.
• Resources.  If Anonymous decides to draw a bead on you, then they can spend more CPU cycles and engineering hours on the attack than you spent creating a defense.

 

What to do?  You spelled out the first two moves:

1. Use the defender's one natural advantage: we own the playing field.
2. Since we can't do everything, there's no choice but to prioritize.

 

On the topic of prioritization, what if you were given one million dollars and told to defend your country's borders?  A million bucks is a lot of money, but it doesn't go very far when you're buying military hardware. Would you prioritize and decide to defend the Canadian border rather than the Mexican border?  They're both thousands of miles long, so maybe your prioritization exercise would suggest that you can only really be effective at protecting the Vermont border.  Pretty silly, huh?  The right thing to do with that million dollars is to spend it figuring out what a real defense would look like and then explaining the problems that stem from not getting the job done.

 

Applying the same idea to getting started with static analysis (or any other proactive security technique), the projects to get started with are the ones that will get you visibility into what's really going on in the organization's code, what's easy and what's difficult about working with the developers, and what you need to do to build the case for a full-fledged rollout.  Sometimes this means going after the flagship product because that's where new approaches have to prove their mettle. Sometimes it means working with the team your friend manages because they're the ones who will return your phone calls.  In any case, the right answer is NOT trying to risk-rank your apps and chew through them one at a time until the universe cools.

 ((Part 3 of the conversation is here))

Comments

[Atdre]

If you are looking at a brownfield app portfolio and it allows Web traffic from the Internet to an Directory service, Database, or other Web service via connection strings, whether in the code, a config, or even by client-side certificates. These are assets that can be documented. Once documented, follow the data flow further into your infrastructure until fully completed. Now you have an asset-model.

Using the asset-model, you can determine the list of software components that touch or are touched by this data flow. Too bad only one commercial static analysis tool can work on single components without a full build. Why is this?

OSINT combined with focused runtime analysis activities could demonstrate which platforms are included in the asset-model. For example, Apache headers along with forced browsing and information disclosures could tell you which versions of CakePHP and CodeIgniter are being used across this asset-model. In addition, it would also identify packages such as TinyMCE, WebCalendar, Drupal, Joomla, Mambo, MediaWiki, Serendipity, and the ever-so-troublesome Wordpress (note that these are just examples). Then you can start to build a threat-model around these assets. I suggest another look at the Microsoft Press book, Threat-Modeling, on how to prioritize issues using STRIDE. Chapter 7 discusses this from a security testing perspective and could probably use an update that includes secure code review and secure application development/deployment management.

I do like FTA/FMECA and evidence-based management, but I agree that risk-ranking apps and chewing through them is the wrong approach for everyone.

Questions for Brian:

Why do you suggest Standardization is good and Risk-Ranking is bad, but your products and services do not reflect this? Is this a new path that you are embarking on? Where are the Fortify products that help us accomplish these goals and to create new strategies like them?

Recently, I saw a webinar with Brian around a new product that you were working on. It seemed to cover configuration problems such as the ones I've described here, but the focus seemed to be on DMZs and public-facing Internet web apps. I forget the name of the product, in fact, I don't even think the product name was mentioned in the webinar. I'd love to hear more about it. Perhaps a case study is in order? Or you could talk about it here in a part 3?