Chapter 3
In This Chapter
Setting security testing goals
Selecting which systems to test
Developing your testing standards
Examining hacking tools
As an information security professional, you must plan your security assessment efforts before you start. A detailed plan doesn’t mean that your testing must be elaborate. It just means that you’re clear and concise about what to do. Given the seriousness of ethical hacking, you should make this process as structured as possible.
Even if you test only a single web application or workgroup of computers, be sure to take the critical steps of establishing your goals, defining and documenting the scope of what you’ll be testing, determining your testing standards, and gathering and familiarizing yourself with the proper tools for the task. This chapter covers these steps to help you create a positive environment so you can set yourself up for success.
You can’t hit a target you can’t see. Your testing plan needs goals. The main goal of ethical hacking is to find vulnerabilities in your systems from the perspective of the bad guys so you can make your environment more secure. You can then take this a step further:
The following questions can start the ball rolling when you define the goals for your ethical hacking plan:
After you know your goals, document the steps to get there. For example, if one goal is to develop a competitive advantage to keep existing customers and attract new ones, determine the answers to these questions:
Will you notify the affected parties of what you’re doing and when you’re doing it? If so, how?
Customer notification is a critical issue. Many customers appreciate that you’re taking steps to protect their information. Approach the testing in a positive way. Don’t say, “We’re breaking into our own systems to see what information is vulnerable to hackers,” even if that’s what you’re doing. Instead, say that you’re assessing the overall security of your network environment so the information will be as secure as possible.
Establishing your goals takes time, but you won’t regret it. These goals are your road map. If you have any concerns, refer to these goals to make sure that you stay on track. Additional resources on goal setting and management can be found in the Appendix.
After you’ve established your overall goals, decide which systems to test. You probably don’t want — or need — to assess the security of all your systems at the same time. Assessing the security of all your systems could be quite an undertaking and might lead to problems. I’m not recommending that you don’t eventually assess every computer and application you have. I’m just suggesting that whenever possible, you should break your projects into smaller chunks to make them more manageable. You might decide which systems to test based on a high-level risk analysis, answering questions such as
The following list includes devices, systems, and applications that you may consider performing your hacking tests on:
What specific systems you should test depends on several factors. If you have a small network, you can test everything. Consider testing just public-facing hosts such as e-mail and web servers and their associated applications. The ethical hacking process is flexible. Base these decisions on what makes the most business sense.
Start with the most vulnerable systems and consider these factors:
A previous security risk assessment, vulnerability test, or business impact analysis may already have generated answers to the preceding questions. If so, that documentation can help identify systems for further testing. Bow Tie and Failure Modes and Effects Analysis (FMEA) are additional approaches.
Another factor that will help you decide where to start is to assess the systems that have the greatest visibility. For example, focusing on a database or file server that stores client or other critical information may make more sense — at least initially — than concentrating on a firewall or web server that hosts marketing information about the company.
One miscommunication or slip-up 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
This is a list of general best practices — you can apply more standards for your situation. The following sections describe these general best practices in more detail.
They say that it’s “all in the timing.” This is especially true when performing security 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 denial of service (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. It’s amazing what a 12-hour time difference (2 p.m. during major production versus 2 a.m. during a slower period) can make when testing your systems! 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 in a larger project plan. A timeline such as the following keeps things simple and provides a reference during testing:
Test Performed |
Start Time |
Projected End Time |
Web application vulnerability scanning |
July 1, 21:00 |
July 2, 07:00 |
OS vulnerability scanning |
July 2, 10:00 |
July 3, 02:00 |
OS vulnerability exploitation |
July 3, 08:00 |
July 3, 17:00 |
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 and keep you out of hot water. It might also be needed as evidence should you uncover malfeasance.
Sometimes, you might know the general tests that you perform, but if you use automated tools, it may be next to 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 readme files that come with the tools you use.
An updated program once bit me. I was performing a vulnerability scan on a client’s website — the same test I performed the previous week. The client and I had scheduled the test date and time in advance. But I didn’t know that the software vendor made some changes to its web form submission tests, and I accidentally flooded the client’s web application, creating a DoS condition.
Luckily, this DoS condition occurred after business hours and didn’t affect the client’s operations. However, the client’s web application was coded to generate an e-mail for every form submission and there was no CAPTCHA on the page to limit successive submissions. The application developer and company’s president received 4,000 e-mails in their inboxes within about 10 minutes — ouch!
My experience is a perfect example of not knowing how my tool was configured by default and what it would do in that situation. I was lucky that the president was tech-savvy and understood the situation. Remember to have a contingency plan in case a situation like mine occurs. Just as important, set people’s expectations that trouble can occur — even when you’ve taken all the right steps to ensure everything’s in check.
Having some knowledge of the systems you’re testing is generally the best approach, but it’s not required. Having a basic understanding of the systems you hack can protect you and others. Obtaining this knowledge shouldn’t be difficult if you’re testing your own in-house systems. If you’re testing a client’s systems, you might have to dig a little deeper into how the systems work so you’re familiar with them. Doing so has always been my practice and I’ve only had a small number of clients ask for a full blind assessment because most people are scared of 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 fair game, possibly even including DoS testing. The bad guys aren’t poking around on your systems within a limited scope, so why should you?
Consider whether the tests should be performed so that they’re undetected by network administrators and any managed security service providers or related vendors. Though not required, this practice should be considered, especially for social engineering and physical security tests. I outline specific tests for those subjects in Chapters 6 and 7.
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 insiders. You can’t predict whether you’ll be attacked by someone inside or outside your network, so cover all your bases as much as you can. Combine external (public Internet) tests and internal (private LAN) tests.
You can perform some tests, such as password cracking and network infrastructure assessments, from your office. For external tests that require network connectivity, you might have to go offsite (a good excuse to work from home), use an external proxy server, or simply use guest Wi-Fi. Some security vendors’ vulnerability scanners can even be 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 guest access.
Determine ahead of time whether you’ll stop or keep going when you find a critical security hole. You don’t need to keep testing forever. Just follow the path you’re on until you’ve met your objectives or reached your goals. 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.
Having said this, if you discover a major hole, I recommend contacting 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 test your systems. Here are some examples of those assumptions:
Document all assumptions. You won’t regret it.
Which security assessment tools you need depend on the tests you’re going to run. You can perform some ethical hacking tests with a pair of sneakers, a telephone, and a basic workstation on the network, but comprehensive testing is easier with good, dedicated tools.
It’s important to know what each tool can and can’t do and how to use each one. I suggest reading the manual and other Help files. Unfortunately, some tools have limited documentation, which can be frustrating. You can search forums and post a message if you’re having trouble with a tool.
If you’re like me, you may despise some freeware and open source security tools. There are plenty that have wasted hours of my life that I’ll never get back. If these tools end up causing you more headaches than they’re worth, or don’t do what you need them to do, consider purchasing commercial alternatives. They’re often easier to use and typically generate better high-level executive reports. Some commercial tools are expensive to acquire, but their ease of use and functionality often justify the initial and ongoing costs. In most situations with security tools, you get what you pay for.
18.191.14.196