Application Security Best Practices Top 10 Checklist

August 1, 2019 Gabriel Avner

 

Software applications play an integral role in how we interact with the world around us. They help us ask for directions, meet the love of our life (or a close enough equivalent), shop, build new technologies, and more. However as the software development industry has seen massive growth in recent years, we need to ask if organizations are doing enough to follow application security best practices to keep their users safe from the likes of hackers and other digital miscreants.

The growth of mobile applications, Internet of Things (IoT), and the fact that it has become standard practice for companies that do not come from the software development industry to develop applications, have all led to a situation where issues of application security can fall through the cracks. This is especially true with less experienced development teams that are rushed to get their new version up on time and may not be up on application security best practices that they can employ to keep their products secure.

In hopes of saving these teams, as well as providing a solid refresher for more experienced organizations, we have pulled together the top 10 application security practices that you should already be using for your organization.   

#1 Track Your Assets 

You can’t protect what you don’t know you have.

Do you know which servers you are using for specific functions or apps? Which open source components are you using in you various web apps? 

Just ask Equifax which was recently hit with a $700 million fine for their failure to protect the data of over 145 million people how important it is to remember which software is running in which application. The credit rating agency suffered the breach when they failed to patch the vulnerable Apache Struts open source component in one of their customer web portals, supposedly because they were unaware that it was in use there. 

Keeping a running track of your assets now can help save headaches and disasters later down the line. I advise automating as much of this process as possible since it can feel like a Sisyphean task as organizations continue to scale their development.

While you are at it, take the time to classify your assets, noting which ones are critical to your business functions, and which are of various lower importance. This will come in handy later for your threat assessment and remediation strategy.

#2 Perform a Threat Assessment

Once we have a list of what needs protecting, we can now begin to figure out what our threats are and how to mitigate them.

What are the paths that hackers could use to breach our application? Do we have existing security measures in place to detect or prevent an attack? Are more or different tools needed?

These are just some of the questions that need to be asked in going about your threat assessment. However, it is important to also be realistic about expectations for how secure we can be. This means that even if we take the maximum level of protection that we can think of, nothing is ever unhackable. We also need to be honest about what kind of measures we think that our team can really maintain over the long run. Pushing for too much can lead to our security standards and practices being ignored. Remember that security is a marathon, not a sprint.

In judging what our risk is, we can use the basic formula of Risk = Probability of Attack x Impact of Attack.

Another way to think about it is how likely is something to happen versus how bad will it be if it does. Chances that a whale is going to drop out of the sky and crush you are pretty low, but it would be pretty bad if it did. Alternatively, getting bitten by mosquitoes while on a hike is pretty likely, so while annoying, is not likely to be the end of the world.  

#3 Stay on Top of your Patching 

Are you patching your operating systems with the latest versions? What about third-party software? Chances are that you are lagging behind. The question is though, how exposed are you leaving yourself?

Patching your software with updates either from commercial vendors or the open source community that maintains projects is one of the most important steps that you can take to ensure the security of your software. This is because when a vulnerability is responsibly discovered and reported by a security researcher to the owners of the product or project, it is then published on security advisories and databases like the National Vulnerability Database (NVD) for public consumption. Ideally, a fix is created and pushed out before the publication, giving users the chance to secure their software.

However, if we do not patch when one becomes available, then we are not taking that last step towards better security. 

For fairness’s sake, I understand that many developers may be hesitant to upgrade to the latest version of the software as there is a chance that it may not be backwards compatible and could break your product. That said, updating and patching should be towards the top of your application security best practices list any day of the week.  

 

#4 Manage your Containers

Containers have grown in popularity over the past few years as more organizations embrace the technology for its flexibility that makes it easier to build, test, and deploy across various environments throughout the SDLC. 

Containers are generally believed to come with security advantages that give them a leg up. Given their self-contained OS environment, they are segmented by design, thus lowering the risk level to other applications. However, containers still face risks from exploits such as a breakout attack where the isolation is broken. There is also the possibility that the code being stored within the container may itself be vulnerable. 

In order to secure your container usage throughout the CI/CD pipeline, you should run automated scans for proprietary and open source vulnerabilities from start to finish, including in your registries. 

Along with these scans, application security best practices for working with containers also include important steps like signing your own images with tools like Docker Content Trust if you are using Docker Hub, or Shared Access Signature if your team is on Microsoft’s Azure.    

#5 Strategize your Remediation Ops

Vulnerabilities have been on the rise in recent years, spiking drastically in 2017 when the count more than doubled from the previous year. This trend shows no sign of letting up anytime soon, meaning that developers have their dance cards full when it comes to remediations.

Given the scale of the task at hand, prioritization here is essential for teams who hope to keep their applications secure while maintaining their sanity.

Doing so requires performing a threat assessment based on the severity of a vulnerability (CVSS rating), how critical the impacted application is to your operations, and a variety of other factors. When it comes to open source vulnerabilities, it also helps to understand if your proprietary code is actually making use of the vulnerable functionality in the given open source component. If the vulnerable component’s functionality is not receiving calls from your product, then it is considered to be ineffective and therefore not a high risk, even if it has a severe CVSS rating.

A smart strategy is one that prioritizes the most pressing threats first, taking into account the factors at play, and leaves the low-risk ones for later.   

#6 Encrypt, Encrypt, Encrypt  

