4 steps to getting started securing applications

A lot of times, especially when you join smaller organizations, there are no (or very few) formal processes in place. The approach taken to secure applications and resources is a team of developers saying: “Let’s follow best practices and review each other’s code before pushing to production, and that will be good for now.” Because no one really has the time, or the experience, to take it on.

On top of that, you may already have one or more existing applications, and it can be overwhelming to know where to start and how to get everyone on board with taking a more systematic approach to Application Security.

Or maybe you do have the luxury of getting started before a single line of code gets typed, but you haven’t really done it before from the ground up, and you’re not sure where to start.

Regardless of your situation, you have to start somewhere and then work your way through. 

In this post, we’ll take a look at some critical steps you can take to start securing your applications with a strategy instead of as an afterthought.

We also have another article on how to get started with application security if you’d like additional information.

Step 1: Know what you’ve got

Regardless of whether we’re talking about Application Security or another Information Security specialty, knowing what you’ve got is going to be step one. You can’t protect what you don’t know you have and many organizations are still blissfully ignorant of things that they’ve got on the web.

I’ve seen organizations go from monolithic applications to microservices, and they didn’t have any asset management systems or strategy in place before or after that transition. Not only can keeping track of your resources be a challenge for monolithic applications, but once you break it out into potentially hundreds or thousands of services, it becomes much more complicated, and no one ends up doing it.

So if you’re part of an organization that already has existing resources, then day 1 of getting started securing applications should consist of taking inventory and creating a catalog of all the things that exist.

If your organization already has existing resources and they’re about to start creating more, or refactor (ie: going from a monolith to microservices), or just all around start from scratch on a brand new project, make sure they start by implementing that asset management system!

Keep track of what you and your team create.

You’ll want to document things like:

• Web services
• Internal apps
• Data stores
• APIs
• etc

There are a plethora of tools that exist for this purpose, and it will depend on your exact needs, so definitely research what will work best for you. If you’re a small company or startup, you could potentially even get away with just a list that details all of your assets to start. That won’t scale well, but it’s better than nothing.

Step 2: Understand top risks

Once you’ve taken inventory of your assets, the next step to take is to understand the top risks facing those assets and resources.

For web or mobile applications, you can’t go wrong with the OWASP top 10 lists as a starting point.

These lists produce guidance around the top 10 biggest threats that are out there. Even if they are not the only web app vulnerabilities, they are the most prevalent, which presents an opportunity to protect against the biggest risks as a starting point.

For example, Injections are in the #1 spot. Injections are bad, because it means that data is leaving your organization, or someone is taking control over your infrastructure.

By being aware of what injections are, how they work, and the impact they can have on your app and business, it can help you understand priority and whether it is relevant to your applications or not. More on this in a bit.

At a minimum, you need to understand what the top 10 are, because now that you’ve got an inventory of your assets, you can have a better idea of which risks in the top 10 might be relevant to those assets, which will help you narrow it down.

This might seem basic and unnecessary to mention in this post if you’re already familiar with the top 10, but you’d be surprised how many developers aren’t familiar with those lists! And even if you are, your development team might not be. You’ll need their buy-in on this, so I’d recommend sending it to them and asking them to spend some time reading through it at a minimum.

Step 3: Implement frameworks

Once you’ve taken inventory from step 1, and you or your team have become familiar with the OWASP top 10 lists from step 2, its time to start implementing frameworks to help you move forward.

Even just the thought of taking action can be completely overwhelming if you’re by yourself, part of a small team, or even part of a larger team which will require buy-in from key players.

Many will see this as something else to add on to their to-do list when they’re already overwhelmed.

The good news is that while, yes, this will add some work to people’s plates in the near-term, once implemented and practiced, it will make things much easier long-term.

It will also diminish your odds of having to deal with emergency security issues down the road, or of announcing to your customers that their data was stolen from your company, which are both great things in my book.
That’s where frameworks like the ones below make a huge difference, and it’s also why we created a free Introduction to Application Security course that discusses everything in this post, and more.

