1. What is Penetration Testing?

Penetration testing is the exploitation of vulnerabilities present in an organization’s network. It helps determine which vulnerabilities are exploitable and the degree of information exposure or network control that the organization could expect an attacker to achieve after successfully exploiting a vulnerability. No penetration test is or ever can be “just like a hacker would do it,” due to necessary limitations placed on penetration tests conducted by “white hats.” Hackers don’t have to follow the same rules as the “good guys” and they could care less whether your systems crash during one of their “tests.” We’ll talk more about this later. Right now, before we can talk any more about penetration testing, we need to talk about various types of vulnerabilities and how they might be discovered.

Before we can exploit a vulnerability in a penetration test, we have to discover what vulnerabilities exist within (and outside of) the organization. A vulnerability is a potential weakness in an organization’s security. I use the term “potential” because not all vulnerabilities are exploitable or worth exploiting. A flaw may exist and may even be documented, but perhaps no one has figured out (yet) how to exploit it. Some vulnerabilities, although exploitable, might not yield enough information in return for the time or resources necessary to exploit them. Why break into a bank and steal only a dollar? That doesn’t make much sense, does it?

Vulnerabilities can be thought of in two broad categories: logical and physical. We normally think of logical vulnerabilities as those associated with the organization’s computers, infrastructure devices, software, or applications. Physical vulnerabilities, on the other hand, are normally thought of as those having to do with either the actual physical security of the organization (such as a door that doesn’t always lock properly), the sensitive information that “accidentally” ends up in the dumpster, or the vulnerability of the organization’s employees to social engineering (a vendor asking to use a computer to send a “quick email” to the boss).

Logical vulnerabilities can be discovered using any number of manual or automated tools and even by browsing the Internet. For those of you who are familiar with Johnny Long’s Google Hacking books: “Passwords, for the love of God!!! Google found passwords!” The discovery of logical vulnerabilities is usually called security scanning, vulnerability scanning, or just scanning. Unfortunately, there are a number of “security consultants” who run a scan, put a fancy report cover on the output of the tool, and pass off these scans as a penetration test.

Physical vulnerabilities can be discovered as part of a physical security inspection, a “midnight raid” on the organization’s dumpsters, getting information from employees, or via unaccompanied access to a usually nonpublic area (I really need to use the bathroom!).

Vulnerabilities might also exist due to a lack of company policies or procedures or an employee’s failure to follow the policy or procedure. Regardless of the cause of the vulnerability, it might have the potential to compromise the organization’s security. So, of all the vulnerabilities that have been discovered, how do we know which ones pose the greatest danger to the organization’s network? We test them! We test them to see which ones we can exploit and exactly what could happen if a “real” attacker exploited that vulnerability.

Because few organizations that I know of have enough money, time, or resources to eliminate every vulnerability discovered, they have to prioritize their efforts; this is one of the best reasons for an organization to conduct a penetration test. At the conclusion of the penetration test, they will know which vulnerabilities can be exploited and what can happen if they are exploited. They can then plan to correct the vulnerabilities based on the amount of critical information exposed or network control gained by exploiting the vulnerability. In other words, a penetration test helps organizations strike a balance between security and business functionality. Sounds like a perfect solution, right? If only it were so!

There are organizations that do not care about the “true risks” that their organizations face. Instead, they are more interested in being able to tell their shareholders or their regulating agencies that they’ve conducted a penetration test and “passed” it. If the penetration test is structured so that only certain systems are tested, or if the test is conducted during a known timeframe, the test results will be favorable to the organization, but the test isn’t a true reflection of its network security posture. This kind of “boutique testing” can lead to a false sense of security for the organization, its employees, and its stakeholders.

2. How does Penetration Testing Differ from an Actual “Hack?”

Earlier, I mentioned that penetration testing isn’t and never can be “just like a hacker would do it.” How come? Except in the case of “directed” sabotage or espionage, it’s not personal between your organization and attackers. They don’t care who you are, where you are, or what your organization does to earn its living. They just want to hack something. The easier it is to attack your network, the more likely it is that you’ll be a target. Ask your network administrator to look at the network intrusion detection logs (or look at them yourself if you’re a network admin). See how many times in a 24-hour period your organization’s network gets scanned for potential vulnerabilities.

