When it comes to choosing a vendor that can effectively test your apps for security flaws, there’s just so many different things to consider that it’s easy to be overwhelmed. It’s a crowded marketplace out there, and demand doesn’t always meet the supply, so making an educated decision on who tests your apps can seriously boost or badly impair your ability to deploy secure, stable applications on each release.
But really, how are you supposed to find the right people to figure out if your apps are reasonably secure or leaking sensitive information like a capsized oil tanker?
The first thing you need to do is ask yourself a few questions about what exactly you’re looking to achieve by hiring a third party to examine the security posture of your applications.
- What outcome do you need/expect from this?
If you don’t frequently release new updates to your application, and just need an AppSec assessment to get certified for a compliance standard, your security needs will be much smaller.
- Do you need support fixing bugs?
Depending on the security fluency of your developers, you might need just the vulnerability reports and nothing else, or hands-on support in remediating vulnerabilities.
- Do you need to build a security automation pipeline?
If all you’re looking for is a few security scans a year and nothing more, your security requirements are a lot smaller than if you need security automation set up in your CI/CD pipeline.
Now that we’ve got those out of the way, let’s get to brass tacks. Here are 5 things to keep in mind when you’re looking for an Application Security Testing vendor for your organisation.
1. Threat Modelling
One of the most overlooked aspect of security assessment is threat modelling. A threat model is essentially an ‘Abuse Case’ that helps security testers view the software under test in the same light as the attackers. Security testers use threat modelling as a design analysis technique to develop innovative and effective test cases mirroring the way attackers would view the system.
CIOs and CISOs should consider threat modelling as a critical step when evaluating security assessment providers. Going into an AppSec assessment with a plan is always more effective than going in blind.
Check it out: Download our open source Threat Modelling framework
2. Testing Methodology
It’s important to assess the testing methodology employed by the vendor. Testing methodologies such as OSSTMM and PTES are essential to gauge the effectiveness of an application security test, and product companies should consider them when evaluating vendors. Also, keep in mind that these standards are specific to application security and should not be confused with compliances.
Information Security compliances such as ISO 27001 or PCI-DSS are overarching in nature and cover the organisation as a whole from a security perspective. Compliances also demand application security assessments and mandate that assessments should be conducted under industry standard methodologies such as OSSTMM and PTES.
3. Mode of Testing: Automated vs. Manual
It is essential to understand the difference between an automated and manual security assessment. The automated approach is primarily done via tools and scanners. Although this brings speed and coverage, it often lacks depth. A purely manual approach will ensure depth, but takes too long, thereby, making it impractical as it will adversely affect the application release cycle of production or go-live.
A hybrid testing approach brings the best of both worlds. Using a healthy mix of automation in the initial stages of the assessment (recon, mapping and discovery) and manual techniques in the latter half (exploitation) will ensure depth without sacrificing coverage.
In addition, effective threat modelling can further augment this approach as it will help the security tester to prioritise security risks and run custom exploits to identify deep-rooted business logic vulnerabilities that are unique to each application.
4. Reporting & Analysis
Coming full circle to the final aspect – Effective Reporting. One of the biggest reasons people hate security testing is because of poor reporting. When reports provide high level description of the vulnerabilities instead of details on which page, parameter and exact steps on how to recreate the vulnerability, developers waste hours and hours trying to find the flaw in the code base.
It’s also important to recognise that developers approach an application from a functional perspective. As a result, even when security flaws are reported, they’re at a loss when it comes to fixing the vulnerabilities.
Therefore, it is critical for assessment reports to be as detailed as possible. A good report should clearly enumerate the page, parameter and how the security tester identified the vulnerability (supported by screenshots). It should also provide practical steps on how to resolve them.
5. Adding Value: Building Self-Sufficiency
Although the points above talk about the key aspects that should be considered when selecting a vendor for security assessment, you should also look at value added service enhancements that can help product houses in becoming self reliant with respect to application security.
Validation of vulnerabilities (typically a bottleneck in assessments) can be optimised by automation. Creating validation scripts can greatly reduce validation iterations leading to savings on cost and effort. Scripts can also benefit developers in recreating the vulnerability on a continuous basis, thereby testing successive versions of the application for security flaws.
Training is also an aspect that is overlooked. In many cases, product organisations consider training to be optional; a good to-have and not a need-to-have. On the contrary, periodic training when delivered in a hands-on model with relevant content that brings developers up to speed on the latest threats and exploits, will lead to overall reduction of dependency on third-party vendors for security assessments.