[REVS] OSSTMM - Open Source Security Testing Methodology Manual
From: SecuriTeam (support_at_securiteam.com)
To: firstname.lastname@example.org Date: 27 Aug 2003 10:23:24 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
- - - - - - - - -
OSSTMM - Open Source Security Testing Methodology Manual
The Open Source Security Testing Methodology Manual (OSSTMM) is an open
standard method for performing security tests. Since it's inception in
January 2001, the OSSTMM has become the most widely used, peer-reviewed,
comprehensive security testing methodology in existence. While other
methodologies and "best practices" attack security testing from a 50,000
foot view, the OSSTMM focuses on the technical details of exactly which
items need to be tested, what to do during a security test, and when
different types of security tests should be performed. The OSSTMM provides
testing methodologies for the following six security areas: Information
Security, Process Security, Internet Technology Security, Communications
Security, Wireless Security, and Physical Security.
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. Moreover, through the thoroughness of its application
you will find a revolutionary approach to testing security.
Make no mistake - 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 influence 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 is
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 period. Only
then will the tester have addressed the test according to the OSSTMM
model. Only then can 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, in addition, the known
configurations have not changed. However, 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 scattershot, encompassing a range of variables
over a period before degrading below an acceptable risk level. Starting
with 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 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 will 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 result is that as security testers we participate and form a larger
plan. We are 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
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: email@example.com
In order to subscribe to the mailing list, simply forward this email to: firstname.lastname@example.org
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.