Create Test Standards for Your Ethical Hacks
One miscommunication or slip-up in your test standards can send the systems crashing during your ethical hacking tests. No one wants that to happen. To prevent mishaps, develop and document testing standards. These standards should include
When the tests are performed, along with the overall timeline
Which tests are performed
How much knowledge of the systems you acquire in advance
How the tests are performed and from what source IP addresses
What you do when a major vulnerability is discovered
Time your tests
This is especially true when performing ethical hacking tests. Make sure that the tests you perform minimize disruption to business processes, information systems, and people. You want to avoid harmful situations such as miscommunicating the timing of tests and causing a DoS attack against a high-traffic e-commerce site in the middle of the day or performing password-cracking tests in the middle of the night.
Even having people in different time zones can create issues. Everyone on the project needs to agree on a detailed timeline before you begin. Having the team members’ agreement puts everyone on the same page and sets correct expectations.
Your testing timeline should include specific short-term dates and times of each test, the start and end dates, and any specific milestones in between. You can develop and enter your timeline into a simple spreadsheet or Gantt chart, or you can include the timeline as part of your initial client proposal and contract. Your timeline may also be work breakdown structures in a larger project plan.
Run specific tests
You might have been charged with performing a general penetration test, or you may want to perform specific tests, such as cracking passwords or trying to gain access to a web application. Or you might be performing a social engineering test or assessing Windows on the network.
However you test, you might not want to reveal the specifics of the testing. Even when your manager or client doesn’t require detailed records of your tests, document what you’re doing at a high level. Documenting your testing can help eliminate any potential miscommunication.
You might know the general tests that you perform, but if you use automated tools, it may be impossible to understand every test you perform completely. This is especially true when the software you’re using receives real-time vulnerability updates and patches from the vendor each time you run it. The potential for frequent updates underscores the importance of reading the documentation and files that come with the tools you use.
Blind versus knowledge assessments
Having some knowledge of the systems you’re testing might be a good idea, but it’s not required. But, a basic understanding of the systems you hack can protect you and others. Obtaining this knowledge shouldn’t be difficult if you’re hacking your own in-house systems.
If you hack a client’s systems, you might have to dig a little deeper into how the systems work so you’re familiar with them. This doesn’t mean that blind assessments aren’t valuable, but the type of assessment you carry out depends on your specific needs.
The best approach is to plan on unlimited attacks, wherein any test is possible, possibly even including DoS testing.
Consider whether the tests should be performed so that they’re undetected by network administrators and any managed security service providers. Though not required, this practice should be considered, especially for social engineering and physical security tests.
The tests you perform dictate where you must run them from. Your goal is to test your systems from locations accessible by malicious hackers or employees. You can’t predict whether you’ll be attacked by someone inside or outside your network, so cover all your bases. Combine external tests and internal tests.
You can perform some tests, such as password cracking and network-infrastructure assessments, from your office. For external hacks that require network connectivity, you might have to go off-site or use an external proxy server. Some security vendors’ vulnerability scanners are run from the cloud, so that would work as well.
Better yet, if you can assign an available public IP address to your computer, simply plug in to the network on the outside of the firewall for a hacker’s-eye view of your systems. Internal tests are easy because you need only physical access to the building and the network. You might be able to use a DSL line or cable modem already in place for visitors and similar users.
Respond to vulnerabilities you find
Determine ahead of time whether you’ll stop or keep going when you find a critical security hole. You don’t need to keep hacking forever or until you crash all the systems. Just follow the path you’re on until you just can’t hack it any longer. When in doubt, the best thing to do is to have a specific goal in mind and then stop when that goal has been met.
If you discover a major hole, contact the right people as soon as possible so that they can begin fixing the issue right away. The right people may be software developers, product or project managers, or even CIOs. If you wait a few days or weeks, someone might exploit the vulnerability and cause damage that could’ve been prevented.
You’ve heard about what you make of yourself when you assume things. Even so, you make assumptions when you hack a system. Here are some examples of those assumptions:
Computers, networks, and people are available when you’re testing.
You have all the proper testing tools.
The testing tools you use will minimize the chances of crashing the systems you test.
You understand the likelihood that existing vulnerabilities were not found or that you used your testing tools improperly.
You know the risks of your tests.
Document all assumptions and have management or your client sign off on them as part of your overall approval process.