Last week I came across two stories about PayChoice (a payroll processing company) and the United States National Security Agency (NSA) getting hacked and really didn’t think twice about them. Every organization is susceptible to online risk regardless of best-efforts employed, in-house expertise yada yada. A trip to Vancouver, British Columbia this past weekend however got me thinking deeper about those stories and the lessons we can all (security experts and non-security experts alike) can learn.
First, the lesson to be learned is NOT ’if security-expert organizations like the NSA and PayChoice can’t get security right, we’re all doomed.’ That’s not what we’re looking for here. As an aside, good ‘security’ requires many different moving parts working together, great ‘security’ even more. The question I am more interested in is why hasn’t security guidance, process and tools been better adopted by now? Why are vulnerabilities like SQL injection still possible even for the NSA and PayChoice, or any organization for that matter, especially with the wealth of guidance and tools available? Here’s my opinion on one reason why and it can be best illustrated by an anecdote from my Vancouver weekend. Here’s what happened …
“My Friend Would Like Soft Tofu, Not Fried, and No BBQ Pork …”
After going out Saturday night, my friends and I headed over to a tucked-away 24 hour Chinese food joint to get a late-night snack. There I was trying to order a customized dish for a non-Asian friend and was having no luck. I would try to order in Cantonese and our waitress would respond, “sorry I no speak (Cantonese)”. Then I tried in English, same result: “sorry, I no speak (English).” Our waitress spoke a different Asian language (not to mention my Cantonese is less than perfect) so beyond shaking and nodding our heads and simple hand gestures, we just could not communicate effectively with each other. A friend who could communicate with our waitress stepped in, our orders were taken and we got the food we wanted.
“Sorry, I No Speak (Security)”
If it hadn’t been for my other friend who could speak the language that the waitress taking our order understood, it would have been unrealistic to expect her to bring the food that we wanted, you know the soft tofu, not fried and no BBQ pork. I might have been lucky and got exactly what I wanted, but that would have been rare.
I think the same goes for security, especially in application security. If we’re asking developers to create more secure software, build more secure Web sites, but we’re not speaking in the language that they (developers) understand, it’s unlikely we’ll get what we want (i.e., more secure software).
When I think about security guidance training for instance, most training that I’ve seen is heavy on the attack information and light on the secure development information (i.e., the stuff that developers understand, and perhaps care about). And if I really think about, most of the time the presenter isn’t a developer themselves! The same goes for tools. With the exception of code scanners, most of the ‘secure development tools’ available are really watered-down attack tools that. Cross-site scripting and SQL injection scanners? Socket fuzzing tools? All great tools, but are these really the best tools to help developers? Are they really focused towards developers and better, will they really use them? To be honest, I do know of a handful of developers that actually do use the security guidance and tools available to them, but I suspect if we want to see wider more in-depth adoption we need a slight perspective shift.
–Kevin
2 Comments
Interesting post – something I’ve also observed is that if the security people aren’t also developers – and not just developers, but people who ship code – then they’re likely thinking about security in isolation. The developer is thinking schedule, perf, risk of regression, feature backlog, localization, making everything run on some number of platforms and/or browsers, AND security.
If the security person isn’t in tune with the full range of the effects of their suggestions – features cut, schedule slipped, etc – then the developer might just flip the bozo bit, and now the security person sounds like Charlie Brown’s teacher – BLAH, BLAH, BLAH…
As security people, we need to give advice that’s actionable, takes into account the full range of issues the developer faces, and helps them deal with the biggest problems first.
Hey David,
Great to hear from you, hope all is well. Indeed, the bigger the picture the security person has of things going outside of their box the better. I am also glad you pointed out the need to provide advice that’s actionable (it’s one thing to tell someone they have a problem, but it’s another to provide them with a solution). Thanks for taking the time to share your thoughts!
–Kevin