open-source security testing methodology manual

INSTITUTE FOR SECURITY AND OPEN
METHODOLOGIES

Any information contained within this document may not be modified or sold without the express consent of the author.
Copyright 2000-2003, Peter Vincent Herzog, the Institute for Security and Open Methodologies. All Rights Reserved,
available for free dissemination under the Open Methodology License (OML).








OSSTMM
WIRELESS
2.9.1

Wireless Security Testing Section
Open-Source Security Testing Methodology Manual


Created by Pete Herzog

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

2
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.




CURRENT VERSION:
OSSTMM Wireless 2.9.1

NOTES:
This is the first of a series of OSSTMM Section separations to provide focus to
various types of security tests and promote higher quality peer-review.

All updated material until 3.0 will only be released only to subscribers.

CHANGES:
Fixed mistake in EMF Testing module.

DATE OF CURRENT VERSION:
Wednesday, October 30, 2003

DATE OF ORIGINAL VERSION:
Monday, December 18, 2000

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

3
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

OSSTMM Contributors
Those who have contributed to this manual in consistent, valuable ways have been listed here although many
more people should receive our thanks. Each person here receives recognition for the type of contribution
although not as to what was contributed. The use of contribution obscurity in this document is for the prevention
of biases and to promote fresh ideas. If you are interested in contributing, please see the ISECOM website for
more information.


CREATED BY:
Pete Herzog Managing Director of ISECOM - pete<at>isecom.org
KEY CONTRIBUTORS:
Marta Barceló
Robert E. Lee
Rick Tucker
Nigel Hedges
Colby Clark
Tom O’Connor
Andrea Barisani
Gary Axten
Marco Ivaldi
Raoul Chiesa

Assistant Director of ISECOM - marta<at>isecom.org
co-Chairman of the Board of ISECOM -
robert<at>isecom.org

Board Advisor of ISECOM - rick<at>isecom.org
nigel.hedges<at>ca.com
colby<at>isecom.org
tom91<at>elivefree.net
lcars<at>infis.univ.trieste.it
gary.axten<at>lineone.net
raptor<at>mediaservice.net
raoul<at>mediaservice.net
KEY ASSISTANCE:
Dru Lavigne
Felix Schallock
Anton Chuvakin
Efrain Torres
Lluís Vera
Rogelio M. Azorín
Richard Feist
Rob J. Meijer
John Pascuzzi
Miguel Angel de Cara
L Chris N Shepherd
Darren Young
Clemens Wittinger
Nabil Ouchn
Sean Cocat
Leonardo Loro
Carles Alcolea
Claudia Kottmann

Manager of the OPRP of ISECOM - dru<at>isecom.org
felix.schallock<at>e-security-net.de

anton<at>chuvakin.org
et<at>cyberspace.org
lvera<at>isecb.com
rma<at>isecb.com
rfeist<at>nyxtec.net
rmeijer<at>xs4all.nl
johnpas<at>hushmail.com
miguelangel.decara<at>dvc.es
chris.shepherd<at>icctcorp.com
darren<at>younghome.com
cwr<at>atsec.com
ghosted<at>ccc.ma
scocat<at>remingtonltd.com
leoloro<at>microsoft.com
calcolea<at>menta.net
claudia.kottmann<at>gmx.net
KEY SUPPORTERS:
Jaume Abella
Travis Schack
Andre Maxwell
John Regney
Peter Klee
Martin Pivetta
Daniel Fdez. Bleda
Clément Dupuis
Waidat Chan
Josep Ruano Bou
Tyler Shields
Javier Fdez. Sanguino
Vicente Aguilera

John Rittinghouse
Kris Buytaert
Xavier Caballé
Brennan Hay
jaumea<at>salleurl.edu
travis<at>vitalisec.com
amaxwel3<at>bellsouth.net
sregney<at>gedas.es
klee<at>de.ibm.com
martin.pivetta<at>itatwork.com
dfernandez<at>isecauditors.com
cdupuis<at>cccure.org
waidat<at>interrorem.com
jruano<at>capside.com
tcroc<at>cow.pasture.com
jfernandez<at>germinus.com
vaguilera<at>isecauditors.com
jwr<at>rittinghouse.homeip.net
buytaert<at>stone-it be
xavi<at>caballe.com
hayb<at>ncr.disa.mil


OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

4
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Key Contributors: This designation is for those individuals who have contributed a significant portion of their
time and energy into creating a better OSSTMM. This required complete section rewrites, module
enhancements, and rules of engagement development.

Key Assistance: This designation is for those individuals who have contributed significantly to the ideas, design,
and development of the OSSTMM. This required section rewrites, module contributions, and significant editing.

Key Supporters: This designation is for those individuals who have made significant efforts towards promoting
and explaining the OSSTMM in the name of ISECOM. This required article and press writings, improvements to
the OSSTMM, and regular knowledge support.
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

5
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Foreword
In previous versions of the OSSTMM a primary focus was on what we do as security testers. Due to the success
of those releases and the OSSTMM’s growing approval amongst the IT security community, I have had the
continued pleasure to expand upon the OSSTMM. To help deliver this methodology, I created the OSSTMM
Professional Security Tester (OPST) and Analyst (OPSA) certifications. I’ve had the pleasure to teach these now
on a number of occasions, and it has been during some of these classes that I have observed a growing
requirement to define why we do security testing.

When dealing with security and risk management, many think of these in terms of odds and predictability. They
ask: What are the odds that an incident, threat or attack will occur? Just how predictable is it that this event will
occur? While it is true that some defenses are proactive enough to address unknown and unpredictable attacks,
most organizations depend on defenses that are strengthened by a database of known attacks. A penetration
tester knows that to counteract these he/she must also have a database of known up-to-date attacks. This aids in

