Close Widget

By SureCloud’s Martin Ellis, Senior Cybersecurity Consultant.

So, you have booked your first test, and now you are wondering what you should be prepared for?  


In this blog, we will talk about… 

  1. The sort of traffic you are likely to see from your testing provider
  2. How this might affect you
  3. The choices you make around testing

We will be looking at this from the point of view of a web application test, but many of the themes apply to infrastructure testing as well. These points all need to be caveated with that they cover the general case and may not cover all cases you have agreed to during scoping. 


What might I expect during testing? 

In this section, we are going to briefly discuss some of the common things we have seen clients struggle with or were not expecting during testing.  

Levels of traffic

During testing you are likely to see a lot of traffic; for some clients, this may be far more traffic than your site is used to seeing, and may include requests that a real user is unlikely to try repeatedly. That single slow request that isn’t an issue because users only call it once might suddenly be being called hundreds of times. What you should remember is that this is not a load test; the testers are not trying to crash your site through traffic. If you are seeing slowdown with your website that is affecting other users, reach out to your tester and ask them to slow down testing in general or inform them of specific requests that are causing issues.

There are a few things you should consider before testing that may help with the above. Can you recover the site quickly if there is an issue? SureCloud would recommend testing how long it takes to recover from a host failing under load. In the unlikely event that a server fails due to traffic during a test, is this downtime acceptable to you?

It should also be noted that the traffic from the testers is likely to be intermittent because testing features of applications produces a large amount of data that your testers will have to process. You are likely to see a large influx of traffic as the testers investigate a feature, followed by lulls in traffic as they process the responses; this is normal and should be expected as good testing has a large amount of manual work and review.

The final takeaway is that if a tester can take down your website or application, it is highly likely that an attacker can too, and an attacker will have the ability to direct far more traffic at you than your testers are using.


Types of traffic

Your testers will be throwing traffic at your application that it is unlikely to have seen before because how an application handles unexpected traffic and requests will help them to determine if it has any security vulnerabilities. This traffic will be trying to find bugs in both your infrastructure and application logic and will include malformed requests at all levels of the messages.

This is likely to produce a lot of logging information; this is normal. Depending on the application, you may also receive messages that can trigger virus alerts, which is also to be expected. Where possible SureCloud recommends implementing specific filtering of logging coming from your testers source addresses. This information should not be thrown away, as it may contain valuable information to help diagnose issues discovered during testing; instead, it should be reviewed, and by filtering the logs from your usual logs you will help prevent testing masking real issues affecting real clients of the application.

If you do see traffic that you are concerned about, first check the source of the traffic to see if it is coming from your testers, and then reach out to them. They will be able to explain what was happening at the time and may be able to clarify things for you.
It should be noted as well that unless otherwise specified it is usual for other services exposed to the internet from your web application server to also be in scope. If this is something, you explicitly don’t want this should be agreed with your testers during the scoping phase.

Subscribe below to get alerted about part 2 of this blog – we continue to look at the different elements you should prepare for including requests from your testers and what to do if something goes wrong.

How can we help?