Once an attacker has decided that you’re his or her (yes, there are female hackers—good ones, too!) next target, they may take weeks or months to perform the first step of an attack: reconnaissance. As a penetration tester or company providing penetration testing services, I doubt that you’re going to get hired to spend six months doing reconnaissance and another couple of months conducting an attack. So, the first difference between a penetration test and a real attack is the length of time taken to conduct all the activities needed to produce a successful outcome. As “good guys,” we don’t have the luxury of time that the “bad guys” do. So we’re handicapped to begin with.

In some (not all) cases, once attackers find a suitable vulnerability to attack, they will. They don’t care that the vulnerability resides on a mission-critical system, if the vulnerability will crash the system, or that the system might become unusable in the middle of the busiest time of day. If that vulnerability doesn’t “pan out,” they find another and try again. They keep it up until they run out of vulnerabilities that they can exploit, or they’re discovered, or they manage to successfully breach the network or crash the system. Penetration test teams normally don’t have this luxury, either. Usually the test team has X amount of time to find a vulnerability and get in or the test is over and the network is declared “safe and secure.” If the test team didn’t have enough time to test all the vulnerabilities—oh, well. The test is still over, they still didn’t get in, and so our network must be safe! Few seem to think about the fact that a “real” attacker may, just by blind luck, choose one of the unable-to-be-tested-because-of-time-limitations vulnerabilities and be able to waltz right into the network without being detected.

Some systems are declared “off limits” to testing because they’re “too important to have crash” during a test. An organization may specify that testing can only occur during certain hours or on certain days because of a real or perceived impact on business operations. This is the second difference between a penetration test and a real attack: Hackers don’t play by any rules. They attack what they want when they want and how they want. Just to be clear: I’m not advocating denial-of-service testing during the busiest time of an organization’s day, or unrestricted testing at any time. I’m just trying to make a point that no system is too critical to test. From a hacker’s perspective, there are no “off-limits” systems, just opportunities for attack. We’ll talk more about differences between real attacks and penetration tests when we talk about the various types of testing in the next section.

3. Types of Penetration Testing

Some sources classify penetration testing into two types—internal and external—and then talk about the “variations” of these types of tests based on the amount of information the test team has been given about the organization prior to starting the test. Other sources use a reverse-classification system, typing the penetration test based on the amount of information available to the test team and then the location from which the test is conducted. I much prefer the latter method, since it removes any chance of misunderstanding about what testing is going to be conducted where. Warning: If you’re planning to take the CISSP or some of the other network security certification examinations, stick with the “old skool” “classification by location, then type” definitions for penetration testing types and variations.

When a penetration test is conducted against Internet-facing hosts, it is known as external testing. When conducted against hosts inside the organization’s internal network, it is known as internal testing. Obviously, a complete penetration test will encompass testing of both external and internal hosts. The “variations” of penetration tests are normally classified based on how much information the test team has been given about the organization. The three most commonly used terms for penetration types are white-box, gray-box, and black-box testing. Before we talk about these penetration testing variations, you need to understand that we can conduct any of them (white, gray, or black) either externally or internally. If we want a complete test, we need to test both externally and internally. Got it? Good! Now we can talk about what is involved with each type of testing.

We’ll start with white-box testing. The “official” definition of white-box testing usually includes verbiage about providing information so as to be able to assess the security of a specific target or assess security against a specific attack. There are several problems with this definition in real life. The first is that it sounds as though you would only conduct a white-box test if you were looking to verify the security of one specific host or looking to verify the security of your network against one specific attack. But it would be foolhardy to test for only one vulnerability. Since the “variations” we’re talking about are supposed to be centered on the amount of information available to the test team, let’s look at a white-box test from an information availability perspective.

Who in your organization knows the most about your network? Probably the network administrator. Any organization that has recently terminated employment of a network administrator or member of the IT Department under less than favorable circumstances has a big problem. There is the potential that the organization’s network could be attacked by this former employee who has extreme knowledge about the network. In a white-box test, therefore, the test team should be given about the same amount of information that a network administrator would have. Probably the team won’t be given passwords, but they’ll be given network ranges, topologies, and so on.

Gray-box testing, by “official” definition, provides “some” knowledge to the test team, about the sort of thing a normal, unprivileged user might have: hostnames, maybe a few IP addresses, the fact that the organization allows senior management to “remote” into the network, and so on. Common, though not necessarily public, knowledge about the “inner workings” of the organization’s network is the level of information provided to the test team. Some sources claim that this testing type (as well as the information disclosed in a white-box test) “puts the tester at an advantage” over an attacker because the test team possesses information that an attacker wouldn’t have. But that’s not necessarily the case. Any organization that has terminated a “normal user” has the potential for an attack based on that user’s inside knowledge of the network.