the swiftness and effectiveness of each attempt. Time and time again, a certain set of “ethical hacks” will prove
successful, so the tester will savor these jewels from his/her database of attacks, and log the success ratios.
Armed with this information the penetration tester will attempt to exploit a customer’s network until one of the
attacks succeeds. This technique is well and good, however in practice the client’s organization becomes a
casino and the penetration testers are playing against the client’s predetermined odds. This is much like the
gambler is at the mercy of the odds set by the casino. For those unfamiliar with casinos and forms of gambling, it
is important to understand that established games of chance like those found at a casino, can never have a
50/50 win to lose ratio because the casino will not make money. Therefore, casinos will choose to offer games
which will offer a higher lose than win ratio to assure money is made over a set period of time which is known as
“setting the odds”. Players who learn to “cheat” at casino games use techniques to upset the win to lose ratio in
the other direction. This is never more true than when a player knows how to play a game better than the casino
(which is extremely rare but happens) in which case the casino would consider this cheating even if it relied on
memory abilities like counting cards (blackjack), skills like calculating an extremely large number of variables to
place bets accordingly (sports betting and animal racing), or something simple like pattern recognition (roulette).
Penetration testers who gain privileged access through higher skills and better knowledge than the client has is
also sometimes seen as “cheating” although they are actually changing the rules of the game by exploiting
security defenses which have been minimized for business justification and usability. Changing the rules of the
game is very different than playing by the rules and setting your own odds in the test. Often times the client is
aware of these risks which are necessary for business. You can’t open a store without inviting people to shop.

Methodical security testing is different from penetration testing. It relies on a combination of creativeness,
expansive knowledge bases of best practices, legal issues, and the client’s industry regulations as well as known
threats, and the breadth of the target organization’s security presence (or points of risk) to “cheat“ at the casino,
thus making our own odds. We do this by exploiting predictability and best practices to the most thorough extent
possible. In other words, we test all extremes of everything considered predictable and fully utilize best practices
to test against the worst-case scenarios that may not be as predictable. For organizations truly committed to
reduce as much risk as possible, it almost goes without saying that it is our duty as security testers to explore the
breadth, depth of risk, and to properly identify this during the testing of the target.

The types of questions we must continually ask ourselves in the testing process are: Which assets can I access

at what time to force the maximum security risk? Under what circumstances do I find the most weaknesses?
When am I most likely to put confidentiality, integrity and availability to the test? By remaining methodical and
persistent, the accumulative effect of these tests will paint an accurate picture for us of the risks, weaknesses,
information leaks, and vulnerabilities. This will assist us greatly with any business justifications for safeguards, as
well as satisfying any regulative/legislative requirements through due care and diligence.

The following points will aid you well as you set out to create and deliver your high standard security tests:

• When to test is as important as what and why to test.
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

6
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.


Waiting to make the test, waiting to report the problems, and waiting to address problems are all
mistakes. As you left your house to go on vacation, did you wait until you returned to test if you actually
locked the doors? Of course not. You locked the door and rattled the knob to make sure it was locked.
Waiting until you return to test would also require going through the house to see what’s missing, and
you don’t need reminding that an audit takes much longer than a security test.

• Do sweat the small stuff, because it’s all small stuff.

Testing is in the details and often it is the smallest details that lead to the biggest security breaches. In
addition, it is the accumulation of the small stuff, which individually may not represent much risk although
when aggregated, may also lead to a security breach.

• Do make more with less.

As budgets for security defense remain small, the security tester needs to operate with efficiency and
creativity to do more in less time. If inefficient security testing becomes too costly it is tempting for an
organization to see security testing as an extraneous cost. This is unfortunate because the risks
associated from not conducting security testing still remains unknown. Therefore, as we balance
thoroughness with efficiency in our security tests, the results will time and time again speak for
themselves - many more organizations will view security testing as a cost justified weapon in their
defensive posture.

• Don’t underestimate the importance of the Security Policy in any form.

This policy is the company’s official declaration of what they want to accomplish. Very few people ever
arrive somewhere without first intending to get there. A security policy is all about that intention, and the
organization’s goal of security within it. The security policy for an organization is often very complex with
multiple persons tasked to develop and maintain it. Mistakes due to policy in one section will often form
a negative flow-on effect that will impact other sections. It only takes a few termites in a wall to lead to
infestation of the whole house. For example, if a policy is not in place to specify controls that check
people who leave with boxes or equipment, then information leakage may occur. Security Policy
specifies many more controls that have a direct effect on standards and procedures, such as what
egression rules exist on the screening router, or what e-mails one may forward out from inside the
company.

• What they get is all about how you give it.

Despite all attempts at thoroughness and efficiency, one of the largest factors about determining the
success of a security posture is still based on economics. This is all handled far away from the tester’s
toolbox. It requires a certain level of project management skills, perceptiveness about your client, and
good communication skills. Has enough time for the test been budgeted? Will there be enough in the
budget for fixing discovered vulnerabilities? What types of risk will senior management accept or feel is
unworthy of budgeting? The end result of the security test will be some form of deliverable to your client

or client’s management – and all these economic factors should have been worked out before hand.
After all, what’s the difference between a good and a bad security test if the report is ignored?

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

7
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Table of Contents

OSSTMM Contributors 3

Foreword 5
Introduction 8
Scope 9
Intended Audience 9
Accreditation 9
End Result 10
Analysis 10
Internet and Network Related Terms 10
Compliance 14
Legislation 14
Best Practices 16
Rules Of Engagement 17
Process 19
The Security Map 20
Security Map Module List 21
Risk Assessment 22

