This article, for a change, is not intended for hackers but rather to the CISOs amongst you. As a Chief Information Security Officer you have to endure a longer fight and a very complex array of systems in your organization regardless of the ’8th layer of the OSI model’ – the human layer. This article is intended to provide some advices on some topics you should consider prior to hiring a penetration tester. Since the pentesters’ position is not under regulations or standards, some issues might vary greatly between two contractors.
Basic Background Test
GOOGLE YOUR TESTER! Remember, anyone can call them selves a penetration tester. This contractor is someone whom you are giving the permission to hack your organization and extract sensitive information. Check for articles, publications, communities and every thing you can. If you have a doubt about the individual you can enquire the vendor about replacing the employee for that particular job. If you are not sure about the vendor, feel free to check other vendors.
Time Line
Set your time line up a head. Remember that the most difficult part of the test is not the actual hacking but rather the report writing. This will take some time especially if there are significant findings.
Establish the exact times of the test. You should be aware when you are tested so you can identify real threats from the test itself and act accordingly. Make sure you back up your IT staff while the test is occurring, just in case. Be prepared for malfunctions but remember that they can just occur regardless of the test so don’t be too quick to throw accusations.
A small tip: you might prefer conducting the test at night or over the weekend to avoid work load on servers or just being able to know that you have an entire day to clear up anything that might happen.
Type of Report
Make sure you make a check list for your self on the details you would like to see in the report. Remember that the report is written in a particular way and is not customizable to your preference but some features are. For example, if your native language is different from English, make sure you mention the report’s language prior to the test’s initiation. You might want to point out that you need a readable Executive Summery in Word format since you are going to rewrite it before sending it or presenting it. Do you need a vulnerable machines list after the test?
It is a good idea to ask the tester to see an example report prior to the beginning of the work. See if the report is what you need and if you have any comments or special requests make them prior to the beginning of the work and document them in a check list so that you can verify you have received all of the information you wanted after the report was handed to you. Perhaps you are interested in viewing the log files of your tester and the tools they have worked with. Some vendors would prefer not to disclose this information but you can at least request the information about the log files and more detailed information about the method of attack – “enforcing” that your tester is well documented and organized.
Scope
It is crucial to define a clear scope to the attacker. Here is a list of some of the things you might be interested in considering as a part of the spectrum:
- Which servers are crucial and cannot be tested?
- Which servers are you going to replicate since it’s important to test them but you are not interested in risking them?
- Can denial of service attacks be implemented or tested?
- Can, and if so how and which, changes can be caused to systems?
- Social Engineering attacks can be very successful and many penetration testers prefer using them. Are you interested in SE attacks? How far can it go? Do you allow just phishing and spamming or do you allow phone calls and actual manipulation?
These are just a few examples. Think carefully about what you want tested. The implications of testing a web site, infrastructure, network or entire organization are completely different and the spectrum should be defined with that in mind. For example you can have two companies each testing the entire entity resiliency to cyber attacks and both have the same systems deployed – one can be testing only technologies and IT surfaces while the other is interested in the entire organization’s strength.
Risk Rating
Now that you have the attack surface well define, go and rate your risks. Make sure you have a good list of the systems that are being tested and the implications of compromising their availability or integrity.
Backups
Do you have a proper backup? Remember that even the most ‘stupid’ tests can occur in data corruption. For example; running Acunetix on a web page will fill up automatic forms many times. If these forms list information directly to the database, can you easily separate valid data from invalid data created by the test?
While testing some data might be lost. Mistakes happen and remember that even if the pentester is the one to blame, you are the one who will be held responsible and you will need to clean up after him so make sure you have all your data backed up as close as you can to the initialization of the test on all relevant systems so that you will have an insurance policy. Make sure you have your VMs backed up, your network devices and configurations, storage and servers. Remember that any exploit might have unexpected results.
Coordination & Business Approval
Some tests might lead to degraded performances and systems’ in-availability. This might be a part of the test you do with to proceed. If you are going to conduct tests that might interferer with business availability and work, coordinate it with system administrators and network administration. Also, try to see who is affected by these actions. Make sure you have all appropriate approvals. Sometimes, for certain attack such as Man-In-The-Middle which might cause severe overload on network components and disturb normal work load you might want to coordinate these tests for night times or weekends to make sure you have not causing any co-workers to lose files or lower performance.
Exclusion List
Writing ‘all DB servers’ is not an exclusion list and neither is ‘all personal employees files’. Give your contractor a sorted and valid list for someone who does not know your organization. Provide paths, IP addresses, machines names and servers classes as much as you can to make sure there will be no mix up. Remember that he is now introducing him/her self to all your network at once and with all this new information is needs to be crystal clear what they are not to touch.
Remember also not to write your entire network in the exclusion list for two main reasons; 1st – your tester will not be able to remember all of them and will loose a lot of time going back and forth from the list you have compiled and will probably miss some; 2nd – you will limit your tester’s ability to reach results. Compile a list with all your exclusions but make sure to keep it rational. You may need to define the scope of attack up to a level of subnet or exact IP list to verify that your tester has the exact information of devices to exclude from the attack.
Success Rates
It is a good idea to define what are your pentester’s success rates. Each company has different weak spots and sensitive systems. For some it’s the file server while others only care about the site’s availability while it has no sensitive information. Map your sensitive areas and hand them over to your tester – emphasizing the prof of concepts you wish to see in the report in case of a successful penetration.
About The Author |
||
 |
David (Dudu) Broda |
|
| Doudou is the manager of the Defence Division at See-Security and the head of the Chief Information Security Officer’s program. A well appreciated CISSP, great motivational speaker, a great Information security manager with great knowledge in Governmental Compliance and Regulations and much much more. | ||
 |
Yuval Nativ |
|
| Yuval (tisf) Nativ is the manager of the Cyber Assualt Division of See-Security Technologies. As part of his job he is the manager of the Hacking Defined Experts program, a penetration tester, security researcher and developer. If you like to find him in our offices, just ask where Moriarty is… | ||