Menu
close
The open web application security project (OWASP) has been a leader in web application security for years. It’s a nonprofit organization that has become very popular for its OWASP Top 10 series. Which routinely highlights the top 10 web application security vulnerabilities based on data collected in the previous year. In the past OWASP focused heavily on how companies could mitigate the risks associated with these vulnerabilities. While this was better than doing nothing it didn’t address the root cause of the issue, which was poor application design. To address this new problem OWASP is moving towards encouraging best practices in web application design over risk mitigation. OWASP’s shift to best practices will give companies the knowledge and awareness needed to build applications that are secure by design.
OWASP was created to be an awareness document and it was never intended to be used as a security standard by itself. However, since its inception in 2003, its popularity has led to it being one of the most widely used sources for web application security practices. To help companies develop their application security program, OWASP has identified six stages for “How to start an AppSec program with the OWASP Top 10”:
OWASP encourages CISOs and AppSec leadership to use the OWASP Software Assurance Maturity Model (SAMM). This model helps companies to identify their weaknesses and areas of improvement over a 1-3 years period. The goal is to evaluate where the organization is currently and identify gaps in the areas of governance, design, implementation, verification, and operations. It also helps you to rank those issues so you know which are urgent and need to be resolved immediately versus those that aren’t a priority. There's also opportunities to accept risks, rather than close them all through patching, so you'll want to be aware of all your options.
OWASP advocates for a concept called the “paved road”, which is simply the idea that the easiest way is also the most secure way. In this concept, they assert that for an application to be developed securely there needs to be a deep relationship between the development team and the security team. Ideally, they should be the same but at the very least they need to work closely together to ensure that the security team gives the developers ample input to develop a secure application.
In this stage, you need to implement the paved road philosophy. This doesn’t just include the application itself but the collaboration and feedback must be given to the entire application ecosystem and the entire enterprise. It should not be a band-aid solution that is put together just for one application or one project, it should be consistent. This stage focuses on implementing 3 key elements for developing secure applications: People, processes, and technology.
As you successfully develop a framework for securing your applications the next step will be moving all of your applications over to that new system. OWASP suggests that this be done one component at a time and as you do so you should implement detection tools that will allow you to gather information for the development team on how they can better improve the security of their applications. Your organization should implement continuous integration checks that will inspect the code and provide warnings or reject any builds that are flagged as insecure. This prevents insecure code from creeping into the application over time, prevents technical debt, and reduces the chance of an insecure application. Ideally, anytime something is flagged as insecure the tool should automatically provide a secure alternative so that the development is given the correct solution immediately.
Next, you should test that your paved road approach has mitigated the issues identified in the OWASP Top 10. These vulnerabilities are commonly targeted in web applications and by addressing them you significantly reduce your risk of exploitation. It’s important that based on your testing you continuously improve on the security components that you use in your secure development lifecycle.
OWASP suggests going beyond just the OWASP top 10, which only covers 10 risk categories. They strongly encourage organizations to adopt the Application Security Verification Standard. This standard provides a basis for testing web application security controls and gives developers a more in-depth list of requirements for secure development compared to the OWASP top 10.
To develop secure applications you need to work with the right security practices in mind. This year the insecure design was introduced to the OWASP top 10 as a new category in the Number 4 position with a focus on risks related to application design flaws. In this section, we are going to go over some of the most important practices for developing secure applications.
Threat modeling is the process of identifying the risks and threats that are most likely to affect your application. This is a very important security practice that should be done at the beginning of the SDLC. This way you can understand what’s needed before you start building the application and you can start planning for the type of security controls that you need to implement to prevent those attacks from happening. There are several threat modeling frameworks that you can use during your planning phase including STRIDE, MITRE ATT&CK, PASTA, and Trike.
An architecture diagram is a diagram of a system/application that is used to show the overall outline of a software system and the relationships, constraints, and boundaries between the components. Using these diagrams is a good way to map out what security controls are needed in the application, where they need to be placed, and how they are interconnected within the application. Use the information that you gained in threat modeling to plan out what controls are needed and how they can be added to your application to ensure security.
Secure design patterns are designed to eliminate the accidental insertions of vulnerabilities into code. A secure pattern is simply a reusable solution for writing/developing code. It allows developers to create secure code quickly and easily without having to “reinvent the wheel” so to speak. One way to do this is to use known secure third-party code in the development of your applications rather than creating it from scratch. This almost ensures that the code you produce is secure because it’s been peer-reviewed by multiple analysts before you. Alternatively, the code in your company’s internal code base should be tested and then reused where possible. Lastly, to confirm that the code/application has been built correctly you should test it using security professionals and software. You can use manual penetration testers or you should leverage companies like Veracode that allow you to submit your code for review by their proprietary software. Regardless of what method you choose you need to have a process for testing your applications for security flaws.
You must train your developers on adhering to OWASP’s best practices. Developers are experts in writing code but not necessarily secure coding. Businesses must take the time to educate their developers and provide training on these practices to ensure that fewer mistakes are made and the overall security of their applications increases.
OWASP is shifting its focus to promoting and teaching best practices rather than simply mitigating risks. This requires companies to implement security processes through the entire SDLC so that applications are built and maintained according to the right practices. In this article, we discussed three main areas that companies need to focus on. First is threat modeling, understanding what the threats and risks are to our applications. Once you have that you should leverage architecture diagrams to map out what security controls you need and how you are going to implement them in your application. Lastly, use secure design patterns to build the application securely. By using pre-existing design patterns you can avoid having to come up with a secure solution yourself and simply reuse existing secure code or follow a secure coding methodology that will help you develop a secure application. Lastly, you should always test your product to ensure that it is secure. This can be done through manual penetration testing or automated security tools provided by companies Veracode that can scan your application/source code for vulnerabilities.
[convertful id="179153"]
301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4