Risk Evaluation 22
“Perfect” Security 23
Risk Assessment Values 25
Risk Types 25
Sections and Modules 27
Test Modules and Tasks 28
Module Example 28
Methodology 29
Section E – Wireless Security 30
Risk Assessment Values 31
Modules 32
1. EMR (Electromagnetic Radiation) Testing 32
2. 802.11 Wireless Networks Testing 33
3. Bluetooth Network Testing 37
4. Wireless Input Device Testing 40
5. Wireless Handheld Security Testing 41
6. Cordless Communications Testing 42
7. Wireless Surveillance Device Testing 43
8. Wireless Transaction Device Testing 44
9. RFID Testing 45
10. Infrared Systems Testing 47
Open Methodology License (OML) 49
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

8
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Introduction

This manual is a combination of ambition, study, and years of experience. The individual tests themselves are
not particularly revolutionary, but the methodology as a whole does represent the benchmark for the security
testing profession. And through the thoroughness of its application you will find a revolutionary approach to
testing security.

This manual is a professional standard for security testing in any environment from the outside to the inside. As
a professional standard, it includes the rules of engagement, the ethics for the professional tester, the legalities of
security testing, and a comprehensive set of the tests themselves. As security testing continues to evolve into
being a valid, respected profession, the OSSTMM intends to be the professional’s handbook.

The objective of this manual is to create one accepted method for performing a thorough security test. Details
such as the credentials of the security tester, the size of the security firm, financing, or vendor backing will impact
the scale and complexity of our test – but any network or security expert who meets the outline requirements in
this manual will have completed a successful security profile. You will find no recommendation to follow the
methodology like a flowchart. It is a series of steps that must be visited and revisited (often) during the making of
a thorough test. The methodology chart provided is the optimal way of addressing this with pairs of testers
however any number of testers are able to follow the methodology in tandem. What is most important in this
methodology is that the various tests are assessed and performed where applicable until the expected results are
met within a given time frame. Only then will the tester have addressed the test according to the OSSTMM
model. Only then will the report be at the very least called thorough.

Some security testers believe that a security test is simply a “point in time” view of a defensive posture and
present the output from their tests as a “security snapshot”. They call it a snapshot because at that time the
known vulnerabilities, the known weaknesses, and the known configurations have not changed. Is this snapshot
enough? The methodology proposed in this manual will provide more than a snapshot. Risk Assessment Values
(RAVs) will enhance these snapshots with the dimensions of frequency and a timing context to the security tests.
The snapshot then becomes a profile, encompassing a range of variables over a period of time before degrading
below an acceptable risk level. In the 2.5 revision of the OSSTMM we have evolved the definition and application
of RAVs to more accurately quantify this risk level. The RAVs provide specific tests with specific time periods
that become cyclic in nature and minimize the amount of risk one takes in any defensive posture.

Some may ask: “Is it worth having a standard methodology for testing security?” Well, the quality of output and
results of a security test is hard to gauge without one. Many variables affect the outcome of a test, including the
personal style and bias of a tester. Precisely because of all these variables, it is important to define the right way
to test based on best practices and a worldwide consensus. If you can reduce the amount of bias in testing, you
will reduce many false assumptions and you will avoid mediocre results. You’ll have the correct balanced
judgment of risk, value, and the business justification of the target being tested. By limiting and guiding our
biases, it makes good security testers great and provides novices with the proper methodology to conduct the
right tests in the right areas.

The end result is that as security testers we participate and form a larger plan. We’re using and contributing to an
open-source and standardized methodology that everyone can access. Everyone can open, dissect, add to,
suggest and contribute to the OSSTMM, where all constructive criticism will continue to develop and evolve the
methodology. It just might be the most valuable contribution anyone can make to professional security testing.

We welcome your feedback.

Pete Herzog
Managing Director, ISECOM
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

9
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Scope
This is a document of security testing methodology; it is a set of rules and guidelines for which, what, and when
events are tested. This methodology only covers external security testing, which is testing security from an
unprivileged environment to a privileged environment or location, to circumvent security components, processes,

and alarms to gain privileged access. It is also within the scope of this document to provide a standardized
approach to a thorough security test of each section of the security presence (e.g. physical security, wireless
security, communications security, information security, Internet technology security, and process security) of an
organization. Within this open, peer-reviewed approach for a thorough security test we achieve an international
standard for security testing to use as a baseline for all security testing methodologies known and unknown.

The limitation to the scope of external security testing is due to the substantial differences between external to
internal and internal to internal testing. These differences are fundamentally in the access privileges, goals and
deliverables associated with internal to internal testing.

The testing towards the discovery of unknown vulnerabilities is not within the scope of this document nor is it
within the scope of an OSSTMM security test. The security test described herein is a practical and efficient test
of known vulnerabilities, information leaks, and deviations from law, industry standards, and best practices.

ISECOM requires that a security test may only be considered an OSSTMM test if it is:

• Quantifiable.
• Consistent and repeatable.
• Valid beyond the "now" time frame.
• Based on the merit of the tester and analyst not on brands.
• Thorough.
• Compliant to individual and local laws and the human right to privacy.

ISECOM does not claim that using the OSSTMM constitutes a legal protection in any court of law however it
does serve as the highest level of appropriate diligence when the results are applied to improve security in a
reasonable time frame.

Intended Audience
This manual is written for security testing professionals. Terms, skills, and processes mentioned in here may not
be clear to those not directly involved and experienced with security testing.

