If you think the Rules of Engagement sound like a war movie, you’re not alone. In the penetration testing world, it’s more about cyber warfare, indirectly.
Proactive penetration testing can help combat would-be attackers by identifying for vulnerabilities before they do. The Rules of Engagement, or ROE, is a document that any reputable penetration testing company should put in place before testing begins.
The Rules of Engagement define the scope, or limits, of the testing to be performed. This can include the dates and times that testing will be performed, what IP addresses the tester will be using to conduct the tests, and what devices or web applications will be in scope, specifically identified by IPs and urls. The ROE may also include a list of IPs or hostnames that off limits, or out of scope.
The Rules of Engagement should have the penetration tester’s contact information or someone who can directly assist you during testing. There may be times where you will want to speak with the tester, especially if things are transpiring on your network during the active testing.
This happened to a client of MainNerve’s. The client was scheduled for their annual penetration testing and their internet line was not up and running (most likely a fiber cut from construction). The client called to see if it was from MainNerve testing, but our tester hadn’t engaged yet.
The Rules of Engagement provides information on how the tester will communicate with your team. MainNerve testers will always reach out before testing to ensure that your team is aware he or she will be actively engaging your systems. Additionally, if there are any high or critical vulnerabilities, you will be notified immediately.
There should be a game plan as to what will transpire with the data discovered during testing, and a listed project schedule secondary to multi-day testing. The ROE should also define the methodology, or approach, employed during testing, such as black box, grey box, or white box.
The importance of Rules of Engagement cannot be overstated. They define what is to be tested, how it is to be tested, and when it is to be tested. They identify the testers and give you a clear line of communication to them, and they to you. They give clear limits and requirements to ensure that the systems and services you need to be tested are tested and that any systems you do not want tested are not.
