Another word for stakeholders

This is probably more worthy of a tweet (funny how tweeting has cut down on my blogging) but Alex Payne writes about the challenges of securing twitter (a relevant topic given my Twitter usage lately)

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.

This post is depressing on a number of levels, mainly because it reminds me of the attitudes (and my own personal frustrations) from back in the early years of doing product security at Cisco.

I hear thing have actually have improved (however slowly) there, but obviously in the supercool world of 2.0 and social networking, they are still pre-2001.

Stakeholders, yeah I'll tell you another word for stakeholders: people that give a shit.

I remember a certain Director of Marketing in the Security & VPN BU. These guys have long since cashed out their options (and the product is killed off), so I don't feel any reservations about blogging about it. Yeah, he was a stakeholder all right, he told us (a small, understaffed, security testing team with no power or authority) that his remote access VPN product was a communication product so security didn't really apply. (Leaving out the far more interesting & cynical quote from a GSR Director of Marketing)

So I understand the frustration, but the idea (that even even if you are a developer, product manager, system administrator) that suddenly you put on your security security hat, stop the presses, fix everything is a quaint notion alongside that 20th century concept that your application, device, or TCP/IP enabled Kleenex box (a big shout out to the Hewitt appsec crew!) is behind a firewall (or not on the Internet) so therefore security isn't a big deal.

You are the stakeholder. And to paraphrase The Wire, "Is you up or is you not?"

Security is not about losing the big battles. It is about winning the small ones. The one's you can win. You do what you can and don't whine about it. If it is not your call, then it is not your problem. Worry about what is your call. That is all you can do.

Been there and done that, you are wasting a lot of time and energy. Trust me.
If you don't believe me, read Unfettered. Bless his heart, Joe is still preaching (nobody gets it, nothing is being done, etc.) the same way he did the first conference of his I attended on SCADA security back in 2003.

Either they get it or they don't and maybe if they don't appear to get it, it is because it really isn't that important in the grand scheme of things. Or maybe you aren't explaining it well enough. If it is really important it work itself out in the long run.