This one has been on the OWASP Top 10 for years, making encryption of your data at rest and in transit a must-have on any application security best practices list. 

Failure to properly lock down your traffic can lead to the exposure of sensitive data through man-in-the-middle attacks and other forms of intrusion. If for example, you are storing user IDs and passwords, or other types of info that could put your customers at risk, in plain text, then you are putting them and your future business with them at risk. 

Your basic checklist here for encryption should include items like making sure that you are using SSL with an up to date certificate. HTTPS has become the standard these days, so do not be left behind. Hashing is also your friend and a good idea.

Also, always remember not to “roll your own crypto” as they say. Work with security products that have a dedicated team and the experience to do it right.

#7 Manage privileges

Not everyone in your organization needs to have access to everything. Application security best practices, as well as guidance from network security, encourage us to limit access to only those who need it.

The reason here is two fold. First is that if a hacker is able to pop Bob in accounting’s credentials, we would like to avoid giving them the freedom to roam latterly into other more sensitive data. Second is our almost scarier concern over insider threats. If an employee decides to betray your trust and illicitly access something sensitive that could hurt your company, they may be able to do so if controls are not in place.

In order to avoid such unpleasantness, adhere to the Principle of Least Privilege, giving only access to users that they need to do their jobs. While it may lead to some annoyances, it is also a good way to avoid unnecessary exposure. 

 

#8 Embrace Automation for your Vulnerability Management

In recent years developers have taken significantly more ownership for the security of their applications, especially when it comes to tasks like vulnerability management. Even as this transfer of responsibility appears to be the right move given the fact that developers have the necessary knowledge to address the vulnerabilities and their proximity to the code throughout the development process, it is now more challenging than ever before.

The sheer number of vulnerabilities have been on the rise since 2017 like we mentioned above in the notes on strategizing remediation ops. Given this scale, developers need automated tools as force multipliers to help them keep up with the number of alerts which are coming their way.

Developers have been on the path towards more automated testing becoming the standard over the last few years with the rise of DevOps. More recently, many organizations are seeking to make the transition to insert security into their SDLC, hoping to gain the mantle of being a DevSecOps squad.

These teams are using automation to test early and often, pushing as many of their security checks to the beginning stages of their development in the goal of catching them when they are still easy to manage. This strategy helps to avoid painful tear and replace ops that can come at a test before a release.

For testing proprietary code during development, Static Application Security Testing (SAST) can help to find potential vulnerabilities in your code. While this can play an important role in closing security holes, proprietary code is only a relatively small proportion of the overall codebase. 

Open source components generally comprise between 60-80% of the code base in over 92% of modern applications, making securing them a top priority for your application security checklist. Software Composition Analysis (SCA) tools can help teams to run automated security checks and reporting throughout the SDLC, identifying all of the open source components in their environment and detecting which ones have known vulnerabilities that can put your applications at risk.

By shifting left our automated testing for open source security issues, we are able to make the job of vulnerability management far more feasible.

#9 Pentest / Work with the community of bug hunters

While automation will help you to catch the vast majority of security issues before a release, or even post-deployment when done correctly since new vulnerabilities can be published, no application security best practices checklist would be complete without citing the need for pentesting.

These talented guys and gals can comb through your code, poking and prodding your app to find the weak points. As many of these hopefully law-abiding citizens have a past in the darker regions of the hacking world, they know exactly what a determined hacker will likely try when breaking into your application. Relatively small operations, teams at companies like Shevirah, Insomnia Security and Luta Security will put your code through the ringer before the attackers do.

Along with these professional hacking firms, there are always the freelancers who work with bug bounty programs like HackerOne and BugCrowd who seek out vulnerabilities on their own for cash prizes. If you are not already sponsoring a bounty for your product, then you probably should be.

Even if it can be annoying to add the extra expenses of working with an outside firm, it is better to pay for white hats to try and break in rather than face the consequences for a breach when customers find out that you passed on sending your app through the rough and tumble of human testing. 

#10 Be Careful with Tokens 

This should be an easy one to deal with yet it is still facepalm-worthy none the less. About a year ago, a developer friend asked if I wanted to see something stupid. “Always,” I replied eagerly.

Said developer promptly ran a search on a popular developer resource website for tokens pertaining to a number of widely used third-party services, explaining to me that this is how he could find free tokens online. As he explained it, some developers would simply include the token details in their open source repos instead of storing them somewhere more secure.

This should be an application security best practice basic. Please don’t leave the tokens that you have paid for laying around in your code just waiting for the taking.

 

Application Security Best Practices as Basic Practices

Everything in this list of application security best practices should be a part of the ongoing process of how your organization develops your products. This list is intentionally devoid of steps that fall outside of the bare minimum of steps that should be taken for minimizing the risks to your company’s applications and data.

Staying ahead of hackers is in large part avoiding the common mistakes that others are likely to make, making yourself a harder target to exploit than others. While no perimeter or other protections are ever fully hacked proof and a determined hacker can find alternative modes of entry into an organization, following these basic best practices will go a long way in making your application not worth the hassle for the hackers, hopefully keeping you and your data safe for another day.  

 
Previous Article
Top 5 New Open Source Security Vulnerabilities in July 2019
Top 5 New Open Source Security Vulnerabilities in July 2019

Next Article
5 Vulnerability Assessment Common Misperceptions
5 Vulnerability Assessment Common Misperceptions