Now let’s talk about everyone’s favorite: black-box penetration testing. Again, we’ll start with the common definition, which usually says something like “provides the test team with little or no information except for possibly the company name.” The test team is required to obtain all their attack information from public sources such as the Internet. There’s usually some sentence somewhere in the description that says how a black-box test is always much better than any other type of test because it most closely mimics the way an attacker would conduct an attack. The definition might be right (and I might even be inclined to agree with it) if the organization has never terminated a network admin or any other employee with network access. I might also be more in agreement with this train of thought if the majority of attacks were conducted by unknown persons from the far reaches of the globe instead of former employees or currently employed “insiders”!

Depending on what article or book you happen to be reading at the time, you might also see references to application penetration testing, Web penetration testing, shrink-wrap penetration testing, wireless penetration testing, telephony penetration testing, Bluetooth penetration testing . . . and the list goes on. I’ve seen every possible device in a network listed as a separate penetration test. The bottom line is that if it’s present in the network, an organization needs to discover what vulnerabilities exist on it and then test those vulnerabilities to discover what could happen if they’re successfully exploited.

I guess since Morgan Kaufmann asked me to write this chapter, I can give you my opinion: I don’t like black-box penetration testing. I don’t want any network of mine tested “just like a hacker would do it.” I want my network tested better than any hacker ever could, because I don’t want to end up on the front page of The New York Times as the subject of a “latest breach” article. My client’s data are much too important to take that chance.

The success of every penetration test rests on the experience of the test team. If some hacker has more experience than the test team I hire, I’m in trouble! So how do I even the odds? Instead of hiring a team to do a black box, in which they’re going to spend hours searching for information and poking around, I give them the necessary information to test the network thoroughly, right up front. By doing so, their time is actually spent testing the network, not carrying out a high-tech scavenger hunt. Any good penetration test team is still going to do reconnaissance and tell me what information is available about my organization from public sources anyway. No, I’m not going to give up the administrative password to my network. But I am going to tell them what my IP ranges are, whether or not I have wireless, and whether I allow remote access into the network, among other things.

In addition to the types and variations of penetration testing, we also need to talk about announced and unannounced testing. Which of these two methods will be used depends on whether your intent is to test the network itself or the network’s security staff. In an announced test, the penetration testing team works in “full cooperation” with the IT staff and the IT staff has “full knowledge” about the test, such as what will be tested and when. In an unannounced test, only specific members of the tested organization (usually the higher levels of management) are aware that the testing will take place. Even they may only know a “window” of time for testing, not the exact times or dates.

If you follow the published guidelines, an unannounced test is used when testing an organization’s incident response capability is called for. Announced tests are used when the organization simply wants to test network devices. Is this really how it happens in the real world? Sometimes it isn’t.

Most organizations that conduct annual testing do so at about the same time every year, especially if it’s a government organization. So there’s really no such thing as an “unannounced” test. Everyone knows that sometime between X and Y dates, they’re going to be tested. In some organizations this means that during that timeframe there suddenly appears to be an increased awareness of network security. Machines get patched quicker. Logs are reviewed daily. Abnormal activities are reported immediately. After the testing window is over, however, it’s back to the same old routine until the next testing window, next year.

What about announced testing, you ask? Think about it: If you’re a network administrator and you know a test is coming, you’re going to make sure that everything is as good as you can make it. Once again, there’s that increased emphasis on security—until the testing window is over, that is.

Let’s take a minute to recap what we’ve talked about so far. We’ve learned that a penetration test is used to exploit discovered vulnerabilities and to help determine what an attacker could do if they successfully exploited a vulnerability. We learned that not all vulnerabilities are actually a concern, because there might not be a way to exploit them or what we’d get by exploiting them wouldn’t justify the time or effort we spent in doing so. We learned that there are different types and variations of penetration tests, that they can be announced or unannounced, and that none of them are actually “just like a hacker would do it.” Probably the most important thing we’ve learned so far is that if we really and truly want to protect our network from a real-life attack, we have to offset the biggest advantage that a hacker has: time. We discovered that we can do this by giving the testing team sufficient information to thoroughly test the network instead of surfing the Internet on our dime.

What’s next? Let’s talk about how a penetration test might be conducted.

4. Phases of Penetration Testing

There are three phases in a penetration test, and they mimic the phases that an attacker would use to conduct a real attack. These phases are the pre-attack phase, the attack phase, and the post-attack phase, as shown in Figure 22.1.

