Software applications are the weakest link when it comes to the security of the enterprise stack. In The State of Application Security, 2020, Forrester says the majority of external attacks occur either by exploiting a software vulnerability (42%) or through a web application (35%).
As applications become more complex and software development timelines shrink, developers are under pressure to release new features as quickly as possible. As a result, developers rely more heavily on third-party libraries, particularly open source components, to achieve differentiated and compelling application functionality. This increase in open source components forces organizations to adjust their security practices. In addition, new frameworks like containers and APIs add to the complexity of application security.
With developers under pressure to continually release new features, organizations face the very real risk that security won’t keep up. One of the ways organizations can secure their software is by adopting application security best practices and integrating them into their software development life cycle.
To this end, here are the top 10 application security best practices you should already be using in your organization.
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 in your various web apps?
Don’t think tracking your assets is that important? Just ask Equifax, which was hit with a $700 million fine for their failure to protect the data of over 145 million customers, how important it is to remember which software is running in which application. The credit rating agency suffered the breach after they failed to patch the vulnerable Apache Struts open source component in one of their customer web portals. Equifax claimed they weren’t aware the vulnerable open source component was being used in the customer portal.
Keeping track of your assets now saves headaches and disasters later down the line. This process should be automated as much as possible since it can feel like a Sisyphean task as organizations continue to scale their development.
In addition to tracking your assets, take the time to classify them, noting which ones are critical to your business functions and which are of lower importance. This comes in handy later for your threat assessment and remediation strategy.
Once you have a list of what needs protecting, you can begin to figure out what your threats are and how to mitigate them.
What are the paths that hackers could use to breach your application? Do you 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 you need to answer as part of your threat assessment. However, you also need to be realistic about expectations for how secure you can be. This means that even if you take the maximum level of protection available, nothing is ever unhackable. You also need to be honest about what kind of measures you think your team can maintain in the long run. Pushing for too much can lead to your security standards and practices being ignored. Remember that security is a marathon, not a sprint.
In judging your risk, use the basic formula:
Risk = Probability of Attack x Impact of Attack.
Another way to think about risk is how likely something is to happen versus how bad it would be if it did. Chances are pretty low that a whale would drop out of the sky and crush you, though it would be catastrophic if it did. Alternatively, getting bitten by a mosquito while on a hike is pretty likely, yet not likely to cause significant harm beyond a few itchy bumps.
Are you patching your operating systems with the latest versions? What about third-party software? Chances are you’re lagging behind, which means you’re exposed.
Patching your software with updates either from commercial vendors or the open source community is one of the most important steps you can take to ensure the security of your software. When a vulnerability is responsibly discovered and reported to the owners of the product or project, the vulnerability is then published on security advisories and databases like WhiteSource Vulnerability Database for public consumption. Ideally, a fix is created and pushed out before the publication, giving users the chance to secure their software.
However, if you don’t patch when one becomes available, you are not taking that last step toward better security.
Developers may be hesitant to upgrade to the latest version of the software if it could break your product, but automated tools can help tremendously here. Updating and patching should be at the top of your application security best practices list any day of the week.
Containers have grown in popularity over the past few years as more organizations embrace the technology for its flexibility, which 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. Also, the code being stored within the container may itself be vulnerable.
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.
Vulnerabilities have been on the rise in recent years, and this trend shows no sign of letting up anytime soon. Developers have their dance cards full when it comes to remediation. Given the scale of the task at hand, prioritization is essential for teams that 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, you need to know whether your proprietary code is actually using the vulnerable functionality in the open source component. If the vulnerable component’s functionality is not receiving calls from your product, then it is ineffective and not a high risk even if its CVSS rating is critical.
A smart strategy is one that automatically prioritizes the most pressing threats first, taking into account the factors at play, and leaves the low-risk ones for later.
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 at risk.
Your basic checklist encryption should include making sure 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 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.
Not everyone in your organization needs to have access to everything. Application security best practices, as well as guidance from network security, limit access to applications and data to only those who need it.
The reason here is two fold. First, if a hacker is able to gain access to a system using someone from marketing’s credentials, you need to prevent the hacker from roaming into other more sensitive data, such as finance or legal. Second is the concern over insider threats, whether unintentional — losing a laptop or attaching the wrong file to an email — or malicious. By managing privileges and adhering to the Principle of Least Privilege of giving employees access to only the data they need, you could reduce your exposure compared with having no controls in place.
In recent years, developers have taken more ownership of the security of their applications, especially when it comes to tasks like vulnerability management. As security shifts left, developer teams are testing early and often, pushing as many of their security checks to the beginning stages of their development when vulnerabilities are easier and less costly to fix. Given the sheer numbers of vulnerabilities, developers need automated tools to help them manage the unwieldy testing process.
For testing proprietary code during development, static application security testing (SAST) and dynamic application security testing (DAST) can help to find potential vulnerabilities in your code. While SAST and DAST play an important role in closing security holes, proprietary code is a relatively small portion of your overall codebase.
Open source components generally comprise between 60-80% of your codebase in more than 92% of modern applications. This means securing open source components should be a top priority for your application security checklist. Software composition analysis 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 put your applications at risk.
By shifting left your automated testing for open source security issues, you are able to better manage your vulnerabilities.
While automated tools help you to catch the vast majority of security issues before a release, no application security best practices list would be complete without citing the need for pen testing. Pen testers can comb through your code, poking and prodding your app to find weak points. Good pen testers know exactly what a determined hacker will try when breaking into your application.
You can hire professional hacking firms or use 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 bug bounty for your product, you should be.
Despite the extra expenses of working with pen testers, you are far better off paying for white hats to try and break in rather than face the consequences of a breach in the wild.
This should be an easy one to secure, but it is surprising how many developers don’t properly secure their tokens for third-party services.
Unfortunately, you can easily find unsecured tokens online by searching through popular developer websites. Developers simply include the token details in their open source repos instead of storing them somewhere more secure.
Properly securing your third-party tokens should be an application security best practice basic. Please don’t leave tokens you have paid for laying around in your code just waiting for the taking.
Everything in this list of application security best practices should be a part of your organization’s ongoing development process. This list contains the bare minimum of steps that should be taken to minimize 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 application security measures are ever fully hack-proof, following these basic best practices goes a long way in making your application not worth the hassle for the hackers, thereby keeping you and your data safe for another day.