This is the intro to a series of blog posts about building an application security program. Some of this advice probably won’t work for you and your organization and that’s OK. Take the parts that do work and build out from there. Before I succeeded I failed many times. This series comprises the lessons I have so painfully learned.
This guide is meant for people that find themselves starting a program from scratch and were somehow unlucky enough to stumble across this blog. This series of blog posts will be broken up into these sections:
Getting Started on your AppSec Program (down below)
Secure SDLC
Metrics (hardest part and they will all be awful)
(ノಠ益ಠ)ノ彡┻━┻ (aka, redoing everything because it all sucks)
Asset Discovery
Compensating Controls and Remediation Prioritization
Building shit that makes security easier for Developers (Devs)
There are probably more sections I could add but these ones make sense to me. Additionally, there are probably better ways to do a lot of things that I mention in this series, but I like making my life harder.
How to Read this blog series I feel the best way to read this series of blogs is to imagine this as an episode of Scared Straight; I am the convict, you are the juvenile delinquent, and we are about to become best friends.
Why AppSec? If you don’t know what AppSec is or why it is important, there are probably better resources out there. Go check out OWASP or Google shit. This section is actually about why I care about AppSec. I care because it is fun, challenging, and occasionally rewarding (like when a vulnerability type clicks with a Dev). Also, AppSec is the best Sec, InfoSec people who say different are just wrong.
Getting Started on your AppSec Program Your application program will be changing a lot. Remember, just because it’s your baby doesn’t mean that it's not ugly. First thing you will want to do is to come up with a mission statement and some tenets that will hopefully be the guiding light on how you approach your AppSec activities. You will try many things along the way and will probably fuck up, but that’s cool. Learn from your mistakes and make changes to your program, keep adapting to make sure that creating secure software is easy as possible for your Devs. Another thing you should do is steal everything. Anything you encounter through talks or presentations that you think might be a fit for your program - steal it. If you have ethical problems with theft then simply consider it reallocation.
Figuring out what is important There are two things that you need to figure out: #1 What is important to you, and #2 What is important to the business? At first, these will probably be two different things. If you are uncommonly lucky there is one pipeline for applications, and you won’t be dealing with multiple legacy environments. Go for good enough security, not everything has to be perfect. You are just starting out so having a little is better than having none.
Tip #7: Build your personal brand In InfoSec, your personal brand is more important than actual InfoSec abilities and 'skillz'. So get on Twitter and start tweeting at every important InfoSec person you can. Go get those 10k followers!
Policies and Standards Note: I mostly write standards and guidelines. Your first policies and standards are probably going to suck and that is fine. Acceptance, it’s the first step. The initial policies won’t cover everything. In fact, they’ll probably be overly harsh and your Devs won’t be able to meet the requirements. They will, however, look really good on paper. I would suggest using OWASP’s Application Security Verification Standard. What I did was remove about half of the items and changed the language from ‘Verify’ to ‘You Must’. Only keep things that you find super important and those that can be verified through scanning and automation. You can add more as your AppSec team’s capabilities get built out.
Service-Level Agreements Be very generous with your SLAs at first. You can always modify them to pace with your Devs ability and speed at fixing the security bugs. I like to have generous SLAs because teams generally meet them a lot quicker, and you don’t want to get the Devs in any trouble by not meeting your standards. Keep in mind that a happy Dev is a helpful Dev and you want them to be helpful. One other thing to think about is that not all Dev teams in your organization may be “agile” (even some of the ones that think they are).
Research You will be researching all the new technologies that Devs want to use. After your research you will embark on an engaging write-up of best practices to send out to the Devs. Whether you lean towards mixed media such as cut-and-paste or are a modern Proust, you will need to accept that an artist is rarely appreciated in life. The Devs will likely not read your documentation no matter the meme count. Send it to them anyway.
Management This shit is hard and frustrating, so if you don’t have support from upper management, just go find a new job because there are tons of companies that actually want to do AppSec and will support you.
Resources you might need Here are some resources to get you started:
Google (before you ask, look for the answer first)
Learn this (I didn’t actually read this but the title is what you need to do)
About the Author
Ray is a Life Coach and Conspiracy Theorist. He does AppSec in his non-spare time for money. Twitter