Practical Security Assessment (Penetration Testing) - Assessment Planning
0x??roll
Challenges
- Effective patch management procedures
- Managed system configuration hardening policies
- Multi-layered DMZs
- Centralized security log management
- Host-based security controls
- Network intrusion detection or prevention systems
- Wireless intrusion detection or prevention systems
- Web application intrusion detection or prevention systems
- End user, executive security, and insider threat training
Define the Scope
- Trust but verify: are you sure the clients provide IP addresses of the network they own?
- Discovered something out of scope? Ask the client!
- Rules of engagement
- Determine your deliverables
Good Questions to Ask
- Who has the authority to authorize testing?
- What is the purpose of the test?
- What is the proposed timeframe for the testing? Are there any restrictions as to when the testing can be performed?
- Does your customer understand the difference between a vulnerability assessment and a penetration test?
- Will you be conducting this test with, or without the cooperation of the IT security operations team? Are you testing their effectiveness?
- Is social engineering permitted? How about denial-of-service attacks?
- Are you able to test physical security measures used to secure servers, critical data storage, or anything else that requires physical access? For example, lock picking, impersonating an employee to gain entry into a building, or just generally walking into the areas that the average unaffiliated person should not have access to.
- Are you allowed to see the network documentation or be informed of the network architecture prior to testing to speed things along? (Not necessarily recommended, as this may instill doubt about the value of your findings. Most businesses do not expect this to be an easy information to determine on your own.)
- What are the IP ranges that you are allowed to test against? There are laws against scanning and testing systems without proper permissions. Be extremely diligent when ensuring that these devices and ranges actually belong to your client, or you may be in danger of facing legal ramifications.
- What are the physical locations of the company? This is more valuable to you as a tester if social engineering is permitted because it ensures that you are at the sanctioned buildings when testing. If time permits, you should let your clients know if you were able to access any of this information publicly in case they were under the impression that their locations were secret or difficult to find.
- What to do if there is a problem or if the initial goal of the test has been reached? Will you continue to test to find more entries, or is the testing over? This part is critical and ties into the question of why the customer wants a penetration test in the first place.
- Are there legal implications that you need to be aware of, such as systems that are in different countries and so on? Not all countries have the same laws when it comes to penetration testing.
- Will additional permission be required once a vulnerability has been exploited? This is important when performing tests on segmented networks. The client may not be aware that you can use internal systems as pivot points to delve deeper within their network.
- How are databases to be handled? Are you allowed to add records, users, and so on?
Tools to use
- Kali
- Custom/public scripts
- Recording tools
Data Recording: Magic Tree
Automatically records data and generates reports from:
- Nessus
- Nikto
- Nmap
- Burp
- Qualys
- Imperva Scuba
- OpenVAS
Data Recording: Dradis
Change the template
# cd /usr/lib/dradis/server/vendor/plugins/html_export
# nano template.html.erb