Designers, architects, and developers will find this manual useful to build better defense and testing tools. Many
of the tests do not have a way to be automated. Many of the automated tests do not follow a methodology or
follow one in an optimal order. This manual will address these issues.


Accreditation
A security test data sheet is required to be signed by the tester(s) and accompany all final reports to submit an
OSSTMM certified test. This data sheet available with OSSTMM 2.5. This data sheet will show which modules
and tasks had been tested to completion, not tested to completion and why, and not applicable and why. The
checklist must be signed and provided with the final test report to the client. A data sheet which indicates that
only specific Modules of an OSSTMM Section has been tested due to time constraints, project problems, or
customer refusal can NOT be said then to be a full OSSTMM test of the determined Section.

Reasons for the data sheet are:

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

10
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

• Serves as proof of thorough, OSSTMM testing.
• Makes a tester(s) responsible for the test.
• Makes a clear statement to the client.
• Provides a convenient overview.
• Provides a clear checklist for the tester.

The use of this manual in the conducting of security testing is determined by the reporting of each task and its
results even where not applicable in the final report. All final reports which include this information and the
proper, associate checklists are said to have been conducted in the most thorough and complete manner and
may include the following statement and a stamp in the report:







This test has been performed in accordance to the Open Source
Security Testing Methodology available at />
and hereby stands within best practices of security testing.


All stamps (color and b&w) are available at />

End Result
The ultimate goal is to set a standard in security testing methodology which when used results in meeting
practical and operational security requirements. The indirect result is creating a discipline that can act as a
central point in all security tests regardless of the size of the organization, technology, or defenses.


Analysis
The scope of this document does not include direct analysis of the data collected when using this manual. This
analysis is the result of understanding the appropriate laws, industry regulations, and business needs appropriate
to the particular client and the best practices and regulations for security and privacy other the client’s regions of
operation. However, analysis of some form is implied by the use of “Expected Results” within the methodology
so some analysis must be done to assure at least these expected results are met.

Internet and Network Related Terms
Throughout this manual we refer to words and terms that may be construed with other intents or meanings. This
is especially true through international translations. For definitions not associated within this table below, see the
reference of the OUSPG
Vulnerability Testing Terminology glossary available at
/>.

Application Test
The security testing of any application whether or not it’s part of the Internet
presence.
Assessment
An overview of the security presence for the estimation of time and man hours.
Automated Testing
Any kind of unattended testing that also provides analysis
Black Box
The tester has no prior knowledge of the test elements or environment
Black Hat
A hacker who is chaotic, anarchistic and breaks the law
Client
This refers to a sales recipient with whom confidentiality is enforced through a
signed non-disclosure agreement.
Competitive Intelligence
A practice legally for extracting business information from competitors.
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

11
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org

ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Containment Measures
A process for quarantine and validation
Customer
This refers to a sales recipient with whom confidentiality is only ethically implied as
no non-disclosure agreement or contract has been signed by either party.
Environment
The interactive, co-dependent state of the network in operation. Also known as
the setting
Estimate
A document of the time and man hours required for a test and may include price
Ethical Hacking
A form of penetration testing originally used as a marketing ploy but has come to
mean a pen test of all systems – where there is more than one goal, generally,
everything is a goal
Expected Results
The findings from a specific module
Firewall
The software or hardware tool for imposing an Access Control List (ACL) on a
system or network
Goal
The end result to be achieved. May sometimes be a trophy which is a finding on the
network that has potential, financial worth like a database of credit card numbers
Gray Box
The tester has some prior knowledge of the test elements or environment
Gray Hat
A hacker who is chaotic and anarchistic but does not break the law, however
the actions often lack integrity or ethics
Hacker

A clever person who has a natural curiosity, likes to know how things work and is
interested in circumvention techniques or exploiting processes to see what happens
Intrusion Detection
System (IDS)
Either passive or active, host-based or network based, this tool is designed to
monitor and sometimes stop attacks in action
Liability
The financial assurance of diligence and responsibility.
Location
The physical location.
Man Hours
This stands for the work one person does in one hour. Two man hours can be the
work two people can do in one hour OR the work one person can do in two hours
Manual Testing
A test which requires a person to input data throughout the testing process and
monitor the outcome to provide analysis
Man Weeks
This is the amount of work one person can do in one work week of 40 hours
Modules
These are viewpoints based in business security for individual OSSTMM sections
Network Scope
This refers to what a tester may legally test
Non Disclosure
Agreement
A legal contract to stop the spread of information beyond the need to know basis of
those sharing the NDA
PBX
Stands for Phone Exchange and is the central server in an organization for handling
phone lines
Penetration Test

A security test with a defined goal which ends when the goal is achieved or time
runs out
Plan
A calendar of tasks to be systematically completed in a test
Posture Assessment
The U.S. Military term for a security test
Practical
Defines security which is usable and applies to business justification
Privileges Testing
Tests where credentials are supplied to the user and permission is granted for
testing with those credentials
Privileges
Credentials and permission
RAV
Risk Assessment Values. This is the de facto risk assessment tool of the OSSTMM
which relies on cycles and degradation factors in the modules
Remote Access
This is defined as access from outside the location

Risk Assessment
In the OSSTMM this is used to describe security degradation as a comparison
marker which can quantify a level of security over time
Router
A software or hardware device for routing packets
Scope
A description of what is permitted in a security test
Scouting
Document grinding for new or unique business information and trends
Sections
In the OSSTMM, these are used to define general security viewpoints. The

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

12
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

