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. Making a detailed plan doesn’t mean that your testing must be elaborate — just that you’re clear and concise about what to do. Given the seriousness of vulnerability and penetration testing, 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 vulnerability and penetration testing is to find the flaws in your systems from the perspective of the bad guys so that you can make your environment more secure. Then you can take this a step further:

• Define more specific goals. Align these goals with your business objectives. Specify what you and management are trying to get from this process and what performance criteria you’ll use to ensure that 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 security testing plan:

• Does your testing support the mission of the business and its IT and security departments?
• What business goals are met by performing this testing? These goals may include the following:
  • Working through Statement on Standards for Attestation Engagements (SSAE) 18 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 (such as 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 you glean 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 you’ll take to get there. 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 (a.k.a covert testingin which you know nothing about the systems you’re testing) or knowledge-based (a.k.a. overt testing in which you’re given specific information about the systems you’re testing, such as IP addresses, host names, usernames, and passwords)?

  I recommend the latter approach.

• Will your testing be technical in nature, involve physical security assessments, or use social engineering?
• Will you be part of a larger security testing 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, and if so, how?

  Customer notification is a critical issue. Many customers appreciate that you’re taking steps to protect their information. Just make sure that you set everyone’s expectations properly.

• How will you know whether customers 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 setting them. These goals are your road map. If you have any concerns, refer to these goals to make sure that you stay on track. You can find additional resources on goal setting and management in the appendix.

Determining Which Systems to Test

After you’ve established your overall goals, decide which systems to test. You may not 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, especially if you’re getting started out. The Pareto principle (focusing on your highest-payoff tasks) should take precedence. You might decide which systems to test based on a high-level risk analysis, answering questions such as these:

• 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 to be most vulnerable to attack?
• Which systems are undocumented, are rarely administered, or are the ones you know the least about?

The following list includes devices, systems, and applications on which you might perform vulnerability and penetration tests:

• Routers and switches
• Firewalls
• Wireless access points
• Web applications (internal, external (hosted locally or inand the cloud)
• Database, email, and file servers
• Mobile devices (such as smartphones and tablets) that store confidential information
• Physical security cameras and building access control systems
• Supervisory control and data acquisition (SCADA) and industrial control systems
• Workstations and servers

The systems you test depend on several factors. If you have a small network, you can test everything. For larger organizations, onsider testing only public-facing hosts such as email and web servers and their associated applications. The security testing process is flexible. Base your decisions on what makes the most business sense or what you’re required to do based on compliance regulations or demands from business partners and customers.

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 (OS) 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 have generated answers to the preceding questions. If so, that documentation can help you identify systems for further testing. Bow Tie and Failure Modes and Effects Analysis (FMEA) are additional approaches.

Vulnerability and penetration testing goes deeper than basic vulnerability scans and higher-level information risk assessments. With proper testing, you might start by gleaning information on all systems — including the organization as a whole — and then further assess the most vulnerable systems. I discuss the vulnerability and penetration testing methodology in Chapter 4.

Another factor that helps you decide where to start is your assessment of the systems that have the greatest visibility. It may make more sense (at least initially) to focus on a database or file server that stores critical client information than to concentrate on a firewall or web server that hosts marketing information, for example.

Creating Testing Standards

One miscommunication or slip-up can send systems crashing during your security testing. 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 to do when a major vulnerability is discovered.

This list is general best practices; you can apply more standards for your situation. The following sections describe these best practices in more detail.

Selecting Security Assessment Tools

Which security assessment tools you need depend on the tests you’re going to run. You can perform some security tests with a pair of sneakers, a telephone, and a basic workstation on the network, but comprehensive testing is easier when you have good, dedicated tools.

The tools I discuss in this book aren’t malware. The tools and even their websites may be flagged as such by certain antimalware and web filtering software, but they’re not malware. I cover only legitimate tools, many of which I’ve used for years. If you experience trouble downloading, installing, or running the tools I cover in this book, 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 —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 list of tools.

It’s important to know what each tool can and can’t do, as well as 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’re familiar with the tools, this precaution can 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. Plenty of them have wasted hours or even days 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, which are often easier to use and typically generate better high-level executive reports. Some commercial tools are expensive, but their ease of use and functionality may justify the initial and ongoing costs. In most situations with security tools, you get what you pay for.