The activities that take place in each phase (as far as the penetration testing team is concerned) depend on how the rules of engagement have specified that the penetration test be conducted. To give you a more complete picture, we talk about these phases from the perspective of a hacker and from that of a penetration team conducting the test under “black-box” conditions.

5. Defining What’s Expected

Someone once said: “You can’t win the game if you don’t know the rules!” That statement makes good sense for a penetration test team as well. Every penetration test must have a clearly defined set of rules by which the penetration test “game” is played. These rules are put into place to help protect both the tested organization and the penetration test team from errors of omission and commission (under normal circumstances). According to the National Institute of Standards and Technology (NIST), the “rule book” for penetration tests is often called the “Rules of Engagement.” Rules of Engagement define things like which IP addresses or hosts are and are not allowed to be tested, which techniques are and are not allowed to be used, when testing is permitted or prohibited, points of contact for both the test team and the tested organization, IP addresses of machines from which testing is conducted, and measures to prevent escalation of an incident response to law enforcement, just to name a few.

There isn’t a standard format for the Rules of Engagement, so it is not the only document that can be used to control a penetration test. Based on the complexity of the tested organization and the scope of the penetration test, the penetration test team may also use detailed test plan(s) for either or both logical and physical testing. In addition to these documents, both the client and the penetration test company conducting the operation will require some type of formal contact that spells out either explicitly, or incorporates by reference, such items as how discovered sensitive material will be handled, an indemnification statement, nondisclosure statement, fees, project schedule, reporting, and responsibilities. These are but a few of the many items that penetration testing control documents cover, but they should be sufficient for you to understand that all aspects of the penetration test need to be described somewhere in a document.

We now know what’s expected during the penetration test. Armed with this information, how does the penetration test team plan to deliver the goods? It starts with a methodology.

6. The Need for a Methodology

When you leave for vacation and you’ve never been to your destination before, you’re likely make a list of things you need or want to do before, during, or after the trip. You might also take a map along so you know how to get there and not get lost or sidetracked along the way. Penetration test teams also use a map of sorts. It’s called their methodology.

A methodology is simply a way to ensure that a particular activity is conducted in a standard manner, with documented and repeatable results. It’s a planning tool to help ensure that all mandatory aspects of an activity are performed.

Just as a map will show you various ways to get to your destination, a good penetration testing methodology does not restrict the test team to a single way of compromising the network. While on the road to your dream vacation, you might find your planned route closed or under construction and you might have to make a detour. You might want to do some sightseeing, or maybe visit long-lost relatives along the way.

Similarly, in a penetration test, your primary attack strategy might not work, forcing you to find a way around a particular network device, firewall, or intrusion prevention system. While exploiting one vulnerability, you may discover another one that leads you to a different host or a different subnet. A well-written methodology allows the test team the leeway necessary to explore these “targets of opportunity” while still ultimately guiding them to the stated goals of the test.

Most penetration test companies will have developed a standard methodology that covers all aspects of a penetration test. This baseline methodology document is the starting point for planning a particular test. Once the control documentation has been finalized, the penetration test team will know exactly what they can and cannot test. They will then modify that baseline methodology based on the scope statement in the Rules of Engagement for the penetration test that they are going to conduct.

Different clients are subject to different regulatory requirements such as HIPAA, Sarbanes-Oxley, Gramm-Leach-Bliley, or others, so the penetration test team’s methodology must also be flexible enough to cover these and other government or private industry regulations.

In a minute, we’ll talk about the sources of penetration testing methodologies, but for now, just understand that a methodology is not a “nice to have,” it’s a “must have.” Without a methodology to be used as the basis to plan and execute a penetration test, there is no reliability. The team will be lost in the network, never knowing if they’ve fulfilled the requirements of the test or not until they’re writing the report. By then, it’s too late—for them and for the organization.

7. Penetration Testing Methodologies

Back to our map example for a minute. Unless you’re a cartographer, you’re probably not going to make your own map to get to your dream vacation destination. You’ll rely on a map that someone else has drawn, tested, and published. The same holds true for penetration testing methodologies. Before we talk about how a methodology, any methodology, is used in a penetration test, let’s discuss penetration testing methodologies in general. There are probably as many different methodologies as there are companies conducting penetration tests, but all of them fit into one of two broad categories: open source or proprietary.

Open-source methodologies are just that: available for use by anyone. Probably the best-known open-source methodology, and de facto standard, is the Open Source Security Testing Methodology Manual (OSSTMM), the brainchild of Pete Herzog. You can get the latest copy of this document at www.isecom.org. Another valuable open-source methodology is the Open Web Application Security Project (OWASP), geared to securing Web applications, available at www.owasp.org.