OSSTMM uses 6 viewpoints; IT, Information, Wireless, Communications, Physical
and Process
Security Audit
A hands-on, privileged security inspection of the OS and Applications of a system.
In the U.S.A. and Canada “Auditor” is an official term and official job only to be used
by a licensed practitioner. However, in other countries, “security audit” is a common
term for a penetration or security test.
Security Presence
How security is applied to all six security sections of an organization
Security Scope
Another term for scope
Security Test
A test for the security presence. May be specified by section
Social Engineering
An active attack against processes
Tasks
Specific security tests in a module to achieve one or more of the defined Expected
Results
Time
Physical time - the fourth dimension - 24 hours a day
Usability
A step to making security understandable and efficient so as not to be intentionally
bypassed for any legitimate reason

Verification Test
A follow-up security test after all the fixes have been fixed
Visibility
Components of the security presence which can be remotely discerned
Vulnerability Test
A test for services, open ports and known vulnerabilities
White Box
The tester has full prior knowledge of the test elements or environment
White Hat
A hacker who does not break the law and acts in an ethical manner


OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

14
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Compliance
This manual was developed to satisfy the testing and risk assessment for personal data protection and
information security in the following bodies of legislation. The tests performed provide the necessary information
to analyze for data privacy concerns as per most governmental legislations and organizational best practices due
to this manual’s thorough testing stance. Although not all country statutes can be detailed herein, this manual
has explored the various bodies of law to meet the requirements of strong examples of individual rights and
privacy.

Legislation
The tests in this manual have included in design the remote auditing and testing from the outside to the inside of
the following:

Austria
• Austrian Data Protection Act 2000 (Bundesgesetz über den Schutz personenbezogener Daten
(Datenschutzgesetz 2000 - DSG 2000)) specifically requirements of §14

United States of America
• U.S. Gramm-Leach-Bliley Act (GLBA)
• Clinger-Cohen Act
• Government Performance and Results Act
• Government Paperwork Elimination Act
• FTC Act, 15 U.S.C. 45(a), Section 5(a)
• Children’s Online Privacy Protection Act (COPPA)
• ICANN Uniform Dispute Resolution Policy (UDRP)
• Anticybersquatting Protection Act (ACPA)
• Federal Information Security Management Act.
• U.S. Sarbanes-Oxley Act (SOX)
• California Individual Privacy Senate Bill - SB1386
• USA Government Information Security Reform Act of 2000 section 3534(a)(1)(A)
• Health Insurance Portability and Accountability Act of 1996 (HIPAA).
• OCR HIPAA Privacy TA 164.502E.001, Business Associates [45 CFR §§ 160.103, 164.502(e),
164.514(e)]
• OCR HIPAA Privacy TA 164.514E.001, Health-Related Communications and Marketing [45 CFR §§
164.501, 164.514(e)]
• OCR HIPAA Privacy TA 164.502B.001, Minimum Necessary [45 CFR §§ 164.502(b), 164.514(d)]
• OCR HIPAA Privacy TA 164.501.002, Payment [45 CFR 164.501]

Germany
• Deutsche Bundesdatenschutzgesetz (BDSG) Artikel 1 des Gesetzes zur Fortentwicklung der
Datenverarbeitung und des Datenschutzes from 20. December 1990, BGBl. I S. 2954, 2955, zuletzt
geändert durch das Gesetz zur Neuordnung des Postwesens und der Telekommunikation vom 14.

September 1994, BGBl. I S. 2325

Spain
• Spanish LOPD Ley orgánica de regulación del tratamiento automatizado de los datos de carácter
personal Art.15 LOPD Art. 5,
• LSSICE

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

15
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Canada
• Corporate Governance
• Provincial Law of Quebec, Canada Act Respecting the Protection of Personal Information in the Private
Sector (1993).

United Kingdom
• UK Data Protection Act 1998
• Corporate Governance

Australia
• Privacy Act Amendments of Australia Act No. 119 of 1988 as amended, prepared on 2 August 2001
incorporating amendments up to Act No. 55 of 2001. The Privacy Act 1988 (the Privacy Act) seeks to
balance individual privacy with the public interest in law enforcement and regulatory objectives of
government.
• National Privacy Principle (NPP) 6 provides that an individual with a right of access to information held
about them by an organization.

• National Privacy Principle (NPP) 4.1 provides that an organization must take reasonable steps to protect
the personal information it holds from misuse and loss and from unauthorized access, modification or
disclosure.

OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

16
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Best Practices
The tests in this manual have included in design the remote auditing and testing from the outside to the inside of
the following:

IT Information Library
Information available at /> issued by the British Office for
Government Commerce (OGC)

Germany: IT Baseline Protection Manual (IT Grundschutzhandbuch)
Issued by Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information Security
(BSI)) available at />

German IT Systems
S6.68 (Testing the effectiveness of the management system for the handling of security incidents) and
tests S6.67 (Use of detection measures for security incidents)

ISO 17799-2000 (BS 7799)
This manual fully complies with all of the remote auditing and testing requirements of BS7799 (and its
International equivalent ISO 17799) for information security testing.

GAO and FISCAM
This manual is in compliance to the control activities found in the US General Accounting Office’s (GAO)
Federal Information System Control Audit Manual (FISCAM) where they apply to network security.

SET
This document incorporates the remote auditing test from the SET Secure Electronic
Transaction(TM)Compliance Testing Policies and Procedures, Version 4.1, February 22, 2000

NIST
This manual has matched compliance through methodology in remote security testing and auditing as
per the following National Institute of Standards and Technology (NIST) publications:

