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 untraceableaccess
- 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.

Understanding Standards
Okay, we’ve told you that you need to develop a testing process — here’s
where we give you guidance on how to do so. We wouldn’t keep you hanging
by a wire (this is, after all, a wireless book). The following standards (which
we get friendly with in the upcoming sections) provide guidance on performing
your test:
- ISO 17799
- COBIT
- SSE-CMM
- ISSAF
- OSSTMM

You may find that the methodology you choose is preordained. For instance,
when your organization uses COBIT, you should look to it for guidance. You
don’t need to use all of these methodologies. Pick one and use it. A good
place to start is with the OSSTMM.

Using ISO 17799
The ISO/IEC 17799 is an internationally adopted “code of practice for information
security management” from the International Organization for Standardization
(ISO). The international standard is based on British Standard BS-799.
You can find information about the standard at www.iso.org.
ISO/IEC 17799 is a framework or guideline for your ethical hack — not a true
methodology — but you can use it to help you plan. The document does not
specifically deal with wireless, but it does address network-access control.
The document is a litany of best practices at a higher level than we would
want for a framework for ethical hacking.
One requirement in the document is to control access to both internal and
external networked services. To cover this objective, you need to try to connect
to the wireless access point and try to access any resource on the wired
network.

The document also requires that you ensure there are appropriate authentication
mechanisms for users. You can test this by attempting to connect to a
wireless access point (AP). When there is Open System authentication (see
Chapter 16) you need not do any more work. Obviously no authentication
is not appropriate authentication. APs with shared-key authentication may
require you to use the tools shown in Chapter 15 to crack the key. If the AP is
using WPA security, then you will need to use another tool, such as WPAcrack.
Should the AP implement Extensible Authentication Protocol (EAP), you may
need a tool such as asleap (see Chapter 16).
Bottom line: These guidelines don’t give you a step-by-step recipe for testing,
but they can help you clarify the objectives for your test.

Using COBIT
COBIT is an IT governance framework. Like ISO 17799, this framework will
not provide you with a testing methodology, but it will provide you with the
objectives for your test.
You can find information about COBIT at www.itgi.org/.

Using SSE-CMM
Ever heard of the CERT? (Give you a hint: It’s not a breath mint or a candy.)
It’s the Computer Emergency Response Team that’s part of the Software
Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh,
Pennsylvania. Well, the SEI is known for something else: It developed a
number of capability maturity models (CMM) — essentially specs that can give
you a handle on whether a particular system capability is up to snuff. The SEI
included a CMM just for security — the Systems Security Engineering CMM
(SSE-CMM for short). Now, the SSE-CMM won’t lay out a detailed method of
ethical hacking, but it can provide a framework that will steer you right. The
SSE-CMM can help you develop a scorecard for your organization that can
measure security effectiveness.
You can find out about SSE-CMM at www.sei.cmu.edu/.
The Computer Emergency Response team also sends out security alerts and
advisories. The CERT has a methodology as well — OCTAVE. OCTAVE stands
for Operationally Critical Threat, Asset, and Vulnerability Evaluation. You can
use OCTAVE as a methodology to build a team, identify threats, quantify vulnerabilities,
and develop an action plan to deal with them.
You can find OCTAVE at www.cert.org/octave.

Using ISSAF
The Open Information System Security Group (www.oissg.org) has published
the Information Systems Security Assessment Framework (ISSAF).
Developed as an initiative by information-security professionals, the ISSAF is
a practical tool — a comprehensive framework you can use to assess how
your security effectiveness. It’s an excellent resource to use as you devise
your test. (Draft 0.1 has, in fact, 23 pages on WLAN security assessment.)
The ISSAF details a process that includes the following steps:
1. Information gathering
a. Scan
b. Audit
2. Analysis and research
3. Exploit and attack
4. Reporting and presentation

