How does the red team go about conducting a test?
Let’s say we’re testing an app. The first steps we take are to talk to the specialists who develop, operate or refine the app and to define the goals of our testing. One such goal can be to manipulate a financial transaction in a test environment, or to get our hands on information via an interface within the app. We then determine the approach we want to take – the black box, grey box or white box approach. With the black box approach, we’re given access to the application for testing with no further information about its internal structure. With the grey box approach – which is much more common – we get a little more support, by being able to work with a version in which some protective measures are switched off, for example. This gives us an edge over potential attackers, who generally have more time on their hands than we do, and the ability to use our valuable testing time for actual testing rather than for circumventing security measures. Or you can go one step further with the white box approach, where the source code is available to us, making it easier for us testers to circumvent the protective measures. We then arrange the test setup and get to work. We test aspects such as app authentication, the login procedure or the resetting of passwords for logical errors and deviations from standards. Or we observe how the app behaves when we feed it with information for which it was not actually intended. For example, if a payment from customer A to customer B runs through 10 steps in the background, we look to see what happens if we change the content or the order of the steps. Once we’ve tested enough starting points of this kind, we draw our conclusions and document them. Where necessary, measures are then taken to eliminate the identified vulnerabilities.