I was chatting with Wendy Nather of the 451 Group the other day about a number of items related to appsec. The discussion was insightful on many levels, primarily because well, Wendy is wicked smaht (we’re located in Boston, Wendy is not...).
We touched on a number of issues relevant to secure coding and development standards. We discussed processes and standards, and the lack of both across the industry, often at large organizations. It certainly was fascinating to hear her perspective on how organizations probably should be thinking about standards at least for their own company, if not, taking a cue from reputable best practices.
One thing I have never asked any analyst is what can companies do who might not have any sort of mandate to implement an appsec program – like if they have no process, no requirement to do it, or no idea how to do it, how do they start?
Thought I would share the conversation…
Question:
With a lack of industry standards, what are the top 2-3 you see organizations doing to follow some type of application security model so that software they are using and delivering is secure? In other words, what are successful companies doing right?
Answer:
One of the most important things I see organizations doing is creating their own standards. These standards come from a risk assessment that sets their priorities and takes into account their environment, development processes, and resources. Another thing I see is engagement with the appsec community: getting familiar with OWASP and MITRE (CWE), but more than that, actually meeting with like-minded professionals and trading stories on what works and what doesn't. There isn't one comprehensive standard for application security, so organizations are taking what's there, adapting it, and checking their work with peers.
Question:
What can the immature appsec organization do immediately in order to start reducing application security risk in the absence of a formal process (like an SDLC) or even a formal mandate?
Answer:
When you don't have a formal mandate, you have to practice guerilla appsec, and that means starting at the grass roots level. It means choosing linchpins in your organization — the workers who have the most influence — and winning them over to the idea of improving security. Do any kind of scan on your applications and get a feel for the size of the problem you're facing. Pick a couple of achievable goals, such as stopping the most widespread type of security flaw, and figure out what additional steps you need to put in place to deal with them, both in old code and new. By the time you have that working, you have a baby SDLC.
Question:
Are development organizations better served/more effective if they are following an SDLC if it’s mandated by a compliance requirement, or if the security organization is pushing it to them? Why?
Answer:
Honestly, it depends on whether the organization is more afraid of the hacker, or more afraid of the auditor. But that kind of external motivation doesn't always take root among developers. They should be using an SDLC because it works for them. If it leads to fewer errors, fewer repetitions of process, and helps teams achieve their development goals faster; if it's actually a useful tool for them, then it will function better than if it's imposed on them from above in the name of some threat that the developers might not even believe in.