Proprietary methodologies have been developed by particular entities offering network security services or certifications. The specific details of the processes that produce the output of the methodology are usually kept private. Companies wanting to use these proprietary methodologies must usually undergo specific training in their use and abide by quality standards set by the methodology proponent. Some examples of proprietary methodologies include IBM, ISS, Foundstone, and our own EC Council Licensed Penetrator Tester methodology.

8. Methodology in Action

A comprehensive penetration test is a systematic analysis of all security controls in place at the tested organization. The penetration test team will look at not only the logical and physical vulnerabilities that are present but also at the tested organization’s policies and procedures to assess whether or not the controls in place adequately protect the organization’s information infrastructure.

Let’s examine the use of a penetration testing methodology in more detail to demonstrate how it’s used to conduct a penetration test. Of course, as the President of the EC-Council, I’m going to take the liberty of using our LPT methodology as the example.

9. Penetration Testing Risks

The difference between a real attack and a penetration test is the penetration tester’s intent, authority to conduct the test, and lack of malice. Because penetration testers may use the same tools and procedures as a real attacker, it should be obvious that penetration testing can have serious repercussions if it’s not performed correctly.

Even if your target company ceased all operations for the time the penetration test was being conducted, there is still a danger of data loss, corruption, or system crashes that might require a reinstall from “bare metal.” Few, if any, companies can afford to stop functioning while a penetration test is being performed. Therefore it is incumbent on both the target organization and the penetration test team to do everything in their power to prevent an interruption of normal business processes during penetration testing operations.

Target companies should be urged to back up all their critical data before testing begins. They should always have IT personnel present to immediately begin restoration in the unfortunate event that a system crashes or otherwise becomes unavailable. The test team must be prepared to lend all possible assistance to the target company in helping to restore any system that is affected by penetration testing activities.

10. Liability Issues

Although we just discussed some of the risks involved with conducting a penetration test, the issue of liability deserves its own special section. A botched penetration test can mean serious liability for the penetration test company that conducted the testing. The penetration test company should ensure that the documentation for the penetration test includes a liability waiver.

The waiver must be signed by an authorized representative of the target company and state that the penetration testing firm cannot be held responsible for the consequences of items such as:

11. Legal Consequences

The legal consequences of a penetration test gone wrong can be devastating to both the target company and the penetration testers performing the test. The company may become the target of lawsuits by customers. The penetration testers may become the target of lawsuits by the target company. The only winners in this situation are the lawyers. It is imperative that proper written permission is obtained from the target company before any testing is conducted.

Legal remedies are normally contained in a penetration testing contract that is drawn up in addition to the testing control documentation. Both the penetration test company and the target company should seek legal counsel to review the agreement and to protect their interests. The authorization to perform testing must come from a senior member of the test company, and that senior member must be someone who has the authority to authorize such testing, not just the network administrator or LAN manager.

Authorized representatives of both the penetration test company and the target company must sign the penetration testing contract to indicate that they agree with its contents and the contents of all documentation that may be included or included by reference, such as the Rules of Engagement, the test plan, and other test control documentation.

12. “Get Out of Jail Free” Card

We just talked about how the target company and the penetration test company protect themselves. What about that individual team member crawling around in the dumpster at 2:00 a.m., or the unfortunate team member who’s managed to get into the company president’s office and log onto his or her computer? What protection do those individuals have when that 600-pound gorilla of a security guard clamps his hand on their shoulder and asks what they’re doing?

A “Get Out of Jail Free” card might just work wonders in these and other cases. Though not really a card, it’s usually requested by the penetration test team as “extra insurance” during testing. It is presented if they’re detained or apprehended while in the performance of their duties, as proof that their actions are sanctioned by the officers of the company. The card may actually be a letter on the tested company’s letterhead and signed by the senior officer authorizing the test. It states the specific tasks that can be performed under the protection of the letter and specifically names the bearer.

It contains language that the bearer is conducting activities and testing under the auspices of a contract and that no violation of policy or crime is or has been committed. It includes a 24-hour contact number to verify the validity of the letter. As you can imagine, these “Get Out of Jail Free” cards are very sensitive and are usually distributed to team members immediately before testing begins, collected, and returned to the target company immediately after the end of any testing requiring their use.

