Skip to main content
May 9, 2016

4 Quick and Painless Steps to Get an AppSec Program Going at Your Software Company

Your application security is a problem. So why are you just hearing about this now? Is Big Security suppressing this information? Or could it be that unless there's a huge breach that makes the staff come in on a weekend that anyone bothers to care? It's probably the second one. It's tough to give priority to something that seems to be not a problem the moment.

It's true that you don't have time for it. At least you don't have time for it right now but future you will certainly have more than enough time to deal with it later, right? Probably not, unless you plan it in right now.

Just like visiting the dentist, going to the DMV, or getting married, you need to make the time to do these things if you know it needs to happen. Otherwise you'll keep putting it off.

Let me make this easy on you. Here's 4 quick and painless steps to get an AppSec program going at your software company:

1. Plan a Review

I totally get it that putting things off is really just you expressing yourself. Which is really cool and empowering and artsy- so don't stop doing that- at home. Just maybe at work you could tweak it a little bit by not doing it. But no big deal. Just when you get around to it maybe you give it a break, like right now.

Any kind of development or maintenance requires a plan and a schedule. Roller coasters don't get inspected only when they make a strange noise. They are inspected daily. An orchestra musician doesn't tune their oboe when it sounds strange, mostly because it always sounds strange, but also because it needs to always be in top working order to get good results.

So here's the thing, open a calendar and write in the application project to be reviewed for security. Put down the names of the lead developers on the project. Invite them to the meeting. Then pick another day, put another project name in it, and invite the lead developers again. Then another. And another. Do this until you're out of names or days, whichever comes first. It's that easy and the inventor of calendar will rest happily in their grave.

You might not feel it now but you're in the pros now! You, just went from reactive security to proactive. Feels good, doesn't it?

2. Scope It Out.

You know why people like the idea of secret societies? Because once they know about them they feel like they're in on the secret. It's really not about some fantasy about being ceremoniously inducted and expected to help them feed the world GMO eggplants in the name of Cobra. It's because being in on the secret is all of the secret and none of the danger. Although, most of us wouldn't mind getting to sit at that huge table at the secret headquarters inside a volcano. Because, you know, volcano!

My point is there's anxiety in not knowing and there's satisfaction from knowing. So you know now where I'm going with this and it's not to start a secret society. (But if you do, totally invite me to your lair!)

Know what you have. Know how it works. Know every application you make, every application even if you don't make it, and all the kinds of ways someone on the network or the Internet can interact with that application. Be in on that secret. And keep being in on it by monitoring how and when it changes.

You're probably thinking, I don't know Cupcake, that sounds like a lot of work. It is. But unlike shoveling snow or spoon-feeding children it's a satisfying job that keeps on giving. Because you just got your baseline.

The tricky part, of course, is how to know all that. Many “security professionals” will tell you to do things but not how to do them. Like it's some “magic” we all know. Like it's “common sense”. But not “me”. This is how:

  • Take the application and list all the things it can do as processes. If it lets you input a document then call that the Document Input process and list it out. If it sends the results of a search to the user then call it the Search process and list it out. You get the idea. Don't forget the login process, password recovery process, or user identification process because those are pretty important.
  • Take all the interactions with the application and list how they interact as processes. If it's in development and the dev team interacts with it then call it the Development process and list how everyone in development connects and interacts with it. If it's in production then it had to get there somehow so list the interactions in the Production process. Don't forget maintenance, updates, caching, back-ups, or any security processes.
  • Make a logical map of each process. If you've been consistent then you'll be doing a lot of copy/pasting. If not then you'll be doing a lot of shaking tears out of your keyboard. Then, while you're waiting for your keyboard to dry, make a logical map on the whiteboard of your new Distributing Process Policy process.
  • Make a network map of where all the applications reside, the security in place, and where the back-ups reside. This will seem really easy after the process maps because who doesn't have network maps, right? Just make sure they're right. You wouldn't be the first person to miss documenting that ad-hoc gopher server. (I didn't say this century.)

3. Set Goals.

Like any good soccer player, you need to have goals. Yes, that was a horrible pun, thanks for noticing. You still here?

You know all that planning and map making I had you do before? Well,setting goals allows you to finish that stuff. It’s security, not ballroom dancing so there's no logical place to stop. You can literally keep mapping and analyzing forever which is why you have goals. Incidentally, like ballroom dancing, you can also stop when the music stops but you don't have to.

Goals also provide you something to aspire to. Do you aspire to getting some sleep anytime soon? Then manage your security. With goals, you need to create metrics that will let you know when you reach them as well as policies that let others know they'd better help you reach them. But most of all, goals let you create lines of communication.

You know how when the home town team on the field is getting beaten game after game and the town rallies behind them. They all chip in and take on part of the work to get the team new equipment and uniforms. The old timers come out of retirement to show the players the tricks of yesteryear that helped them win the cup in '58. A dog with amazing ball skills is allowed to play with the team because the rules don't say a player must be human. And some grumpy octogenarian with a bad attitude coaches them and in the end finds true friendship. What I'm saying is it takes a community to make greatness and that's true outside of Disney TV movies as well. You need to rally together. Goals lets you do that.

At the very least, your dev team and sec team should be sharing goals. Can you do that much? Can you?!

4. Reduce Risk.

The last step is to actively reduce your risk. I know that's like saying after eating healthy and exercising, your next step is to weigh less. But it is. You see you've started a subtle yet powerful chain effect when you started doing step #1 which you may not have noticed. You, my Linked-in friend, made yourself more secure.

What happens is when you want security, real security and not the one that comes with a staple in the corner, you start by breaking down your processes and analyzing interactions. By meeting with developers and other key people of applications you're not just analyzing security but also trying to understand what the applications are actually doing. You are making sure they only do what you want them to do. You are correcting mistakes in them, fixing vulnerabilities, and extending security processes to cover gaps. You're taking control on what you can and will expose to the world.

If you've taken anything away from this article by now, it should be that it's impossible to make sweeping generalizations about application security, so you reach out to a security consultancy to find out what's best for you. Unfortunately, it turns out that most security consultancies rely on bodies of sweeping, general best practices to help you. That's because the general security consultancy is full of general security consultants where the difference between you and them is twenty hours of PowerPoint slides and a multiple choice test where one of the questions may have been about how tall a fence needs to be to be called a security fence. So you need something better.

Your application security needs specific attention and specific expertise. If you can't do that then get the right help, a company that does application security. Be careful though. The cybersecurity industry plays fast and loose with its definitions and is full of made-up terms like micro segmentation, threat intelligence, and cybersecurity. Something about all this makes it seem like all these cyber threats are cartoon villains plotting and twisting their cartoon mustaches.

But after all this you've just come much farther in application security than you ever have. No longer will you have hide under your desk during an audit. You are starting to defend yourself against those cyber threats with their logic bombs and injections ready to wipe you out like they did the dinosaurs. You, my MySpace connection, are making security.

Now go back and read this all again except pretend the title now says maintaining security because it's time to do it all again. This time it'll be easier though, I promise.

Pete knows how to solve very complex security problems. He's co-founder of the Institute for Security and Open Methodologies (ISECOM). He created the international standard on security testing and analysis and Hacker Highschool.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.