4 First Steps to Jumpstart Secure Web App Development

You’re ready to get serious about secure web app development. Great… but where do you start? Maybe you have a 5-person team, or maybe it’s 50 people. Maybe you’re all about DevOps, maybe not so much. Maybe you outsource, maybe you don’t. Maybe you have some security tools and skills already, maybe not.
Seems like every team’s process will be different and special, right?… Wrong.

There are four commonsense initial steps that every organization should take to jumpstart their web app security program.

This guidance comes from Jim Manico, one of the world’s top experts in web application security. Jim is the founder of Manicode Security, a cutting-edge application security training firm, and a top contributor to a number of Open Web Application Security Project (OWASP) projects, including the OWASP Application Security Verification Standard (ASVS), the OWASP Cheat Sheet Series and the OWASP Web Security Testing Guide. He was our guest on a recent episode of The Virtual CISO Podcast, hosted by Pivot Point Security’s CISO and Managing Partner, John Verry.

Step 1: Leverage OpenSAMM and BSIMM

“The first thing I would do is work with the main stakeholder and take a look at OpenSAMM and BSIMM,” says Jim. “OpenSAMM [the Software Assurance Maturity Model] is a high level view of all the different components that you should be delivering in an application security program.”
BSIMM (short for Building Security In Maturity Model) is basically a more detailed version of OpenSAMM, with a focus on researching and quantifying the value of different organizations’ security practices. These two open frameworks can be tailored to your specific risk scenario.
“So I would look at all these ideas and say, ‘Hey, stakeholder, here’s all the things you should be doing. Which of these are you doing?’ And we get a baseline of what they are and aren’t doing and start working on increasing those little by little,” Jim clarifies.

Step 2: Conduct a basic application penetration test

“If I was beginning a program, I’d want to get a real basic idea of what’s going on,” Jim continues. “So I actually may start with something like a pen test. Not primarily to identify the bugs—just to bring awareness to the leadership and stakeholders: ‘We have critical bugs in our software. Yes, we should go fix them.’ Prove that this is not a game, and it’s not a theoretical issue, but there are real issues in your software.”
John adds: “In the Internal Auditing Handbook, they actually refer to one of the good uses of a pen test as to ‘shock management to action’.”
So the idea here is to identify some critical vulnerabilities, get a feel for how big the problems are, and show management a “proof of concept” that significant security risk is associated with the app that needs to be mitigated. The hoped-for end result is their buy-in.

Step 3: Get a static analysis tool

With management now onboard, the next step Jim recommends is to implement a “mature static analysis tool.” For Ruby on Rails apps, Jim recommends brakeman, which is open source. “But for the most part, I got to go commercial for static analysis,” Jim explains. That’s the earliest tool I get into place.”
I really try to find a static analysis engine that is specific to my language and framework,” emphasizes Jim. “So I go through a bakeoff with different vendors… so I can find a static analysis engine that I can use on a day-to-day basis. … I might even put a few static analysis tools in place over time.” For example, you might need a tool that does binary analysis for cases (e.g., DLLs) where you don’t own the source code.
“That’s a really good use of time and resources for early stage AppSec, I dare say,” relates Jim.

Step 4: Educate the developers

Not surprisingly for someone whose belief in training is so strong that he founded a training company, Jim asserts, “I also want to get developers educated. I preferred live training. …  Having an effective educator teach developers about the basics of web or application security as narrow to their framework and language as possible is very useful to facilitate other conversations.”
But training without the supports mentioned above is less useful. As Jim describes, “So you have to train developers, but alongside of that should be an analysis and polishing of a lot of other processes. … When you don’t have process in place, you don’t have standards in place and you don’t have like an AppSec SDLC in place, and you bring a trainer in, that’s like the wild wild West. It now becomes like security is a grassroots effort that really doesn’t work.”If your team needs best-practice advice on how to get started on the right foot with web app security, this episode of The Virtual CISO Podcast is just what you’re looking for.
To listen to the complete episode with Jim Manico, and check out the ever-growing slate of episodes in The Virtual CISO Podcast series, click here.
If you don’t use Apple Podcasts, you can access all our episodes here.