These steps correspond to our Ten Commandments of Ethical Hacking. For
each of the steps just given, the document identifies appropriate tasks and
tools. For example, the scanning step lists the following tasks:
1. Detect and identify the wireless network
2. Test for channels and ESSID
3. Test the beacon broadcast frame and recording of broadcast information
4. Test for rogue access points from outside the facility
5. IP address collection of access points and clients
6. MAC address collection of access points and clients
7. Detect and identify the wireless network

The document recommends you use programs such as Kismet, nmap, and
ethereal as tools for Step 1.
You also will find information in the document on the software you can use
and the equipment you will need to build or acquire to do your assessment
of your organization’s wireless-security posture.
The document we reviewed was a beta version, but it shows promise and is
worth watching. You can find the ISSAF at www.oissg.org/issaf.

Using OSSTMM
We do recommend you take a long and hard look at the OSSTMM — the Open
Source Security Testing Methodology Manual (www.osstmm.org). The Institute
for Security and Open Methodologies (ISECOM), an open-source collaborative
community, developed the OSSTMM’s methods and goals much along the
lines of the ISSAF: as a peer-review methodology. Now available as version
3.0, the OSSTMM has been available since January 2001 and is more mature
than the ISSAF.

You’ll find that the OSSTMM gathers the best practices, standard legal issues,
and core ethical concerns of the global security-testing community — but
this document also serves another purpose: consistent definition of terms.
The document provides a glossary that helps sort out the nuances of vulnerability
scanning, security scanning, penetration testing, risk assessment,
security auditing, ethical hacking, and security hacking. The document also
defines white-hat, gray-hat, and black-hat hackers, so that by their metaphorical
hats ye shall know them. But even more importantly (from your viewpoint
as an ethical-hacker-to-be), it provides testing methodologies for wireless
security, distilled in the following bullets:

Posture review: General review of best practices, the organization’s
industry regulations, the organization’s business justifications, the organization’s
security policy, and the legal issues for the organization and
the organization’s regions for doing business.
Electromagnetic radiation (EMR) testing: Testing of the electromagnetic
radiation emitted from wireless devices.
802.11 wireless-networks testing: Testing of access to 802.11 WLANs.
Bluetooth network testing: Testing of Bluetooth ad-hoc networks.
Wireless-input-device testing: Testing of wireless input devices, such as
mice and keyboards.
Wireless-handheld testing: Testing of handheld wireless devices, such
as personal digital assistants and personal electronic devices.
Cordless-communications testing: Testing of cordless communications
communication devices, such as cellular technology.
Wireless-surveillance device testing: Testing of wireless surveillance or
monitoring devices, such as cameras and microphones.
Wireless-transaction device testing: Testing of wireless-transaction
devices, such as uplinks for cash registers and other point of sale
devices in the retail industry.
RFID testing: Testing of RFID (Radio Frequency Identifier) tags.
Infrared testing: Testing of infrared communications communication
devices.
Privacy review: General privacy review of the legal and ethical storage,
transmission, and control of data, based on employee and customer
privacy.

Each step has associated tasks that provide more detail and specific tests. As
well, each step has a table that outlines the expected results. For example,
expected results for Step 3 include these:
1. Verification of the organization’s security policy and practices — and those of its users.
2. Identification of the outermost physical edge of the wireless network.
3. Identification of the logical boundaries of the wireless network.
4. Enumeration of access points that lead into the network.
5. Identification of the IP-range (and possibly DHCP-server) of the wireless network.
6. Identification of the encryption methods used for data transfer.
7. Identification of the authentication methods of exploitable “mobile units” (that is, the clients) and users.
8. Verification of the configuration of all devices.
9. Determination of the flaws in hardware or software that facilitate attacks.

Obviously, you need to cut and paste these tests according to your needs.
For instance, should your organization not have infrared, then you would
skip Step 11.

The OSSTMM is available from www.isecom.org/osstmm/.
With resources like these, you have a methodology — and everything you
need to map out your plan. But rather than leave you hanging there, the rest
of the book shows you how to work through a methodology.



Taken from:
Hacking Wireless Networks For Dummies®
Published by
Wiley Publishing, Inc.
111 River Street
Hoboken, NJ 07030-5774
www.wiley.com