You never know how resilient your application is until you conduct stress/load testing. In this blog, we will focus on pushing your application to its limits, literally!
Note that we will only focus on the third maturity level for this security practice, namely security stress testing.
Implementing Misuse/Abuse testing security practice from SAMM
What are the benefits of adding stress testing to my Application Security program?
The objective behind the third maturity level in Abuse testing is maintaining the application security level after bug fixes, changes, or during maintenance. The main benefit when adding this practice to your AppSec program is the transparency of resilience against denial of service attacks. It is also an opportunity to test your traffic sinkholing strategy. Note that L3 of this practice focuses on stress testing in the context of security. However, availability falls under security in general. Hence, we consider high-load events even from legitimate users as part of this activity.
How do I implement security stress testing?
For this activity you will obviously need appropriate tooling. There are quite some tools available out there for this sort of testing (e.g., ab, siege, Apache jMeter). We have selected Apache jMeter given its simplicity and flexibility.
Stress test scenarios
To implement this security practice, you start building stress test scenarios that replicate user interaction with your application. Once again, you can consider also positive user scenarios in addition to abuse cases.
To implement abuse case you can start sending way too many strange requests in a short amount of time (just like an attacker would do).
In addition to this scenario you can also simulate legitimate traffic, like an online store on Black Friday would experience (e.g. requests that are putting items in the cart, checking out) or a university exam software during class (e.g. saving answers).
Stress test server deployment
The system can be either a test instance that is an exact replica of the production environment or the production environment itself.
The pros of doing it on a separate server is that there would be no risk from affecting real users and real data. However, building an exact copy of the infrastructure may be infeasible.
Another option is to use the same sever but with a “shadow copy” of the application. This way real data and test data are separated, but since both applications are on the same server denial-of-service will affect both.
Of course, the easiest way will be to execute it on the production environment, but stick to doing it on expected offload.
Note that because the tool can replicate a lot of users/threads it is very possible that if a big number of such entities is chosen or a too large load is simulated the server might not be able to hold the traffic, which will end up in a denial-of-service. On the bright side, it would be better if you do it than waiting for an attacker (or legitimate users) to do it for you when it is least expected!
Performing this kind of tests will show you how ready your environment is for big traffic and how resilient it is when it comes to Denial-of-Service (DoS).
Adding Stress Testing to my DevSecOps build pipeline
Additional things that we have done is that a stress test is scheduled to run automatically on a regular basis. We have integrated it in the CI/CD pipeline and adjusted the schedule there. We have added a config with the pass/fail criteria for the test (total amount of error response codes, maximum response time, average response time, etc). We’ve developed a custom script that fails the pipeline and sends us a notification if the above criteria are not met.
What is a traffic sinkholing strategy?
A traffic sinkhole is the process of diverting malicious traffic from your precious customer facing server in production to research servers where the traffic can be analysed by security engineers to provide information about the attack. Beyond a certain volume of malicious traffic only sinkholes can save you. However an overly enthusiastic sinkhole will cause issues for legitimate users. In the OWASP SAMM framework your sinkhole strategy falls under Operations- Incident Management- Incident Response, however it would logically be tested here in the requirement driven testing.
In this blog we have presented how Codific implements maturity level 3 of Misuse/Abuse testing practice. This is essential if you really want to see how much your application can take.
What do we build with SAMM and SAMMY?
Codific is a team of security software engineers that leverage privacy by design principles to build secure cloud solutions. We build applications in different verticals such as HR-tech, Ed-Tech and Med-Tech. Secure collaboration and secure sharing are at the core of our solutions.
Videolab is used by top universities, academies and hospitals to put the care in healthcare. Communication skills, empathy and other soft skills are trained by sharing patient interviews recordings for feedback.
SARA is used by top HR-Consultants to deliver team assessments, psychometric tests, 360 degree feedback, cultural analysis and other analytical HR tools.
SAMMY Is a Software Assurance Maturity Model management tool. It enables companies formulate and implement a security assurance program tuned to the risks they are facing. That way other companies can help us build a simple and safe digital future. Obviously our AppSec program and SAMMY itself is built on top of it.
We believe in collaboration and open innovation, we would love to hear about your projects an see how we can contribute in developing secure software and privacy by design architecture. Contact us.