United by Security: The Test that Divides Us
By Jahmel Harris @JayHarris_Sec & Claire Reckless @clairereckless
Claire Reckless is a software tester primarily in enterprise software. Jay Harris is a penetration tester (ethical hacker). They are really interested in helping testers take security in their own hands.
In today’s talk, Jay and Claire hope to convince people in the room that security is something that they can do and be involved in. Claire was at a security conference last year and there was a very nasty security bug found: ‘this was a QA error for not catching it’. This obviously annoyed Claire and today, they strive to close the gap between testing and security and the other way around.
They start with “Modelling the System”. Modelling is something that can make you understand your system and its vulnerabilities better. She brings up the mnemonic SFDPOT.
Threat Modelling:
It was a whole team exercise. They got the whole team in the room and drew up the entire system.
the STRIDE Threat Model.
Spoofing
Tampering
Repudiation
Information Disclose
Denial of Service
Elevation of Privilege
They use these to break down and categorize the different threats. Going through the entire model did take a long time – in latter sessions they brainstormed around these topics. It really helped them to think about these kind of things and include them in the user story level.
Jay finds that often companies haven’t really done threat modeling for their systems. When the threats (and therefore the risks) are not clear, the pen testing takes longer, becomes more expensive and is less valuable as a lot of really common security issues are there. There are so many low risk issues, that high risks slip through. Normally, for penetration test assignments: there is not a lot of time (a few days at most) and he usually works from a black box perspective.
It is more useful to bring in security experts at the start of a project to include the security requirements (that follow from the Threat Modeling). This means that when the pen test then happens, only the complex issues exist. By making the security requirements explicit, it makes it easier to test against as well.
There are multiple way of discovering Threats:
Thinking like an attacker is a key one.
The threat modeling Claire and Jay already discussed
“Abuse Cases”
Previous Pen Test Reports
Training
External Help (security consultants)
Abuse Cases:
As an attacker, I want to … log into the application without knowing the password
How might that happen? Brute forcing the password? SQL injection? Performing a password reset of specified user? Something else? Try to think of what might be relevant for your application.
Claire gives a shout-out to @berenvd & TestSphere. Claire experimented with Risk-Threat Storming using TestSphere. If you are interested in learning more about Riskstorming and TestSphere: talk to Beren or read some of the blogs on this topic.
The next topic Claire and Jay want to talk about is Exploration. A lot of security focuses on what users probably shouldn’t be doing…. So, Claire got a couple of exploratory testers in the room to do testing with a security focus. They used Mob Hacking to tackle the topic and collaborate together. The testers did not have security background necessarily: they focused on a number of issues: tokens, authentication responses, logfiles. There were a lot of different things they focused on and it was a great learning experience and they found a number of issues. Because they did not have a lot of security knowledge, they did not always know if it was really a security bug. But what they did find was what Claire has now dubbed: Security Smells. Like code smells, they indicate that there is likely a deeper problem there.
Code smells: a surface indication that usually correspond to a deeper problem in the system.
Jay encourages everyone to do these types of testing. The skills to do exploratory testers are key to doing exploration well and it’s something testers do well. Security experts are experts in security but perhaps less focused on how to do exploration well.
Jay goes into detail on what kind of tools people need in their toolbelt to do this well. He encourages people to look under the hood of their application. How does data flow through the system? There are a number of tools that can help guide us there.
The OWASP Top 10 is a brilliant introduction on common security vulnerabilities.
CIA Triad:
Confidentially
Integrity
Availability
If one of these is compromised: there is likely a security flaw!
Jay shares a story: ‘Think Like an Attacker’:
An application that requires a log-in has protection against a brute force attack: when someone logs in with the wrong data more than 3 times, they get locked out of their account. Confidentially of the data is covered in this case. However: an attacker can intentionally start locking people out of their accounts and that compromised the availability.
Automation can help security testing greatly – if done well.
Jay hightlights that pentesting: it is a point in time – which is useful. The only thing worse than NOT doing security testing is THINKING you are doing security testing (but are not really).
Jay and Claire emphasize how much more valuable we can be if we all work together: security experts and testers alike. Security does not need to be a blocker; it can be an enabler.
In conclusion, security is everyone’s responsibility. (And we already have a lot more skills than we think). You don’t need to be an expert to find common vulnerability. In fact, it might be easier if you understand the product.
Thank you Jay & Claire!