Obeying the Ten Commandments of Ethical Hacking - dummies

Obeying the Ten Commandments of Ethical Hacking

By Kevin Beaver, Peter T. Davis, Devin K. Akin

These commandments were not brought down from Mount Sinai, but thou shalt follow these commandments shouldst thou decide to become a believer in the doctrine of ethical hacking.

Thou shalt set thy goals

Your evaluation of the security of a wireless network should seek answers to three basic questions:

  • What can an intruder see on the target access points or networks?
  • What can an intruder do with that information?
  • Does anyone at the target notice the intruder’s attempts — or successes?

You might set a simplistic goal, such as finding unauthorized wireless access points. Or you might set a goal that requires you to obtain information from a system on the wired network. Whatever you choose, you must articulate your goal and communicate it to your sponsors.

Involve others in your goal-setting. If you don’t, you will find the planning process quite difficult. The goal determines the plan. To paraphrase the Cheshire Cat’s response to Alice: “If you don’t know where you are going, any path will take you there.” Including stakeholders in the goal-setting process will build trust that will pay off in spades later on.

Thou shalt plan thy work, lest thou go off course

Few, if any of us, are not bound by one or more constraints. Money, personnel, or time may constrain you. Consequently, it is important for you to plan your testing.

With respect to your plan, you should do the following:

1. Identify the networks you intend to test.

2. Specify the testing interval.

3. Specify the testing process.

4. Develop a plan and share it with all stakeholders.

5. Obtain approval of the plan.

Share your plan. Socialize it with as many people as you can. Don’t worry that lots of people will know that you are going to hack into the wireless network. If your organization is like most others, then it’s unlikely they can combat the organizational inertia to do anything to block your efforts. It is important, though, to remember that you do want to do your testing under “normal” conditions.

Thou shalt obtain permission

When doing ethical hacking, don’t follow the old saw that “asking forgiveness is easier than asking for permission.” Not asking for permission may land you in prison!

You must get your permission in writing. This permission may represent the only thing standing between you and an ill-fitting black-and-white-striped suit and a lengthy stay in the Heartbreak Hotel. It should state that you are authorized to perform a test according to the plan. It should also say that the organization will “stand behind you” in case you are criminally charged or sued. This means they will provide legal and organizational support as long as you stayed within the bounds of the original plan (see Commandment Two).

Thou shalt work ethically

The term ethical in this context means working professionally and with good conscience. You must do nothing that is not in the approved plan or that has been authorized after the approval of the plan.

As an ethical hacker, you are bound to confidentiality and non-disclosure of information you uncover, and that includes the security-testing results. You cannot divulge anything to individuals who do not “need-to-know.” What you learn during your work is extremely sensitive — you must not openly share it.

You must also ensure you are compliant with your organization’s governance and local laws. Do not perform an ethical hack when your policy expressly forbids it — or when the law does.

Thou shalt keep records

Major attributes of an ethical hacker are patience and thoroughness. Doing this work requires hours bent over a keyboard in a darkened room. You may have to do some off-hours work to achieve your goals, but you don’t have to wear hacker gear and drink Red Bull. What you do have to do is keep plugging away until you reach your goal.

One hallmark of professionalism is keeping adequate records to support your findings. When keeping paper or electronic notes, do the following:

  • Log all work performed.
  • Record all information directly into your log.
  • Keep a duplicate of your log.
  • Document — and date — every test.
  • Keep factual records and record all work, even when you think you were not successful.

Thou shalt respect the privacy of others

Treat the information you gather with the utmost respect. You must protect the secrecy of confidential or personal information. All information you obtain during your testing — for example, encryption keys or clear text passwords — must be kept private. Don’t abuse your authority; use it responsibly. This means you won’t snoop into confidential corporate records or private lives. Treat the information with the same care you would give to your own personal information.

Thou shalt do no harm

Remember that the actions you take may have unplanned repercussions. It’s easy to get caught up in the gratifying work of ethical hacking. You try something, and it works, so you keep going. Unfortunately, by doing this you may easily cause an outage of some sort, or trample on someone else’s rights. Resist the urge to go too far and stick to your original plan.

Also, you must understand the nature of your tools. Far too often, people jump in without truly understanding the full implications of the tool. They do not understand that setting up an attack might create a denial of service. Relax, take a deep breath, set your goals, plan your work, select your tools, and (oh yeah) read the documentation.

Thou shalt use a “scientific” process

Your work should garner greater acceptance when you adopt an empirical method. An empirical method has the following attributes:

  • Set quantifiable goals: The essence of selecting a goal is that you know when you’ve reached it. Pick a goal that you can quantify: associating with ten access points, broken encryption keys or a file from an internal server. Time-quantifiable goals, such as testing your systems to see how they stand up to three days of concerted attack, are also good.
  • Tests are consistent and repeatable: If you scan your network twice and get different results each time, this is not consistent. You must provide an explanation for the inconsistency, or the test is invalid. If we repeat your test, will we get the same results? When a test is repeatable or replicable, you can conclude confidently that the same result will occur no matter how many times you replicate it.
  • Tests are valid beyond the “now” time frame: When your results are true, your organization will receive your tests with more enthusiasm if you’ve addressed a persistent or permanent problem, rather than a temporary or transitory problem.

Thou shalt not covet thy neighbor’s tools

No matter how many tools you may have, you will discover new ones. Wireless hacking tools are rife on the Internet — and more are coming out all the time. The temptation to grab them all is fierce.

Early on, your choices of software to use for this “fascinating hobby” were limited. You could download and use Network Stumbler, commonly called NetStumbler, on a Windows platform, or you could use Kismet on Linux. But these days, you have many more choices: Aerosol, Airosniff, Airscanner, APsniff, BSD-Airtools, dstumbler, Gwireless, iStumbler, KisMAC, MacStumbler, MiniStumbler, Mognet, PocketWarrior, pocketWiNc, THC-RUT, THC-Scan, THC-WarDrive, Radiate, WarLinux, Wellenreiter WiStumbler and Wlandump, to name a few. And those are just the free ones. Should you have unlimited time and budget, you could use all these tools. Instead, pick one tool and stick with it.

Thou shalt report all thy findings

Should the duration of your test extend beyond a week, you should provide weekly progress updates. People get nervous when they know someone is attempting to break into their networks or systems and they don’t hear from the people who’ve been authorized to do so.

You should plan to report any high-risk vulnerabilities discovered during testing as soon as they are found. These include

  • discovered breaches
  • vulnerabilities with known — and high — exploitation rates
  • vulnerabilities that are exploitable for full, unmonitored, or untraceable access
  • vulnerabilities that may put immediate lives at risk

You don’t want someone to exploit a weakness that you knew about and intended to report. This will not make you popular with anyone.

Your report is one way for your organization to determine the completeness and veracity of your work. Your peers can review your method, your findings, your analysis, and your conclusions, and offer constructive criticism or suggestions for improvement.

If you find that your report is unjustly criticized, following the Ten Commandments of Ethical Hacking, should easily allow you to defend it.

One last thing: When you find 50 things, report on 50 things. You need not include all 50 findings in the summary but you must include them in the detailed narrative. Withholding such information conveys an impression of laziness, incompetence, or an attempted manipulation of test results. Don’t do it.