• An Introduction to Computer Security: The NIST Handbook, 800-12
• Guidelines on Firewalls and Firewall Policy, 800-41
• Information Technology Security Training Requirements: A Role- and Performance-Based Model,
800-16
• DRAFT Guideline on Network Security Testing, 800-42
• PBX Vulnerability Analysis: Finding Holes in Your PBX Before Someone Else Does, 800-24
• Risk Management Guide for Information Technology Systems, 800-30
• Intrusion Detection Systems, 800-31

MITRE
This manual is CVE compatible for Risk Assessment Values
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

17
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Rules Of Engagement
Those who are partners with ISECOM or publicly claim to use the OSSTMM for security testing must uphold the
following rules of engagement. These rules define the ethical guidelines of acceptable practices in marketing and
selling testing, performing testing work, and handling the results of testing engagements. Failure to comply with
these rules may result in the inability to use the ISECOM seal on test results and the termination of the ISECOM
partnership agreement.

1. Sales and Marketing
1. The use of fear, uncertainty and doubt may not be used in the sales or marketing presentations,
websites, supporting materials, reports, or discussion of security testing for the purpose of selling
or providing security tests. This includes but is not limited to crime, facts, criminal or hacker
profiling, and statistics.
2. The offering of free services for failure to penetrate or provide trophies from the target is
forbidden.
3. Public cracking, hacking, and trespass contests to promote security assurance for sales or
marketing of security testing or security products are forbidden.
4. Performing security tests against any network without explicit written permission from the
appropriate authority is strictly forbidden.
5. The use of names of past clients who you have provided security testing for is forbidden even
upon consent of said client. This is as much for the protection of the client’s confidentiality as it
is for the security testing organization.
6. It is required to provide truthful security advice even when the advice may be to advise giving the
contract to another company. An example of this would be in explaining to a company that your
security testers should not be verifying a security implementation your organization designed and
installed rather it should be tested by an independent 3
rd
party.

2. Assessment / Estimate Delivery

1. Verifying possible vulnerable services without explicit written permission is forbidden.
2. The security testing of obviously highly insecure and unstable systems, locations, and processes
is forbidden until the security has been put in place.

3. Contracts and Negotiations
1. With or without a Non-Disclosure Agreement contract, the security tester is ethically bound to
confidentiality, non-disclosure of customer information, and security testing results.
2. The tester must always assume a limited amount of liability as per responsibility. Acceptable
limited liability is equal to the cost of service. This includes both malicious and non-malicious
errors and project mismanagement.
3. Contracts must clearly explain the limits and dangers of the security test.
4. In the case of remote testing, the contract must include the origin of the testers by telephone
numbers and/or IP addresses.
5. Contracts must contain emergency contact persons and phone numbers.
6. The contract must include clear, specific permissions for tests involving survivability failures,
denial of service, process testing, or social engineering.
7. Contracts must contain the process for future contract and statement of work (SOW) changes.

4. Scope
1. The scope must be clearly defined contractually before verifying vulnerable services.
2. The scope must clearly explain the limits of the security test.

5. Providing Test Plan
1. The test plan must include both calendar time and man hours.
2. The test plan must include hours of testing.
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

18
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org

ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.


6. Providing the rules of engagement to the client.
1. No unusual or major network changes allowed by the client during testing.
2. To prevent temporary raises in security only for the duration of the test, the client should notify
only key people about the testing. It is the client’s judgment which discerns who the key people
are however it is assumed that they will be information and policy gatekeepers, managers of
security processes, incident response, and security operations.
3. If necessary for privileged testing, the client must provide two, separate, access tokens whether
they be logins and passwords, certificates, secure ID numbers, etc. and they should be typical to
the users of the privileges being tested (no especially empty or secure accounts).
4. When performing a privileged test, the tester must first test without privileges in a black box
environment and then test again with privileges.

7. Testing
1. The testers are required to know their tools, where the tools came from, how the tools work, and
have them tested in a restricted test area before using the tools on the client organization.
2. The exploitation of Denial of Service tests may only be done with explicit permission. An
OSSTMM security test does not require one to exploit denial of service and survivability
endangering type vulnerabilities in a test. The tester is expected to use gathered evidence only
to provide a proper review of such security processes and systems.
3. Social engineering and process testing may only be performed in non-identifying statistical
means against untrained or non-security personnel.
4. Social engineering and process testing may only be performed on personnel identified in the
scope and may not include customers, partners, associates, or other external entities.
5. High risk vulnerabilities such as discovered breaches, vulnerabilities with known, high
exploitation rates, vulnerabilities which are exploitable for full, unmonitored or untraceable
access, or which may put immediate lives at risk, discovered during testing must be reported to
the customer with a practical solution as soon as they are found.

6. Distributed Denial of Service testing over the Internet is forbidden.
7. Any form of flood testing where a person, network, system, or service, is overwhelmed from a
larger and stronger source is forbidden.
8. Client notifications are required whenever the tester changes the testing plan, changes the
source test venue, has high risk findings, previous to running new, high risk or high traffic tests,
and if any testing problems have occurred. Additionally, the client should be notified with
progress updates weekly.

8. Reporting
1. Reports must include practical solutions towards discovered security problems.
2. Reports must include all unknowns clearly marked as unknowns.
3. Reports must state clearly all states of security found and not only failed security measures.
4. Reports must use only qualitative metrics for gauging risks based on industry accepted methods.
These metrics must be based on a mathematical formula and not on feelings of the analyst.

9. Report Delivery
1. The client must be notified when the report is being sent as to expect its arrival and to confirm
receipt of delivery.
2. All communication channels for delivery of report must be end to end confidential.


OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

19
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Process
The process of a security test concentrates on evaluating the following areas which in turn reflect upon the

