Does your appsec team struggle with trying to perform security testing on all of your applications? Do you struggle with trying to find more resources for your team to scale your team?
What is your relationship with the QA team?
Often times, we focus on the developers and overlook the QA team. Why? QA engineers are professional testers. The big difference is that they focus on verifying functionality works instead of focusing on how functionality could be mis-used. This shouldn’t be a reason for QA to not be a partner in security testing.
Breaking security issues down to their simplest forms, most are actually pretty straightforward and easy to test for. You most likely already have scanning tools to look for many categories of vulnerabilities. This presents an opportunity to focus on items that tools don’t easily find.
For example, consider a simple authorization flaw like Insecure Direct Object Reference. This is commonly found when the application is accessing data by a direct identifier. For example:
developsec.com/userprofile/5488
In the above URL, we can see that we are accessing user 5488 to view their profile. A very simple test would be to modify that ID at the end to something else, like 5400 to see what happens. If the profile is returned, but the current user is not authorized to see it, then we have a vulnerability. If the user is allowed to see this profile, then that test is good. That doesn’t mean that there is not a vulnerability. To be thorough, you would actually set up a test case where you are trying to access an ID of a user that you know the current user shouldn’t have access to.
This is actually a perfect test case for the QA team. They already have multiple roles configured and understand who does and doesn’t have access to them. It is quick to set up a test case to verify that one user doesn’t have access to another user’s account if that is the rule.
This is also a good example of a vulnerablity that scanners often struggle with. How does the scanner know if user 5488 should or should not have access to 5400? It doesn’t.
Breaking down vulnerabilities to a simple pattern can make them good candidates to be included in QA tests.
The key to this is building a strong relationship with all development groups. To be clear, this is not handing over all security testing to other teams. This is an approach to identify specific tests that make sense in other areas to make sure everyone has the capabilities to provide the best coverage.