The “Marriage” of Quality Engineering and Cybersecurity 🤵👰
Hello readers!
Today we will be sharing an interesting “marriage” of Quality Engineering and Cybersecurity, together with very high-level concept charts.
A marriage is bringing two previously unknown persons with the same life goals together. This would require both parties to know what each other is like and whether there are any similar interests and/or goals. The same applies back to our production development work. In a product team, we have many different functions such as:
- Software Engineering
- Quality Engineering
- UI/UX Designing
- Project Management
- Cybersecurity
We’re sure that most of us know how a typical product team functions, but is it really true that only the software engineers need to be concerned about the security of the product?
Of course not!
Previously we mentioned about the “marriage” of the UI/UX and Cybersecurity, but how about Quality Engineering and Cybersecurity?
Looking for “the one”
Take a look at the chart below about Quality Engineering and Cybersecurity.
| Note: This chart doesn’t fully represent the full view of both Quality Engineering and Cyber Security.
Both functions, though different, are actually aiming for the same goal — to improve on product quality.
Based on the chart above, we noticed that there’s one similar element for both “Performance Testing” and “Penetration Testing” .
“It is all about how the system defends and handles various types of network traffic load”
Due to similar elements for both “Performance Testing” and “Penetration Testing”, we decided to combine and re-define into this — how does the application react and handle large amounts of network traffic.
Previously in this Performance Testing article, we shared our list of considerations and requirements for conducting performance tests. Guess what? Part of Penetration Testing also includes conducting a small scale of application layer Denial-of-Service (DoS) attack (which is spamming network calls and hope that the server crashes) on the agreed environment.
And you think by scaling everything to the maximum will resolve DDoS attack issues? 😏
Translating similar element(s) into use cases
The next question is “How can we get a quick view of the performance and the provision of the hosting environment without going through so many stages of planning?”
With this use case, we start to hunt the “matchmaker” of this marriage.
Finding the “matchmaker”
To find this “matchmaker”, we have the following criteria:
- An existing tool that is inside our stash
- Configure and use approach
- Gentle learning curve
After many rounds of spiking, we have managed to find a “matchmaker” for this “marriage” — Burp Suite Professional.
In “Burp Suite Professional”, the “Intruder” module allows a quick and easy way to conduct an application layer Denial-of-Service (DoS) with quick and easy setup. For more details on the module, kindly refer to this documentation.
Note: This method is a quick way of determining if the hosting environment is provisioned with proper resources through the usage of 1 REST API endpoint. Readers are recommended to perform an actual Performance Testing for a full view.
The engineers will only need to perform the following:
- Identify an endpoint from the application
- Configure the payload
- Set the resource pool size
- Select “Denial-of-Service” found in the Attack results options.
- Execute the run
Sustaining the “Marriage”
Just like most things in this world — starting is easy and sustaining is tough. Once the “marriage” is completed, we need to keep it going. Thus, we deployed this approach of testing into some of our products and have gotten positive outcomes from it such as helping the team to save some hosting cost as they configured the same configuration/provision in a non-production environment.
While reviewing the feedback, we also noticed that this form of testing also allows DevOps engineers to know if the “Auto Scaling” is working as intended!
The above is what we have gone through for the past 1+ years — collaborating within a team and solving problems through the combination of different domains and skill sets. We hope that this article will give you some ideas on conducting your own “marriage” between different domains.
Always remember not to be afraid of mixing and/or trialling with different combinations; the outcome is always a mystery and you may get unexpected pleasant surprises from it! And of course, we will (and should) always be constantly learning and continuously improving ourselves as #weAreAgile. So even if the first few attempts of “marriage” fails, try again and don’t give up!
Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.