security presence which is the defined environment for security testing. These we refer to as the Security
Dimensions:

Visibility
Visibility is what can be seen, logged, or monitored in the security presence both with and without the aid of
electronic devices. This includes, but is not limited to, radio waves, light beyond the visible spectrum,
communication devices such as telephones, GSM, and e-mail, and network packets such as TCP/IP.

Access
Access is an entry point into the security presence. An access point need not be physical barrier. This can
include, but is not limited to, a web page, a window, a network connection, radio waves, or anything in which a
location supports the definition of quasi-public or where a computer interacts with another computer within a
network. Limiting access means denying all except what is expressly permitted financially and in best practices.

Trust
Trust is a specialized pathway in regards to the security presence. Trust includes the kind and amount of
authentication, non-repudiation, access control, accountability, confidentiality, and integrity between two or more
factors within the security presence.

Authentication
Authentication is the measure for which every interaction in the process is privileged.

Non-repudiation
Limited or non-repudiation provides assurance that no person or system responsible for the interaction can deny
involvement in the interaction.

Confidentiality
Confidentiality is the assurance that only the intended systems or parties of specific communication in a process
may have access to the privileged information contained in the process.

Privacy
Privacy is that the process itself is known only between intended systems or parties.

Authorization
Authorization is the assurance that the process has a reason or business justification and is managed by a
responsible party providing privilege to systems or parties.

Integrity
Integrity is the assurance that the process has finality and cannot be changed, continued, redirected, or reversed
without it being known to the systems or parties involved.

Safety
Safety is the means of which a process cannot harm other systems, parties or other processes even through
complete failure.

Alarm
Alarm is the timely and appropriate notification of activities that violate or attempt to violate any of the other
security dimensions. In most security breaches, alarm is often the single process which initiates further
consequences.
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

20
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

The Security Map
The security map is a visual display of the security presence. The security presence is the environment of a
security test and is comprised of six sections which are the sections of this manual. The sections each overlap
and contain elements of all other sections. Proper testing of any one section must include the elements of all

other sections, direct or indirect.

The sections in this manual are:

1. Information Security
2. Process Security
3. Internet Technology Security
4. Communications Security
5. Wireless Security
6. Physical Security

Physical
Security
Information
Security
Internet Technology
Security
Communications
Security
Wireless
Security
Process Security
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

21
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Security Map Module List

The module list of the security map are the primary elements of each section. Each module must further include
all of the Security Dimensions which are integrated into tasks to be completed. To be said to perform an
OSSTMM security test of a particular section, all the modules of that section must be tested and of that which the
infrastructure does not exist for said Module and cannot be verified, will be determined as NOT APPLICABLE in
the OSSTMM Data Sheet inclusive with the final report.

5. Wireless Security Testing
1. Posture Review
2. Electromagnetic Radiation (EMR) Testing
3. 802.11 Wireless Networks Testing
4. Bluetooth Networks Testing
5. Wireless Input Device Testing
6. Wireless Handheld Testing
7. Cordless Communications Testing
8. Wireless Surveillance Device Testing
9. Wireless Transaction Device Testing
10. RFID Testing
11. Infrared Testing
12. Privacy Review




OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

22
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Risk Assessment
Risk assessment is maintained by both the tester and the analyst for all data gathered to support a valid
assessment through non-privileged testing. This implies that if too little or improper data has been gathered then
it may not be possible to provide a valid risk assessment and the tester should therefore rely on best practices,
the client’s industry regulations, the client’s business justifications, the client’s security policy, and the legal issues
for the client and the client’s regions for doing business.

Risk Evaluation

Risk means that limits in the security presence will have a detrimental effect on people, culture information,
processes, business, image, intellectual property, legal rights, or intellectual capital. This manual maintains four
dimensions in testing for a minimal risk state environment:

1. Safety

All tests must exercise concern for worst case scenarios at the greatest expenses. This requires the
tester to hold above all else the regard for human safety in physical and emotional health and
occupation.

2. Privacy

All tests must exercise regard for the right to personal privacy regardless of the regional law. The ethics
and understanding for privacy are often more advanced then current legislation.

3. Practicality

All tests must be engineered for the most minimal complexity, maximum viability, and deepest clarity.

4. Usability

All tests must stay within the frame of usable security. That which is most secure is the least welcoming
and forgiving. The tests within this manual are performed to seek a usable level of security (also known
as practical security).


OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

23
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

“Perfect” Security

In risk assessment, the OSSTMM applies the technique of “Perfect Security”. In Perfect Security, the tester and
analyst gauge the client as to what would be perfect security. This is countered with the Posture Review, which is
best practices, the client’s industry regulations, the client’s business justifications, the client’s security policy, and
the legal issues for the client and the client’s regions for doing business. The result is Perfect Security for that
client. The tester and analyst then provide a gap analysis between the current state of security with Perfect
Security.

Simple best practices as defined as a theoretical towards Perfect Security:

Wireless

• Usability of security features should be a strength.
• Quarantine and verify all wireless devices before accepting.
• Assure business justifications for all wireless devices.
• Maintain established limits of wireless signal strength and distance.
• Limit trusts (to systems and users).

• Encrypt all traffic.
• Allow only accessibility with accountability.
• Layer the security.
• Treat wireless devices as separate networks from established ones.
• Trigger it to alarm on failed or duplicate account access.
• Monitor and log accessibility from all non-voice communication traffic.
• Disallow and limit unauthorized bridging from wireless to wired.
• Decentralize nodes.

Internet Gateway and Services