Security verification standards

Again, for web and mobile applications, OWASP has published verification standards that are invaluable when securing applications. They aren’t the only ones out there, but they are a fantastic starting point when getting started securing applications.

For web applications, you will want to take a look at the ASVS (Application Security Verification Standard). For mobile applications, you will want to look at the ASVS and the MASVS. The reason I still include the ASVS for mobile in addition to the MASVS is because most mobile apps also rely on web services (ie: APIs) to function properly, so you’ll want to make sure the end-to-end is protected.

These frameworks are critical to:

1. Implement effective security controls
2. Verify that those security controls are properly implemented

They also provide you with a huge shortcut to getting started, because contributors have put in the months it takes to get something like this created. Not all of it will be relevant to you, but that’s totally fine. Let’s talk about how to approach that in this next section.

Familiarize yourself with Proactive Controls

In the ASVS and MASVS, you’ll notice that some of the requirements reference something called Proactive Controls. For example, for Requirement V1.1.1:

• Verify the use of a secure software development lifecycle that addresses security in all stages of development. (C1)

It is referencing C1, or Proactive Control #1, which is:

• C1: Define Security Requirements

Taking a step back for a moment, OWASP defines the Top 10 Proactive Controls list as being the most important control and control categories that every architect and developer should absolutely, 100% include in every project.

So again, this can help us narrow things down a bit, even within the ASVS/MASVS.

Instead of exploring them in this post, which we do in our Intro to AppSec course, I’ll just briefly mention the implementation part of C1, which is very helpful and important.

As this page mentions, successful use of security requirements involves four steps:

1. Discovery and Selection
2. Investigation and Documentation
3. Implementation
4. Test

“The point of discovery and selection is to choose a manageable number of security requirements for this release or sprint, and then continue to iterate for each sprint, adding more security functionality over time.”

The point is not to try and implement every requirement at once and in the beginning. That would simply be too much. The point is to slowly and methodically introduce security requirements relevant to your current and anticipated sprints, and then to iterate.

Then, you’ll want to check the current state of your application(s) against those selected requirements, documenting whether development is required for them or not.

If development is required, then that gets added in to your sprint for implementation.

Once implemented, you then test to validate the implementation, and finally you document.

Rinse and repeat.

This 1st proactive control is a great way to create the mindset of implementing security from the very beginning of the SDLC instead of after code has already been written.

So by using the Proactive Controls list in addition to the ASVS/MASVS, and the two prior steps from this article, you’ve already got a lot of your work cut out for you.

Step 4: Join and engage in the AppSec community

This can be everything from following someone on Twitter who posts insights, all the way to reading blogs, listening to talks, or (when things go back to normal), going to in-person conferences and networking.

Following AppSec professionals on Twitter can be a great way to see what they share and publish, and to ask questions. 

Of course, listening and attending talks can be a great way to stay on top of changes, since this field changes all of the time, and it can help you meet others in the industry you can learn from, which is invaluable.

An example of conferences that would help is the OWASP Chapters. Of course, there are others, and it depends largely on where you live or where you can travel to, so a quick Google search should help out.

Conclusion on getting started securing applications

My hope with this article was to give you a down-to-earth approach and roadmap to getting started securing applications. If you’re planning on joining a large organization, a lot of this will already be part of a set of processes that you have to follow. 

But, if you’ve primarily worked at startups/companies with less than 500 employees, chances are that there’s a lot of work left to be done, and not necessarily much guidance to get you through it.

This can be incredibly overwhelming, especially if you don’t have much prior experience dealing with AppSec.

Or perhaps you’re reading this because you’re interested in AppSec as a career, and you’re trying to understand how and where to get started.
Either way, I hope this provided guidance. If you’d like to continue learning more, check out our free Introduction to Application Security(AppSec) course, where we cover these different approaches, techniques, and frameworks, and how to implement them successfully.