Slides Link
Background
In week 1 of RVAPT, the group have went over the Pre-Engagement phase of the penetration testing. There was a clear reason why RVAPT started off with non-technical, a bit "boring" side of Offensive Security. This is because Pre-Engagement is essential in the life cycle of penetration testing. Acknowledging different aspects of Pre-Engagement is crucial in understanding the big-picture of the engagement, as well as not breaking the contract/law.
What is Pre-Engagement?
Pre-Engagement is any kind of interaction between the client and the service provider, prior to the actual engagement. This is done in order to set the big-picture of the engagement. Establishing identical terminologies, setting up expectations, acknowledging purpose of the engagement, defining the scope and rules of engagement all falls under the Pre-Engagement phase. If you did not understand some of the phrases, do not worry, as this post will contain all of the information regarding those.
The Topics
For the actual process of Pre-Engagement, the following phases were covered during the presentation:
- Request for Proposal / Response for Proposal
- Scope of Work
- Rules of Engagement
As I do not have professional experience, I can not say for sure that these documents are the only ones used for Pre-Engagement. I'm sure there are much more legal documents to go over. However, from an technical operator's point of view, these are the most important documents to understand before jumping into the engagement.
Another important point to make is that documents are not the only media used for Pre-Engagement. There could be meetings (remote or in-person), phone calls, or any sort of communication back and forth between the client and the service provider before the engagement starts. However, as those vary a lot depending on the person, agenda of the meeting, and the details, RVAPT presentation only focused on the documents, which are solidified and has some kind of a template to follow.
So, let's dive in.
Request for Proposal
Request for Proposal is a document which the client sends out / publishes to request for an engagement. The document will have some basic information about the engagement, and the service providers will contact the client if they are interested in getting a contract. As we read through, make sure to take extra focus on the overview, purpose, scope, timeline, and the point of contact written in the document. It's important for us to know what we are getting into before the engagement happens.
As service providers, we would send a "Response for Proposal" back to the client. Response for Proposal would include some of the overview, team credentials, assessment plan, and some information regarding payment/financials.
Chances are, Request for Proposal and Response to Proposal would be done through the "higher-ups" such as project manager or the sales team. However, the operators should also at least take a look at these documents as they provide the context of the engagement.
Scope of Work
Scope of Work is a section of a document in Request for Proposal and/or Rules of Engagement which details the targets that should be tested during the engagement. Usually, this will be in the form of IP addresses, subnet in CIDR, or hostnames. The general rule of thumb for the Scope of Work is that service providers should only test the targets that are within the scope.
In short, anything outside of the scope is lava. The service provider should not interact with it in any ways, no matter the reason.
There could be some complex situations however, where interacting with a target outside of scope is necessary. One example of this could be a web server (in-scope) is communicating with a database server that is out of scope. In this case, in order to prove that the web server is vulnerable to SQL injection, the operator needs to interact with the database server, as the webserver itself is sending a SQL query to the database server.
If there are circumstances where the scope is not defined clearly, or there might be edge cases, Pre-Engagement is the best phase to simply ask the client for clarification. Formally, this would be done through a phase called "Request for Information". Informally, an operator should always ask for clarification to one of the seniors, team lead, or the point of contact.
Rules of Engagement
If Scope of Work defines what targets to test, Rules of Engagement defines what kind of behaviors the service provider is allowed and disallowed to do during the engagement. This is where the Pre-Engagement phase gets a bit more technical as well.
For the technical details, the RoE would include testing methods, testing tools, constraints, notification and disclosure process, and Request for Information to the client. Request for Information is a document where service provider asks the clients for various details. Though RoE and RFI, finer technical details gets agreed between the client and the service provider.
Usually Rules of Engagement gets iterated couple of times as the service provider sends out Request for Information to the client.
Conclusion & Further Research
From Request for Proposal to Scope of Work, and Rules of Engagement, we have covered some of the crucial phases of Pre-Engagement. By now, you might have some vague idea of what is going on, but might lack a clear example of these.
A great example of Pre-Engagement documents can be actually found online, by googling.