How to get started with Application Security
If you’re anything like me when I first got started in the world of cybersecurity, you’re overwhelmed with where to start. There are so many vulnerabilities to worry about, so many tools and frameworks to choose from and a seemingly large barrier to entry. So how do you get started with Application Security without feeling overwhelmed? Let’s take a look at some of our recommendations!
Pre-requisites to get started with Application Security
Before we go any further, I have to be honest: if you don’t have at least a couple of years of programming experience under your belt, Application Security is probably not for you yet.
Skills you will need to have
You’re going to have to quickly navigate and understand frameworks, languages, and code that you may not be familiar with and that you didn’t write.
You’ll also need to have some familiarity with the platform that code is running on. So if you’re focused on web development, chances are that you’re running on Linux webservers. Knowing basic Linux will come in handy. Otherwise, if you’re running on Windows, you should have some familiarity with Windows server, etc…
If you’re focused on mobile development, you should be familiar with how iOS or Android run.
What you will be spending your time on
At the end of the day, you will be spending the bulk of your time analyzing source code, manipulating requests between your application and backend services, and trying to find holes in the application’s security.
Sound Interesting? Check out our free ebook
If you’ve never touched a line of code before, you won’t be able to do this. Instead, I’d recommend you pause here and enroll in programming training that piques your interest. Get familiar with software development, and in a few years, come back to AppSec!
With that out of the way, let’s get started!
Get started with Application Security by building a baseline
OWASP, if you haven’t heard of it, is a nonprofit foundation that works to improve the security of software through community-led open source software projects. They’ve come a long way over the past 18 years and they provide a breadth of fabulous resources.
So fabulous, in fact, that we’re going to focus our getting started steps on OWASP projects. They provide a great starting point once we can make sense of what the projects are and which ones to take a look at first.
1. Threat Modeling
We’ll start with Threat Modeling. Threat Modeling may not be the most appealing part of Application Security, but it’s an important step for a very simple reason: if you don’t know what your biggest threats are, how can you properly defend against them?
Why Threat Modeling is important
Think of a house that you are moving into. When it comes to deciding how to set up a security system like outside cameras, you’ll probably want to set up a perimeter that covers the entire outside of the house. But, maybe that’s too expensive and too time-consuming, and the return on investment wouldn’t be justifiable (do you really need a camera looking at just a brick wall?). So instead, you identify entry-points, windows, doors, or easy-to-hide spots for a thief to slip into.
That’s your first line of defense.
The next lines of defense need to deal with the fact that a thief might find their way into your home. If so, which rooms are most critical for you to defend? The kitchen? Probably not. Bathrooms? Maybe not the guest bathroom, but probably the master bath since there might be jewelry or prescription drugs.
Just like you would think about defense scenarios for your home to protect your valuables and your family, you should think about defense scenarios for your application, its data, and its infrastructure. One of the best ways to do that is by creating threat models that ask:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
You can’t think of every single possible scenario of how a thief could break into your house and steal your valuables (what if they use a ladder to get on the roof and make an incision to enter through your attic?). You also can’t think of every possible combination of how your application could become compromised.
When you read the roof scenario, I bet you even rolled your eyes and thought “that’s an exaggeration and extremely unlikely because it’s overly complicated and why would anyone go through the trouble? I don’t have anything that valuable.”
That’s precisely the point. Although there are an infinite number of scenarios, not all of them should get our attention because most of them will be extremely unlikely, or even if they’re not unlikely, they won’t amount to anything.
Factors that make a big difference
As the OWASP page mentions, it’s best to start with the factors that make a big difference:
- Assessment scope – “What’s on the line?” Identify tangible assets such as databases, sensitive documents (ie: intellectual property), and intangibles like reputation, brand, etc…
- Identify Threat Agents and Possible Attacks – Who might try to attack your app? Script kiddies? Sophisticated attackers? Nation-states with serious backing? Don’t forget to include inside jobs whether they are by accident or intended.
- Understand existing countermeasures – Are there any? If so, what are they and are they sufficient?
- Identify exploitable vulnerabilities – Once you’ve outlined the above, you can search for vulnerabilities that could be exploited and do damage to your highest valued targets with the possible attacks you outlined.
- Prioritized Identified Risks – Now, prioritize, prioritize, prioritize. If there’s a risk, but the threat model determined that it’s irrelevant, that’s not the best use of your time.
- Identify countermeasures to reduce threats – Knock out your prioritized list by identifying protective measures in order to reduce your risk to acceptable levels.
The goal of threat modeling is to give you focus in an otherwise chaotic situation whether in terms of figuring out where to get started, or even how to handle reported or exploited vulnerabilities.
2. Exploring the ASVS
Once you’ve identified your focus with threat modeling, it’s time to move on to the next step of creating a list of security requirements relevant to your application and organization.
There are different lists available out there, including the OWASP Application Security Verification Standard(ASVS) and MASVS for mobile. There’s also a project called OWASP SAMM that helps provide a measurable way for organizations to analyze and improve their software security posture.
Both the ASVS and SAMM use a 3-tier maturity level.
- ASVS Level 1 is for low assurance levels
- ASVS Level 2 is for applications that contain sensitive data and is the recommended level for most apps
- ASVS Level 3 is for the most critical applications
Think of the maturity levels as stepping stones to platforms that you’d like to reach. Level 1 is the easiest slope to a not-so-great destination, while level 3 is a very steep slope to a beautiful destination. You can’t just leap to level 3, and perhaps you’re not even interested in the years of training required to get to that level.
Categories and Requirements
In addition to the maturity levels, the ASVS has categories, and those categories have requirements. Each requirement has a column for the 3 maturity levels, with a check mark if it is needed to attain that maturity.
So, let’s say that we deem our application to require a level 2 (L2) since we handle some sensitive customer data.
Looking at the first category (page 14), which is V1: Architecture, Design, and Threat Modeling Requirements, we can see that L2 maturity requires requirements V1.1.1 through V1.1.4 to be satisfied.
As a side note, notice how V1.1.2 mentions threat modeling that we talked about previously? This requirement helps ensure we use threat modeling effectively and continuously throughout our SDLC.
As you look at the list of requirements, you’ll quickly realize how lengthy of a document it is. This is another reason why threat modeling is important. Even if L2 is checked for a requirement, especially for some of the later categories and requirements, they may not all apply to your application and/or organization, and they may not be things you deem important to focus on.
So you can start to see that combining the ASVS and Threat Modeling starts to form an important baseline.
Take another quick look at V1.1.1 which is to “Verify the use of a secure software development lifecycle that addresses security in all stages of development. (C1).”
The C1 links to control #1 of the OWASP Top Ten Proactive Controls. Let’s talk about that for a minute.
3. Proactive Controls
Proactive controls are security techniques that we can apply to our software development projects. In this case, OWASP lists the top 10 that we should consider for every software development project.
The first proactive control
C1, or Control 1, is about defining security requirements.
This control explains how to grab those requirements we’ve looked at in prior lessons and turn them into User Stories and Misuse Cases.
User Stories, as long as you’ve been programming for a couple of years, should not be a new concept to you. It takes the perspective of the user, administrator, and describes functionality based on what a user wants the system to do for them.
For example, if we look at ASVS requirement 2.1.1 which is to “Verify that user set passwords are at least 12 characters in length.”
User stories might be:
- As a user, I can enter a password that has a minimum of 12 characters
- As a user, I can enter my username and password to gain access to the application
While a misuse case is a story focused on the attacker and their actions:
- As an attacker, I can find passwords shorter than 12 characters
Breaking down the ASVS requirements into these user stories and misuse cases helps make them more testable by us or our team.
They then explain how to implement the process of successfully using security requirements in four steps.
Step #1: Discovery and Selection
You’re not meant to tackle all of it at one time. Instead, look through the list of requirements from the ASVS and/or any other custom requirements you’ve deemed necessary for your application, and prioritize them — again, leaning on your threat modeling.
Break them down into a manageable amount per release or sprint, and then continue adding more security functionality in each sprint over time.
Step #2: Investigation and Documentation
Review the existing application and compare it against the security requirements that you’ve outlined as necessary from step 1.
From there, figure out which requirements your application meets, and which requirements still need development.
Make sure to document the investigation so that it remains accurate over time.
Step #3: Implementation
After you investigated and documented your findings of deficiency, it’s time to turn that into action like we just talked about and either modify the application to add the new security functionality, or eliminate the insecure option.
Step #4: Test
Implementing the changes isn’t enough. As the final step, you have to create test cases in order to confirm whether the modified functionality solves the requirement or not.
If it doesn’t, then go back to the implementation phase, and if it does, then it’s time to update documentation and move on to the next requirement!
Overview of Proactive Controls
The first control in this list of proactive controls explains how to embed a security mindset into existing or new projects, and in a way that can certainly fit into your SDLC.
The reason they list it as the topmost important, at least in my opinion, is because they want to stress the importance of thinking about security from the very beginning instead of when the code is already in staging, making it far more expensive and time-consuming to fix.
Of course, this is just one control and there are 9 more in this list, so definitely check those out!
4. Recognizing top Application Security risks
One of the best ways to test our code for application security risks is to manually review that code. Sure, there are a lot of tools out there and they serve an important purpose, but oftentimes they are best at finding low-hanging fruit. They can’t be our only testing method – we have to still manually review code.
This requires a lot of skill and experience, and it isn’t something you can do without at least understanding what some of the biggest risks facing web, mobile, or cloud applications are.
That’s one of the reasons to study the OWASP Top 10 Web App Risks and OWASP Top 10 Mobile App Risks.
As you learn to understand, recognize, and prevent these top risks, you can better protect your apps against the most common attacks.
With that said, we can’t stop there. Unfortunately, there are far more risks out there than just a list of the top 10. So while it is a fantastic starting point, we have to go beyond that.
Where do you go from here?
Stay up-to-date with the AppSec world
One of the best ways to go beyond the starting point is to stay up-to-date with trends, developments, resources, and anything else that can keep us on our toes.
Reasons to stay up-to-date
For example, while we primarily talked about Mobile and Web Application Security frameworks, every day more and more serverless code is being run, which means more and more attacks are bound to target serverless apps.
IoT isn’t new either, but it’s big business. With big business comes attention — attention from people looking to make money, gain power, or simply practice their skills.
If you or your organization are planning on running serverless, running IoT devices, or developing either of those, that’s definitely something to consider. Finding ways of staying up-to-date can help ensure that we don’t miss these changing developments and assume that things are staying constant, because they’re not.
Ways of staying up-to-date
So what are some ways of staying up-to-date?
Join the Cybr community
My first recommendation is to frequently check and contribute to our community at Cybr. You can do that by going in the forums, and you can also check out our industry news feed.
Conferences and meetups
Next, I’d recommend that you look into OWASP conferences since they host them all around the world. They also have meetup chapters, so I would check to see if they have any local to you. This is a great way to meet others with similar interests, to ask questions from people of all skill levels, and to find opportunities that you may not otherwise get. There are many other cybersec conferences and meetups, and you can find those by asking around!
Follow experts and practitioners on social media
Of course, I’d recommend finding people on social media who are experts or even practitioners in this field and following them or connecting with them. Learn from what they post. Ask them questions, contribute to their posts!
Here are a few to get you started:
Have others you’d recommend we follow? Please share here!
Find other communities like Slack communities. Even if they’re not AppSec-specific, they may contain great information and insight. TechStudySlack is a community started by a friend of ours, and it focuses primarily on cloud, but they also have a general #security channel.
Get updates and tips from us on social media
Be sure to follow Cybr’s social media accounts for regular updates and tips:
Feel free to follow me on LinkedIn or Twitter.
Continue learning more about AppSec
While the goal of this blog post was to give you a starting point for your Application Security interests, there’s a whole lot more to discover, and that’s the fun of it!
Check out our free Introduction to Application Security course. If you’re more of an ebook format fan, check out the ebook version of that course.
Of course, we have more articles like these on our blog.
Thanks for reading, and happy learning!