There is a tremendous amount of work involved in conducting a thorough and comprehensive penetration test. What we’ve just discussed is but a 40,000-foot flyover of what actually happens during the process. But we’re not done yet! The one area that we haven’t discussed is the personnel performing these tests.

13. Penetration Testing Consultants

The quality of the penetration test performed for a client is directly dependent on the quality of the consultants performing the work, singularly and in the aggregate. There are hundreds if not thousands of self-proclaimed “security services providers” out there, both companies and individuals. If I’m in need of a penetration test, how can I possibly know whether the firm or individual I’m going to select is really and truly qualified to test my network comprehensively, accurately, and safely? What if I end up hiring a consultancy that employs hackers? What if the consultant(s) aren’t hackers, but they just don’t know what they’re doing?

In these, the last pages of this chapter, I want to talk about the people who perform penetration testing services. First, you get another dose of my personal opinion. Then we’ll talk about security services providers, those who provide penetration testing services. We’ll talk about some of the questions that you might want to ask about their operations and their employees. Here’s a hint for you: If the company is evasive in answering the questions or outright refuses to answer them—run!

What determines whether or not a penetration tester is “experienced”? There are few benchmarks to test the knowledge of a penetration tester. You can’t ask her for a score: “Yes, I’ve performed 27 penetration tests, been successful in compromising 23 of those networks, and the overall degree of difficulty of each one of those tests was 7 on a scale of 1 to 10.”

There really isn’t a Better Business Bureau for penetration testers. You can’t go to a Web site and see that XSecurity has had three complaints filed against them for crashing networks they’ve been testing or that “John Smith” has tested nine networks that were hacked within the following 24 hours. (Whoa! What an idea . . . ! Nah, wouldn’t work.) Few companies would want to admit that they chose the wrong person or company to test their networks, and that kind of information would surely be used by attackers in the “intelligence-gathering phase” as a source of information for future attacks on any company that chose to report.

Well, if we can’t do that, what can we do?

We pretty much have to rely on “word of mouth” that such-and-such a company does a good job. We have to pretty much rely on the fact that the tester has been certified to a basic standard of knowledge by a reputable certification body. We pretty much have to rely on the skill set of the individual penetration tester and that “the whole is more than the sum of its parts” thing called synergy, which is created when a group of penetration testers works together as a team.

I’m not going to insult you by telling you how to go ask for recommendations. I will tell you that there are security certification providers who are better than others and who hold their candidates to a higher standard of knowledge and professionalism than others. Since it’s hard to measure the “synergy” angle, let’s take a closer look at what skill sets should be present on the penetration team that you hire.

14. Required Skill Sets

Your penetration test “dream team” should be well versed in areas such as these:

That’s a rather long list to demonstrate a simple concept: Your penetration team should be able to show proof that they have knowledge about all the hardware, software, services, and protocols in use within your network.

Okay. They have technical skills. Is that enough?

15. Accomplishments

Are the members of the test team “bookworms” or have they had practical experience in their areas of expertise? Have they contributed to the security community? The list that follows should give you some indication of questions you can ask to determine the “experiences” of your test team:

How about some simple questions to ask of the company that will perform your test?

16. Hiring a Penetration Tester

Here are some of the questions you might consider asking prospective security service providers or things to think about when hiring a test team:

That ought to get a company started down the road to hiring a good penetration test team. Now let’s talk about why a company should hire you, either as an individual or as a member of a penetration testing team.

17. Why Should a Company Hire You?

When a prospective client needs a penetration test, they may publish a request for proposal (RFP) or just make an announcement that they are accepting solicitations for security services. When all the bids come in, they will only consider the most qualified candidates. How to you make sure that your or your company’s bid doesn’t end up in the “circular file?”

18. All’s Well that Ends Well

Anybody got an aspirin? I’m sure you probably need one after reading all the information I’ve tried to throw at you in this chapter. I’ve only barely scratched the surface of what a penetration test is, what it’s meant to accomplish, how it’s done, and how you report the findings to the client, but I’m out of space to tell you more.

Let me take these last couple of inches on the page to summarize. If you’ve got a network, the question is not “if” you’ll be attacked, but “when.” If you’re going to make your network as safe as possible, you need to find the weaknesses and then test them to see which ones are really, truly the things that need to be fixed “yesterday.” If you only conduct a penetration test once a year, a real hacker has 364 “unbirthdays” in which to attack and compromise your network. Don’t give them the opportunity. Get someone on your staff certified as an ethical hacker and a Licensed Penetration Tester so that they can perform ethical hacks and penetrations on a regular basis to help protect your network.