• No unencrypted remote access.
• No unauthenticated remote access.
• Restrictions deny all and allow specifically.
• Monitor it all and log it.
• Decentralize.
• Limit Inter-system trust.
• Quarantine all inputs and validate them.
• Install only the applications / daemons necessary.
• Layer the security.
• Invisible is best- show nothing except the service itself.
• Simplicity prevents configuration errors.

Mobile Computing

• Quarantine all incoming network and Internet traffic.
• No unencrypted remote access.
• No unauthenticated remote access.
• Encrypt accordingly.
• Install only the applications / daemons necessary.

• Invisible is best- no running services.
• BIOS passwords required.
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

24
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

• Security training for best practices and recognizing security issues is required for users and helpdesks.

Applications

• Usability of security features should be a strength.
• Assure business justifications for all inputs and outputs in the application.
• Quarantine and validate all inputs.
• Limit trusts (to systems and users).
• Encrypt data.
• Hash the components.
• All actions occur on the server side.
• Layer the security.
• Invisible is best- show only the service itself.
• Trigger it to alarm.

People

• Decentralized authority.
• Personal responsibility.
• Personal security and privacy controls.
• Accessible only through gateway personnel.

• Trained in defined legalities and ethics from security policies.
• Limited, need-to-know access to information and infrastructure.


OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

25
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

Risk Assessment Values
Integrated with each module are Risk Assessment Values (RAVs) which are defined as the degradation of
security (or escalation of risk) over a specific life cycle based on best practices for periodic testing. The
association of risk levels with cycles has proven to be an effective procedure for security metrics.

The concepts of security metrics in this manual are to:

• Establish a standard time cycle for testing and retesting to
• Maintain a measurable level of risk based on
• The degradation of security (escalation of risk) which occurs naturally, with time and
• The ability to measure risk with consistency and detail
• Both before and after testing.

Unlike conventional risk management, the RAVs operate purely on the application of security within an
organization. They take into consideration the controls such as the processes, politics, and procedures by
operating in parallel with the testing methodology. While the testing methodology does examine these controls
sometimes in an indirect nature, the actual controls do not interest the tester rather it is the application of these
controls that determine the results of a security test. A well written policy which is not followed will have no effect
on actual security.

RAVs are determined mathematically by the following factors:
1. The degrees of degradation of each separate module from point of optimum health measured from a
theoretical maximum of 100% for risk management purposes,
2. The cycle which determines the maximum length of time it takes for the degradation to degrade its full
percentage value (degradation) based on security best practices and consensus,
3. The influence of other modules performed or not performed,
4. Weights established by the Security Dimensions,
5. The type of risk as designated by the OSSTMM Risk Types and whether the risk has been:
a. Identified but not investigated or investigation provided varied and unclear results,
b. Verified as in clearly positive or exploitable, or,
c. Not applicable in that it does not exist because the infrastructure or that security mechanism
does not exist.


Risk Types

Whereas the risk types appear to be subjective, the classification of risks to the following types is in actuality
mostly objective when following the framework of the OSSTMM. Future versions will assure this is CVE
compatible.

Vulnerability
A flaw inherent in the security mechanism itself or which can be reached through security safeguards that allows
for privileged access to the location, people, business processes, and people or remote access to business
processes, people, infrastructure, and/or corruption or deletion of data.

A vulnerability may be a metal in a gate which becomes brittle below 0º C, a thumbprint reader which will grant
access with rubber fingers, an infrared device that has no authentication mechanism to make configuration
changes, or a translation error in a web server which allows for the identification of a bank account holder through
an account number.

Weakness
OSSTMM WIRELESS 2.9.1 - The Open Source Security Testing Methodology Manual
29 October 2003

26
Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

A flaw inherent in the platform or environment of which a security mechanism resides in, a misconfiguration,
survivability fault, usability fault, or failure to meet the requirements of the Security Posture.
A weakness may be a process which does not save transaction data for the legal time limit as established by
regional laws, a door alarm which does not sound if the door is left open for a given amount of time, a firewall
which returns ICMP host unreachable messages for internal network systems, a database server that allows
unfiltered queries, or an unlocked, unmonitored entrance into a otherwise secured building.

Information Leak
A flaw inherent in the security mechanism itself or which can be reached through security safeguards which allow
for privileged access to privileged or sensitive information concerning data, business processes, people, or
infrastructure.

An information leak may be a lock with the combination available through audible signs of change within the
lock’s mechanisms, a router providing SNMP information about the target network, a spreadsheet of executive
salaries for a private company, the private mobile telephone number of the marketing staff, or a website with the
next review date of an organization’s elevators.

Concern
A security issue which may result from not following best practices however does not yet currently exist as a
danger.

A concern may be FINGERD running on a server for an organization that has no business need for the FINGER
service, a guarded doorway which requires the watchman to leave the door to apprehend a trespasser with no
new guard to replace the one who left and maintain a presence at the door, or employees who sit with their
monitors and whiteboards viewable from outside the perimeter security.

Unknowns
An unidentifiable or unknown element in the security mechanism itself or which can be reached through security
safeguards that currently has no known impact on security as it tends to make no sense or serve any purpose
with the limited information the tester has.

An unknown may be an unexpected response possibly from a router in a network that is repeatable and may
indicate network problems, an unnatural radio frequency emanating from an area within the secure perimeter
however offers no identification or information, or a spreadsheet which contains private data about a competing
company.


The following table provides the values for the Risk Assessment Values.

Verified Identified Not Applicable
Vulnerability
3.2 1.6 0.4
Weakness
1.6 0.8 0.3
Concern
0.8 0.4 0.2
Information Leak
0.4 0.2 0.1
Unknown
0.2 0.1