This article has also been published on Emmas blog.
You guessed it from the title, but security testing is really just another type of testing. Secure development is not rocket science, but a mindset inside of the scope of any development.
Security is essentially to know your product, both how it’s designed to work (happy path) and how it can be broken (exception paths). If you build a skyscraper, you do not only build it for sunny weather but also for hurricanes. If you’re building software that you sell, the customer expects the software to enable their business, not to block it.
Security is to find bugs and be able to perform good triage on them.
Security is also to have a prestigeless, nonblaming working environment where found bugs actually can be fixed.
I see very talented testers shrug and run away when it comes to security. So let’s be sneaky and stop calling it security testing. How about… regression testing?
Step 1: Regression testing from a security perspective
Let’s look at a possible test chart for the change password feature inside of an app.
- The user must be logged in to their own account
- The user must know their old password to be able to change password
- The user must only be able to change the password on their own account
- The old password must stop working
- The new password must start working
Seems pretty straight forward, does it not? This is the type of tests that you do in regression testing all the time. The normal tester would not be intimidated to test the features around account management, but they wouldn’t want to call it security testing. Also, like all regression testing, it’s a first step. There is no guarantee that some guy with a hoodie and bad hygiene won’t hack you. Regression testing will not cover all your bases, but it will cover some and it will increase your confidence in your product.
Step 2: Exploratory testing from a security perspective
I’m sure you some time have been thinking at the airport security how you would go about to smuggle something. Or noticed that they didn’t find that 250 ml tube of liquid you accidentally forgot to put in the plastic bag. What security holes can you think of at an airport?
Thinking like an attacker is a lot of fun, and can expose more serious issues.
The focus of exploratory testing is more on testing as a “thinking” activity. Exploratory testing is a creative exercise!
My colleague Michal excellently wrote that ethical hackers share the same mindset as exploratory testers, and I agree. Where might the system fail? What happens if it does fail? Try to provoke the system into failing, instead of verifying that it doesn’t fail.
As a sidenote: I would even call this methodology a scientific method, or at least the embryo of one. Good science doesn’t verify hypotheses, it falsifies them. A scientist actively and constantly challenges their belief, and that’s what a good exploratory tester or ethical hackers does as well.
Step 3: Domain knowledge of security
This is what most testers mean when they say they don’t know security. They haven’t sorted their knowledge under the “security hat”. They may not even have the specific knowledge needed. Is AES sufficient password as hashing algorithm? (no, and it’s the wrong question) Is it right to send passwords via mail? (nope) What is a security header, why do you salt a password, and goddamnit security will destroy the user experience so let’s skip it all together…
This is where most people feel security fatigue: the feeling that since we can’t protect against advanced threats and targeted attacks, we might as well not put in any effort at all.
Indeed this is daunting. Even I as a security nerd sometimes feel it, so no question many testers will begin before they start. But you’re not alone at this, and by doing the steps above you have already done the most important parts! And there are many helpful people out there willing to bring you cheat sheets and automated testing tools!