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:
- Use the defender's one natural advantage: we own the playing field.
- 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))