We live in an era where almost every business application and infrastructure is exposed directly or indirectly over networks. No matter how much security you implement, as long as you don’t secure your application and infrastructure from within, you risk being compromised. OWASP Top 10 is a good place to start your security journey but it’s not enough. Although applications are one of the most commonly attacked assets, there’s not enough focus on securing these. Security starts with developers. So in this post, we’ll look into why just OWASP top 10 is not enough and what developers should be aware of when it comes to security.
Why Developers Need to Write More Secure Code
Application security is implementing best security practices while building an application. Developers usually focus on solving the problem statement first. They build the application keeping functionality in mind and later think about security. This approach is not very efficient especially as we move towards Continuous Integration and Continuous Deployment (CI/CD). Therefore, it’s important for developers to write secure code.
Developers are not usually security experts. And writing secure code doesn’t mean that we eliminate security experts and security testing from the picture. But developers need to be aware of common secure coding practices and implement them early in the development phase. Security experts are still going to review the application and security testing will still happen. But secure coding will make the process more efficient. Implementing security at the core of the application helps reduce internal and external threats and avoid breaches and long-term expenses.
To justify the title of this post, let me first take you through what OWASP Top 10 is, and then we’ll try to understand why just that is not enough.
What is OWASP Top 10?
The Open Web Application Security Project (OWASP) releases a list of vulnerabilities in web applications and how to prevent them, known as the OWASP Top 10. This list features the top 10 security weaknesses that web applications have faced taking into account the severity, frequency, and potential impact. The latest list comprises the following:
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery (SSRF)
This list is prepared after consensus from various security experts around the world. So if you’re just starting with web application security, this is a good place to start. By addressing the issues mentioned in the list, you’d be securing your organization from a good number of attacks. So why is this not enough?
Why OWASP Top 10 Is No Longer Enough and why do Developers Need To Know More?
Did you notice that I mentioned “a good number of attacks” above and not “all attacks”? That’s exactly why OWASP Top 10 is not enough. Although OWASP Top 10 addresses the most common issues, it doesn’t cover all the issues. Buffer overflow, Cross-site Request Forgery (CSRF), and Credential Stuffing are examples of weaknesses not covered in the Top 10 but can still cause great harm.
If you’re just starting with security, OWASP Top 10 is a good place to start. It helps you identify and mitigate some of the most exploited security issues. However, attackers don’t just stick to the OWASP Top 10. They’ll try different approaches apart from the top 10 to perform a successful attack. Therefore, it falls on the shoulders of developers to go beyond the OWASP Top 10.
OWASP Top 10 focuses on the top web application vulnerabilities. But only securing your application against OWASP top 10 is not enough as attackers might find different ways to break in that aren't on the OWASP Top 10. For example, the Uber breach was caused by malware exposing a user’s credentials.
Addressing OWASP Top 10 and applying respective prevention mechanisms definitely adds a layer of security to your organization but just that layer is not enough. So what more can be done to secure your application?
Building on OWASP Top 10: What is Next?
Secure Design
You can enhance the overall security of your organization by keeping security in mind while designing your architecture. Secure design comes as a foundation even before you write your first line of code. Using practices such as the least privileges and secure trust model will make it difficult for attackers to breach your systems. Threat modeling can be of great help in understanding the threats and security requirements. Secure design will help you reduce the attack surface so you can focus more on the areas that matter the most.
DevSecOps
Integrating security activities into the SDLC strengthens the core of applications. Using DevSecOps you identify vulnerabilities in the earlier stages of development so you can address security issues sooner. It reduces vulnerabilities in the application making the security testing faster. It also makes it easy to recover from incidents.
Shifting left impacts the cost of finding and fixing a security issue along with the impact on time spent. A vulnerability gets more expensive to fix depending on how late it is found in the SDLC. The more to the right, the more expensive it gets. So DevSecOps also helps optimize costs.
It’s important to understand that DevSecOps is a culture shift. You need to change the mindset of the team and train them to make this approach efficient.
Secure CloudOps
A lot of organizations are moving to cloud. With this change, attackers have also started to focus more on targeting cloud infrastructures. Secure CloudOps is important to address external and internal threats to cloud infrastructure.
Most cloud providers have a basic level of security available. But it’s the individual responsibility to not be content with that. You will need a configuration that’s most secure for you. There’s room for a lot of improvement with cloud - scaling, proactive security, backup and recovery. And since most secure cloud providers take care of basic security aspects such as regular patching, you can focus on more important aspects that are specific to you.
Secure Software Supply Chain
Solarwinds and log4j are two of the most critical attacks we’ve seen recently. And both of these are 3rd party components. It’s wise to use an existing solution and integrate it within your system/application than building something from scratch. However, if there’s a security issue with these dependencies, it also makes your system vulnerable.
It’s important to assess the security of the dependencies you use. And once you deploy, continuously test and monitor for threats. Automated tools will be of great help here. Some advanced SAST and DAST tools can help you fix vulnerabilities while developing and testing your product so that your systems are safe when you move it to production.
Compliance
Compliance is important for two main reasons:
- They are best security practices and help you enhance security
- To avoid fines
Most organizations need to comply with strict compliance requirements. There’s a lot of encouragement for developers to consider compliance during the development phase. Compliance as Code is one such approach. When developers keep compliance in mind, it makes the overall compliance process more efficient as it avoids major changes. It also reduces cost, creates compliance consistency, and improves collaboration within cross-functional teams.
Closing Notes
Developers are no longer individuals who build a system that solves a problem statement. They are also responsible for security. We went through what the OWASP Top 10 is and why addressing and fixing just that is not enough. Then we touched base on different security aspects developers should be aware of.
With the high demand and need for security, developers have also started turning into security experts to some extent. It won’t be long until developers’ profiles will include security as one of the core responsibilities.
