Chapter 3
Developing Your Ethical Hacking Plan
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.
Establishing Your Goals
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:
- Define more specific goals. Align these goals with your business objectives. What are you and the management trying to get from this process? What performance criteria will you use to ensure you’re getting the most out of your testing?
- Create a specific schedule with start and end dates as well as the times your testing is to take place. These dates and times are critical components of your overall plan.
Before you begin any testing, you absolutely, positively need everything in writing and approved. Document everything and involve management in this process. Your best ally in your testing efforts is a manager who supports what you’re doing.
The following questions can start the ball rolling when you define the goals for your ethical hacking plan:
- Does your testing support the mission of the business and its IT and security departments?
- What business goals are met by performing ethical hacking? These goals may include the following:
- Working through Statement on Standards for Attestation Engagements (SSAE) 16 audits
- Meeting federal regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the Payment Card Industry Data Security Standard (PCI DSS)
- Meeting contractual requirements of clients or business partners
- Maintaining the company’s image
- Prepping for the internationally accepted security standard of ISO/IEC 27001:2013
- How will this testing improve security, IT, and the business as a whole?
- What information are you protecting? This could be personal health information, intellectual property, confidential client information, or employees’ private information.
- How much money, time, and effort are you and your organization willing to spend on security assessments?
- What specific deliverables will there be? Deliverables can include anything from high-level executive reports to detailed technical reports and write-ups on what you tested, along with the outcomes of your tests. You can deliver specific information that is gleaned during your testing, such as passwords and other confidential information.
- What specific outcomes do you want? Desired outcomes include the justification for hiring or outsourcing security personnel, increasing your security budget, meeting compliance requirements, or enhancing security systems.
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:
- When will you start your testing?
- Will your testing approach be blind, in which you know nothing about the systems you’re testing, or knowledge-based, in which you’re given specific information about the systems you’re testing, such as IP addresses, hostnames, and even usernames and passwords? I recommend the latter.
- Will your testing be technical in nature, involve physical security assessments, or even use social engineering?
- Will you be part of a larger ethical hacking team, sometimes called a tiger team or red team?
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.
- How will you know whether customers even care about what you’re doing?
- How will you notify customers that the organization is taking steps to enhance the security of their information?
- What measurements can ensure that these efforts are paying off?
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.
Determining Which Systems to Hack
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
- What are your most critical systems? Which systems, if accessed without authorization, would cause the most trouble or suffer the greatest losses?
- Which systems appear most vulnerable to attack?
- Which systems crash the most?
- Which systems are not documented, are rarely administered, or are the ones you know the least about?
The following list includes devices, systems, and applications that you may consider performing your hacking tests on:
- Routers and switches
- Firewalls
- Wireless access points
- Web applications (both internal and hosted in the cloud)
- Application and database servers
- E-mail and file servers
- Mobile devices (such as phones and tablets) that store confidential information
- Physical security cameras and access control systems
- SCADA and industrial control systems
- Workstation and server operating systems
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:
- Whether the computer or application resides on the network or in the cloud
- Which operating system and application(s) the system runs
- The amount or type of critical information stored on the system
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.
Ethical hacking goes a few steps deeper than higher-level information risk assessments and, especially, vulnerability scans. With ethical hacking, you often start by gleaning information on all systems — including the organization as a whole — and then further assessing the most vulnerable systems. But again, this process is flexible. I discuss the ethical hacking methodology in Chapter 4.
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.
Creating Testing Standards
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
- 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 (if performed via an external source via the Internet)
- What you do when a major vulnerability is discovered
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.
Timing
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.
If possible and practical, notify your Internet service providers (ISPs), cloud service providers, or hosting collocation (colo) providers. These companies have firewalls or intrusion prevention systems (IPS) in place to detect malicious behavior. If your provider knows you’re conducting tests, it’s less likely to block your traffic.
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 |
Running 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 and keep you out of hot water. It might also be needed as evidence should you uncover malfeasance.
Enabling logging on the systems you test along with the tools you use can provide evidence of what and when you test and more. It may be overkill, but you could even record screen actions using a tool such as TechSmith’s Camtasia Studio (www.techsmith.com/camtasia.html).
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.
Blind versus knowledge assessments
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.
If too many insiders know about your testing, they might create a false sense of vigilance by improving their habits, which can end up negating the hard work you put into the testing. This doesn’t mean you shouldn’t tell anyone. It’s almost always a good idea to inform the owner of the system who may not be your sponsor. Always have a main point of contact — preferably someone with decision-making authority.
Picking your location
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.
Responding 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 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.
If you don’t have goals, how are you going to know when you arrive at your security testing destination?
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.
Making silly assumptions
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:
- All of the computers, networks, applications, 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. You won’t regret it.
Selecting Security Assessment Tools
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.
The tools discussed in this book are not malware. The tools and even their websites may be flagged as such by certain anti-malware and web filtering software but they’re not. The tools I cover are legitimate tools — many of which I have used for years. If you experience trouble downloading, installing, or running the tools I cover in this book, you may consider configuring your system to allow them through or otherwise trust their execution. Keep in mind that I can’t make any promises. Use checksums where possible by comparing the original MD5 or SHA checksum with the one you get using a tool such as CheckSum Tool (http://sourceforge.net/projects/checksumtool). A criminal could always inject malicious code into the actual tools, so there’s no guarantee of security. You knew that anyway, right?
If you’re not sure what tools to use, fear not. Throughout this book I introduce a wide variety of tools — both free and commercial — that you can use to accomplish your tasks. Chapter 1 provides a list of commercial, freeware, and open source tools. The Appendix contains a comprehensive listing of tools for your reference.
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.
Security vulnerability scanning and exploit tools can be hazardous to your network’s health. Be careful when you use them. Always make sure that you understand what every option does before you use it. Try your tools on test systems if you’re not sure how to use them. Even if you are familiar with them, this precaution can help prevent DoS conditions and loss of data on your production systems.
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.