The Thing About Security
Last week, Twitter, the thing I work on, had some security issues. Earlier in the week a phishing attack started going around. Then, someone used a dictionary attack to grab the account of one of our support staff, who has administrative privileges on the site. We cleaned up both of these issues just as fast as we could. The company communicated quickly and openly about what happened, and if anything, the press seemed to encourage more people to check Twitter out. It was a stressful week, but it forced some positive changes.
It stings a bit to have experts like Bruce Schneier call us out – and rightly so – for not shoring up holes like this sooner. Defending against a dictionary attack is basic stuff. Our fix for it was an afternoon’s work. But dictionary attacks just aren’t something that’s defended against by most web authentication stacks out of the box, which means the vulnerability lingers until a security review or a successful attack. In part, I think this is due to increasing specialization in computer security education, but that’s a topic for a longer post.
The thing about security is that it requires stakeholders. I have a security background, but Twitter’s security isn’t my job. In fact, my job is pretty much the opposite: I open up as much of Twitter’s functionality as I can without (hopefully) making the system insecure. So while I’ve usually been a “first responder” to security incidents because of my background, it requires a major mental context switch from the work I normally do.
Several months after I joined Twitter in early 2007, I suggested to the team that we do a full internal security audit. Stop all work, context switch to Bad Guy Mode, find issues, fix them. I wish I could say that we’ve done that audit in its entirety, but the demands of a growing product supported by a tiny team overshadowed its priority. Now we’re in an unwelcome position that many technical organizations get into: so far into a big code-base that’s never seen any substantial periodic audits that the only way to really find all the issues is to bring in some outside help – something I sincerely hope we end up doing, but is not my call.
Outside security review is about spending enough money that your organization becomes its own security stakeholder. Invest in a high-priced security consultancy’s time for a week and you’d damn well better do something with their findings, right? It’s still a reactive model for a product’s security life-cycle, rather than a proactive one, but it’s something. Ultimately, outside security audits are the price a company pays for not building security mindfulness and education into day-to-day development.
My advice: be a stakeholder in your organization or product’s security from day one. If you don’t have time to be that stakeholder, find one, either inside or outside of your company. Make sure that dollars are on the line, or it won’t get done. There are hundreds of security issues in any complex system that fall under the heading of “basic stuff”, and they won’t get fixed until that happens.
Though maintaining users’ privacy and trust is incentive enough, the cruel reality is that good security is fueled by more than just good intentions and best efforts.