Managing Technical Security Testing - part 5: test execution
Kick-off
The kick-off is the checkpoint verify if all arrangements have been made, like the SPoCs are briefed and available, the restrictions are clear, all contractual issues have been solved, NDAs are ok, test access is set-up, tested and ready to be used, test accounts are set-up, …
Assign a single point of contact (SPoC)
The first action is to establish a (SPoC) for both the organizing team and the testing team. Both need to give priority to any calls/texts/emails from the other SPoC. They might find themselves in a race with incident responders.
Review of the testing parameters
- Excluded tests are highlighted (typically: availability attacks are excluded)
- The SPoC information is double checked.
- The content SoW is briefly presented.
- The incident reporting procedure is reviewed.
- Practical arrangement are reviewed:
- physical access if required
- facilities that are available
- site restrictions
- …
Secure information exchange
During most type of tests confidential and even secret information, like credentials and vulnerability reports, may have to be exchanged. If the tester is of the same organization there will be solutions for that. In between organizations it is more difficult to agree: both parties may have solutions they prefer to use.
Information is delivered according to the type of test:
- Target information: the provided content depends on white box, gray box, black box (multiple possible with time delays)
- Test credentials, probably multiple
- 1 per role
- consider a secondary if the prime one gets blocked
- Authorization model
- Key operations
- Connectivity requirements
Things that go wrong
During the test execution the SPoCs of the organization and of the pentest team must be able to reach each other quickly. Things can go wrong despite careful preparation.
The test targets are defined and other systems are out of scope. Unfortunately, it is easy to step outside of the agreed environment.
- The connectivity solution may be shared with other systems and collateral damage may occur
- While deliberate denial-of-service is excluded, security testing walks outside of the usual and may break the targets or systems used to test the targets
- Web pages can contain links to any other page, so while spidering for instance, leaving the targets is easily done
- The underlying database may be corrupted due to the tests, by SQL injection or otherwise
- The authentication and authorization systems might be shared with other set-ups or even production, as managing access in development or test might be considered important enough to use the general IAM solutions
- Tests usually generate lots of logs and may trigger monitoring alert. The logs might get full and that impacts other systems. The monitoring might get overloaded with security events.
- Getting a locked account is business as usual when pentesting. The support team may not like to have to reset the test accounts every 5 minutes.
- Using a pentest laptop on the organizations network may generate traffic to the outside that is blocked by DLP systems, or as other malicious traffic going out.
- (every pentester can extend this list)
If resolving any of these issues takes too long, the time box gets shorter and less confidence in the test outcome may be the result.
High risk reporting
Whenever pentesters find high risk items (according to their evaluation scheme) they must immediately report it. The issue might have been pre-existing the change, meaning it is in the live version. Even if it is not, it is best to continue investigating the impact and the possible fixes as a high priority finding blocks going into production.
Monitoring actions
A pentest can also be used as a test on the detective measures of the organization. As the whole pentest is one big attempt to break in, lots of monitoring events should be triggered and logs should be created. Checking if the logs and events are indeed catching what has happened should be included in the pentest review.
Preliminary data
The accountable and responsible people always like to get an preview of what to expect: how many things have been found, and will there be findings delaying their release?
The severity ratings may still shift after careful consideration and be different in the report. More important, the adaption to the corporate context can modify the outcome too. For these reasons, the preliminary data may be confined to the CISO team.