You are on page 1of 213

Designed for e-book readers or double-sided printing.

OSSTMM 3 The Open Source Security Testing Methodology Manual


This manual provides test cases that result
in verified facts. These facts provide
actionable information that can
measurably improve your operational
security. By using the OSSTMM you no
longer have to rely on general best
practices, anecdotal evidence, or
superstitions because you will have
verified information specific to your needs
on which to base your security decisions.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1
OSSTMM 3 The Open Source Security Testing Methodology Manual
nstructions
This is a methodology to test the operational security o( physical locations! human interactions! and all
(orms o( communications such as 'ireless! 'ired! analog! and digital. Those 'ho 'ant to *ump right into
testing 'hile using it may (ind the (ollo'ing +uic,-start in(ormation help(ul.
!uic" Start
To start ma,ing an %##T&& test you 'ill need to trac, 'hat you test -the targets.! ho' you test them -the
parts o( the targets tested and not the tools or techni+ues used.! the types o( controls discovered! and
'hat you did not test -targets and parts o( the targets.. Then you may conduct the test as you are
accustomed to 'ith the ob*ective o( being able to ans'er the +uestions in the #ecurity Test Audit /eport
-#TA/. available at the end o( this manual or as its o'n document. The #TA/ gives the speci(ic test
in(ormation on the state o( the scope (or the bene(its o( having a clear statement o( the security metrics
and details (or comparisons 'ith previous security tests or industry test averages. &ore details on the
re+uired in(ormation (or the #TA/ is available throughout this manual and can be re(erenced as needed.
As you may see! ta,ing this approach means that very little time is re+uired in addition to a standard test
and the (ormali0ation o( the report. "t has been reported that this methodology actually reduces testing
and reporting time due to the e((iciencies introduced into the process. There should be no time or
(inancial reason to avoid using the %##T&& and no unreasonable restrictions are made to the tester.
#pgrading from Older $ersions
"( you are (amiliar 'ith the %##T&& 2.1 series then you 'ill (ind that the methodology has completely
changed. The ne' rav provides a (actual attac, sur(ace metric that is much more accurate (or
measuring the susceptibility to attac,s. There are many other changes and enhancements as 'ell but the
primary (ocus has been to move a'ay (rom solution-based testing 'hich assumes speci(ic security
solutions 'ill be (ound in a scope and are re+uired (or security -li,e a (ire'all.. Another change you may
notice is that there is no' a single security testing methodology (or all channels) 2uman! 3hysical! 4ireless!
Telecommunications! and Data Net'or,s.
The rav in(ormation (rom 2.1 to 3.0 is incompatible. Those 'ith early 3.0 dra(t rav -prior to /C 2. 'ill re+uire
that the values be re-calculated using this (inal attac, sur(ace calculation 'hich is available as a
spreadsheet calculator at http)55'''.isecom.org5ravs. 3revious %##T&& security metrics measured ris,
'ith degradation ho'ever this version does not. "nstead! the (ocus no' is on a metric (or the attac,
sur(ace -the e1posure. o( a target or scope. This allo's (or a (actual metric that has no bias or opinion li,e
ris, does. %ur intention is to eventually eliminate the use o( ris, in areas o( security 'hich have no set price
value o( an asset -li,e 'ith people! personal privacy! and even (luctuating mar,ets. in (avor o( trust
metrics 'hich are based completely on (acts.
&uch o( the terminology has changed in this version to provide a pro(essional de(inition o( that 'hich can
actually be created or developed. This is most notable in de(initions (or security and sa(ety 'hich ta,e
more speci(ic and concrete meanings (or operations 'ithin.
#ince so much has changed (rom previous versions! as this is a completely re-'ritten methodology! 'e
recommend you read through it once be(ore using it. 6urther help is available at http)55'''.isecom.org.
Courses to help you ma,e thorough and proper security tests! systems! and processes are available
through "#$C%& and 'ill help you get the most o( the %##T&&.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
$ersion nformation
The current version o( the %pen #ource #ecurity Testing &ethodology &anual -%##T&&. is 3.02. This
version o( the %##T&& ends the 2.1 series. All %##T&& versions prior to 3.0 including 3.0 release
candidates -/C versions. are no' obsolete.
The original version 'as published on &onday! December 7! 2000. This current version is published on
Tuesday! December 8! 200.
&bout this 'ro(ect
This pro*ect is maintained by the "nstitute (or #ecurity and %pen &ethodologies -"#$C%&.! developed in
an open community! and sub*ected to peer and cross-disciplinary revie'. This pro*ect! li,e all "#$C%&
pro*ects! is (ree (rom commercial and political in(luence. 6inancing (or all "#$C%& pro*ects is provided
through partnerships! subscriptions! certi(ications! licensing! and case-study-based research. "#$C%& is a
registered non-pro(it organi0ation and established in Ne' 9or,! :#A and in Catalonia! #pain.
Local Support
/egional "#$C%& o((ices may be available in your area (or language and business support. 6ind the
"#$C%& 3artner in your area at http)55'''.isecom.org5tp.
Community Support
/eader evaluation o( this document! suggestions (or improvements! and results o( its application (or (urther
study are re+uired (or (urther development. Contact us at http)55'''.isecom.org to o((er research support!
revie'! and editing assistance.
Print Edition
The print edition o( this manual is available (or purchase at the "#$C%& 'ebsite.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 3
OSSTMM 3 The Open Source Security Testing Methodology Manual
)estrictions
Any in(ormation contained 'ithin this document may not be modi(ied or sold 'ithout the e1press consent o(
"#$C%&. Commercial selling o( this document or the in(ormation 'ithin this document! including the
methodology applied 'ithin a tool! so(t'are! or chec,list may N%T be provided 'ithout e1plicit permission
(rom "#$C%&.
This research document is (ree to read! (ree to re-distribute non-commercially! and (ree to +uote or apply in
academic or commercial research! and (ree to use or apply in the (ollo'ing commercial engagements)
testing! education! consulting! and research.
This manual is licensed to "#$C%& under Creative Commons 3.0 Attribution-NonCommercial-NoDerivs and the
%pen &ethodology ;icense 3.0.
The "#$C%& logo is an o((icial Trademar, and may not be used or reproduced commercially 'ithout consent
(rom "#$C%&. The %##T&& hummingbird graphic is copyright &arta <arcel= >ordan! licensed to "#$C%& and
may not be used or reproduced commercially 'ithout permission.
As a collaborative! open pro*ect! the %##T&& is not to be distributed by any means (or 'hich there is
commercial gain either by itsel( or as part o( a collection. As a standard! there may be only one! o((icial
version o( the %##T&& at any time and that version is not to be altered or (or,ed in any 'ay 'hich 'ill
cause con(usion as to the purpose o( the original methodology. There(ore! no derivation o( the %##T&& is
allo'ed.
As a methodology! the %##T&& is protected under the %pen &ethodology ;icense 3.0 'hich applies the
protection as that granted to Trade #ecrets. 2o'ever! 'here a Trade #ecret re+uires su((icient e((ort
re+uirements to retain a secret! the %&; re+uires that the user ma,e su((icient e((ort to be as transparent as
possible about the application o( the methodology. There(ore! use and application o( the %##T&& is
considered as acceptance o( the responsibility o( the user to meet the re+uirements in the %&;. There are no
commercial restrictions on the use or application o( the methodology 'ithin the %##T&&. The %&; is available
at the end o( this manual and at http)55'''.isecom.org5oml.
&ny and all licensing *uestions or re*uests should be directed to S+,OM.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
'rimary .evelopers
"#$C%&
Marta Barcel/, .irector, S+,OM Board Member
'ete 0er1og, .irector, OSSTMM 'ro(ect 2ead, S+,OM Board Member
'rimary ,ontributors
The (ollo'ing people are listed alphabetically by company. $ach has been a substantial in(luence to the
development o( this %##T&&.
?&ediaservice.net! "taly
)aoul ,hiesa, S+,OM Board Member
Marco valdi
3abio 4uasconi
3abri1io Sensibile
ad&$/"Tia @mb2! @ermany
0ei"o )udolph, S+,OM Board Member
&aron Brown
<ell Canada! Canada
)ic" Mitchell
<lue #ecure ;imited! Ne' Aealand
)ichard 3eist, S+,OM Board Member
Dreamlab Technologies ;td.! #'it0erland
5ic" Mayencourt, S+,OM Board Member
#rs B. 6eber
&drian 4schwend
Thomas Bader
"#$C%&! :#A
)obert +. 2ee, S+,OM Board Member
@C3 @lobal! &e1ico
3rancisco 'uente
BCT Data! "nc.! :#A
7im Truett, S+,OM Board Member
;a #alle :/;! #pain
8aume &bella, S+,OM Board Member
;ab0C D %utpost28! Netherlands
,or )osielle
%neConsult @mb2! #'it0erland
,hristoph Baumgartner, S+,OM Board Member
%utpost28! #'eden
8ac" ,. 2ouis
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 9
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ontributors, )eviewers, and &ssistants
A huge and sincere than,s to all those 'ho have applied their e((orts to ma,ing this %##T&& version
happen. 4ithout you! there 'ould not have been the no-nonsense discussions that made this manual.
A special thanks to Jack C. Louis (Jan 5, 1977 - March 15, 2009), a rilliant securit!
researcher, an a"a#in$ person, an% a"on$ the &irst '()C*M certi&ie% *+(, an% *+(A
,rainers. -e at '()C*M $reatl! appreciate all !our e&&orts an% here! let the" li.e on
as a ench"ark /e hope inspire other securit! pro&essionals to attain. 0our
contriutions to the *((,MM shall ne.er e &or$otten. ,hank !ou1
,ontributions
Alberto 3errone! ?&ediaservice.net! "taly
&artin Dion! Above #ecurity! Canada
;ars 2eidelberg! ad&$/"Tia @mb2! @ermany
&artin 3a*on,! ad&$/"Tia @mb2! @ermany
Dru ;avigne! Carleton :niversity! Canada
Todd A. >acobs! Codegnome! :#A
3hil /obinson! Digital Assurance! :B
3hilipp $gli! Dreamlab Technologies ;td.! #'it0erland
Daniel 2ulliger! Dreamlab Technologies ;td.! #'it0erland
#imon Nussbaum! Dreamlab Technologies ;td.! #'it0erland
#ven Eetsch! Dreamlab Technologies ;td.! #'it0erland
Colby Clar,! @uidance #o(t'are! :#A
Andy &oore! 2ere(ord "n(o#ec! :B
3eter Blee! "<&! @ermany
Daniel 6ernande0 <leda! "nternet #ecurity Auditors! #pain
>ay Abbott! %utpost28 5 ;ab0C! Netherlands
#teve Armstrong! ;ogically #ecure! :B
#imon 4ep(er! %neConsult @mb2! #'it0erland
&anuel Bruc,er! %neConsult @mb2! #'it0erland
>an Alsen0! %neConsult @mb2! #'it0erland
Tobias $llenberger! %neConsult @mb2! #'it0erland
#haun Copplestone! The 4atchers "nc.! Canada
"an ;atter! 3ure 2ac,ing! Australia
Ty &iller! 3ure 2ac,ing! Australia
>ordi AndrF i EallverdG! ;a Cai1a! #pain
>im <ro'n! Thrupoint! :#A
Chris @ri((in! "#$C%&! :#A
Charles ;e @rand! :#A
Dave ;auer! :#A
>ohn 2o((oss! &innesota #tate Colleges and :niversities! :#A
&i,e &ooney! :#A
3ablo $ndres! Eene0uela 5 @ermany
>eremy 4ilde! compliancetutorial.com! :B 5 6rance
/ob >. &ei*er! Netherlands
&i,e #impson! :#A 5 @ermany
)eview and &ssistance
@unnar 3eterson! Arctec @roup! :#A
Dieter #arra0yn! Ascure nv.! <elgium
<ob Davies! <ell Canada! Canada
>osep /uano! Capside! #pain
Adrien de <eaupre! Canada
Clement Dupuis! CCCure! Canada
Armand 3uccetti! C$A! 6rance
>ose ;uis &artin &as! davinci Consulting! #pain
#ylvie /einhard! Dreamlab Technologies ;td.! #'it0erland
/aphaHl 2aberer-3roust! Dreamlab Technologies ;td.! #'it0erland
>osh Aelonis! Dyad #ecurity! :#A
<ora Turan! $rnst and 9oung! Tur,ey
;uis /amon @arcia #olano! @C3 @lobal! &e1ico
>ohn Thomas /egney! @edas! #pain
&i,e Aiello! @oldman #achs! :#A
Dir, Buhlmann! 23! :B
>ohn /ittinghouse! 2ypersecurity ;;C! :#A
&assimiliano @ra0iani! ""#6A! "taly
>ose Navarro! "ndiseg! #pain
Timothy 3hillips! "n(ormation Assurance #olutions! :#A
>oan /ui0! ;a #alle :/;! #pain
EI,tu 3ons i Colomer! ;a #alle :/;! #pain
/oman Drahtmueller! Novell! @ermany
2ernJn &arcelo /acciatti! #"C;A<#! Argentina
Tom <ro'n! /4$ #hared #ervices "#! :B
&arcel @erardino! #entinel! Dominican /epublic
&anuel Atug! #/C #ecurity /esearch D Consulting @mb2! @ermany
Torsten Du'e! #:#$! @ermany
Ale1ander >. 2er0og! :#A
Dre11 ;aggui! ;DA "nc! 3hilippines
/uud van der &eulen! Netherlands
Chris @at(ord! 2ac,;abs! Australia
4im /emes! <elgium
@ary A1ten! :B 5 #pain
Alan Tang! :B
>ason 4olo0! :#A
>ohn /. &oser! :#A
Tom %KConnor! "reland
&i,e Eas+ue0! City o( &esa! :#A
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
3oreword
#ecurity veri(ication used to re+uire a cross-disciplinary specialist 'ho understood security as deeply as
they understood the rules! la's! underlying premise! operation! process! and technology involved.
#ometime later! third party veri(ication came (rom the popular notion o( builder blindness that says those
closest to the target 'ill generally and usually involuntarily miss the most problems. This became the
standard procedure (or a 'hile and is still 'idely regarded as true even though it actually means that an
outsider 'ith less ,no'ledge o( the target is supposedly more capable o( understanding that target than
the operator. At some point! the pendulum began to s'ing bac, the other 'ay. 4hether this happened
(or either e((iciency or economic reasons is unclear! but it has brought about an important shi(t to provide
the operators 'ith security testing ability. "t has led to simpli(ied (rame'or,s! so(t'are! chec,lists! tool ,its!
and many other 'ays to ma,e security testing easy enough that anyone can do it. ThatKs a good thing.
:n(ortunately! there is no comple1 sub*ect (or 'hich the simpli(ication process is not itsel( comple1 nor the
end result signi(icantly less than the 'hole. This means that to ma,e a security testing solution simple
enough (or non-e1perts to e1ecute! the solution re+uires a comple1 bac,-end to collect the data
according to preconceived rules. This assumes that operations al'ays run according to design and
con(iguration. "t also assumes the solution developer has ta,en into account all the possibilities (or 'here!
'hat! and ho' data can be gathered. 6urthermore it assumes that the data gathered can be properly
sorted into a uni(orm (ormat (or comparison and rule-based analysis. None o( those tas,s are simple.
Assuming that can be done! it 'ould still re+uire an e1haustive database o( possibilities (or the numerous
representations o( security and layers o( controls to deduce security problems. 4hile minimi0ing (alse
positives through correlations based on the rules! la's! underlying premise! operation! process! and
technology involved. This solution could then be able to provide a clear! concise report and metric. This
solution 'ould need to have more than *ust the (rame'or,! so(t'are! chec,list! or tool,it 'hich it
producesL it 'ould need a methodology.
A security methodology is not a simple thing. "t is the bac,-end o( a process or solution 'hich de(ines 'hat
or 'ho is tested as 'ell as 'hen and 'here. "t must ta,e a comple1 process and reduce it into elemental
processes and su((iciently e1plain the components o( those processes. Then the methodology must
e1plain the tests (or veri(ying 'hat those elemental processes are doing 'hile they are doing! moving!
and changing. 6inally! the methodology must contain metrics both to assure the methodology has been
carried out correctly and to comprehend or grade the result o( applying the methodology. #o! ma,ing a
security testing methodology is no small (eat.
4ith each ne' version o( the %##T&& 'e get closer to e1pressing security more satis(actorily than
previous versions. "tKs not that this %##T&& 3 promotes revolutionary ideas but rather it applies many ne'
pragmatic concepts 'hich 'ill improve security. 4e are coming ever closer to truly understanding 'hat
ma,es us sa(e and secure.
6or a chance o( having this enlightenment! " 'ant to than, all the contributors to the %##T&&! the
"#$C%& team! all the "#$C%& certi(ied students 'ho care about the right 'ay to do security testing! all
those teaching 2ac,er 2ighschool to the ne1t generation! all supporters o( the "#$C%& pro*ects including
the "#$C%& Training 3artners! "#$C%& ;icensed Auditors! and (inally my very patient and supportive 'i(e
'ho understands ho' important this is to me and to the 'orld 'e need to improve.
Than, you all (or all your help.
3ete 2er0og
Director! "#$C%&
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ;
OSSTMM 3 The Open Source Security Testing Methodology Manual
Table of ,ontents
nstructions....................................................................................................................................................................%
Muic, #tart...............................................................................................................................................................2
:pgrading (rom %lder Eersions.............................................................................................................................2
Eersion "n(ormation.................................................................................................................................................3
About this 3ro*ect....................................................................................................................................................3
/estrictions...............................................................................................................................................................8
3rimary Developers.................................................................................................................................................N
3rimary Contributors...............................................................................................................................................N
Contributors! /evie'ers! and Assistants...............................................................................................................C
3oreword ......................................................................................................................................................................;
ntroduction................................................................................................................................................................11
3urpose..................................................................................................................................................................3
Document #cope.................................................................................................................................................3
;iability....................................................................................................................................................................3
Certi(ication and Accreditation.........................................................................................................................8
/elated 3ro*ects....................................................................................................................................................O
,hapter 1 < 6hat =ou 5eed to 7now......................................................................................................................%>
. #ecurity.............................................................................................................................................................23
.2 Controls............................................................................................................................................................28
.3 "n(ormation Assurance %b*ectives...............................................................................................................2O
.8 ;imitations........................................................................................................................................................27
.N Actual #ecurity................................................................................................................................................3
.C Compliance....................................................................................................................................................3
,hapter % < 6hat =ou 5eed to .o..........................................................................................................................33
2. De(ining a #ecurity Test..................................................................................................................................33
2.2 #cope...............................................................................................................................................................38
2.3 Common Test Types.......................................................................................................................................3C
2.8 /ules %( $ngagement....................................................................................................................................37
2.N The %perational #ecurity Testing 3rocess....................................................................................................8
2.C 6our 3oint 3rocess...........................................................................................................................................83
2.O The Tri(ecta......................................................................................................................................................88
2.7 $rror 2andling..................................................................................................................................................8C
2.P Disclosure.........................................................................................................................................................N
,hapter 3 < Security &nalysis...................................................................................................................................93
3. Critical #ecurity Thin,ing.................................................................................................................................N8
3.2 /ecogni0e the %p#ec &odel........................................................................................................................NC
3.3 ;oo, (or 3attern &atching as a #ign o( $rrors..............................................................................................NO
3.8 Characteri0e the /esults................................................................................................................................NO
3.N ;oo, (or #igns o( "ntuition................................................................................................................................N7
3.C Transparent /eporting....................................................................................................................................NP
,hapter - < Operational Security Metrics..............................................................................................................:%
8. @etting to Bno' the /av...............................................................................................................................C3
8.2 2o' to &a,e a /av........................................................................................................................................CO
8.3 Turning Test /esults into an Attac, #ur(ace &easurement........................................................................O0
8.8 The %perational #ecurity 6ormula................................................................................................................OP
8.N The Controls 6ormula......................................................................................................................................70
8.C The ;imitations 6ormula..................................................................................................................................73
8.O The Actual #ecurity 6ormula..........................................................................................................................7N
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 9 < Trust &nalysis.........................................................................................................................................?;
N. :nderstanding Trust .......................................................................................................................................7O
N.2 6allacies in Trust...............................................................................................................................................7P
N.3 The Ten Trust 3roperties..................................................................................................................................P0
N.8 The Trust /ules..................................................................................................................................................P
N.N Applying Trust /ules to #ecurity Testing........................................................................................................P8
,hapter : < 6or" 3low..............................................................................................................................................@:
C. &ethodology 6lo'..........................................................................................................................................PO
C.2 The Test &odules ............................................................................................................................................PP
C.3 %ne &ethodology........................................................................................................................................03
,hapter ; A 0uman Security Testing......................................................................................................................1>9
,hapter ? A 'hysical Security Testing....................................................................................................................1%>
,hapter @ A 6ireless Security Testing....................................................................................................................13?
,hapter 1> A Telecommunications Security Testing............................................................................................191
,hapter 11 A .ata 5etwor"s Security Testing.......................................................................................................1:;
,hapter 1% A ,ompliance......................................................................................................................................1?9
/egulations..........................................................................................................................................................7C
,hapter 13 < )eporting with the ST&)...................................................................................................................1@%
,hapter 1- < 6hat =ou 4et....................................................................................................................................%>-
The &Qbius De(ense...........................................................................................................................................20N
@et 4hat 4e Need............................................................................................................................................20C
,hapter 19 < Open Methodology 2icense...........................................................................................................%>?
The %&; 3............................................................................................................................................................207
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org @
OSSTMM 3 The Open Source Security Testing Methodology Manual
n art, the end result is a thing of beauty,
whereas in science, the means of
reaching the end result is a thing of
beauty. 6hen a security test is an art then
the result is unverifiable and that
undermines the value of a test. One way
to assure a security test has value is to
"now the test has been properly
conducted. 3or that you need to use a
formal methodology. The OSSTMM aims to
be it.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
ntroduction
The %pen #ource #ecurity Testing &ethodology &anual -%##T&&. provides a methodology (or a
thorough security test! herein re(erred to as an %##T&& audit. An %##T&& audit is an accurate
measurement o( security at an operational level that is void o( assumptions and anecdotal evidence. As
a methodology it is designed to be consistent and repeatable. As an open source pro*ect! it allo's (or
any security tester to contribute ideas (or per(orming more accurate! actionable! and e((icient security
tests. 6urther it allo's (or the (ree dissemination o( in(ormation and intellectual property.
#ince its start at the end o( 2000! the %##T&& +uic,ly gre' to encompass all security channels 'ith the
applied e1perience o( thousands o( revie'ers. <y 200N! the %##T&& 'as no longer considered *ust a best
practices (rame'or,. "t had become a methodology to assure security 'as being done right at the
operational level. As security audits became mainstream! the need (or a solid methodology became critical. "n
200C! the %##T&& changed (rom de(ining tests based on solutions such as (ire'all tests and router tests to a
standard (or those 'ho needed a reliable security test rather than *ust a compliance report (or a speci(ic
regulation or legislation.
#ince environments are signi(icantly more comple1 than in years past due such things as remote operations!
virtuali0ation! cloud computing! and other ne' in(rastructure types! 'e can no longer thin, in simplistic tests
meant only (or des,tops! servers! or routing e+uipment. There(ore! 'ith version 3! the %##T&& encompasses
tests (rom all channels - 2uman! 3hysical! 4ireless! Telecommunications! and Data Net'or,s. This also ma,es it
a per(ectly suited (or testing cloud computing! virtual in(rastructures! messaging middle'are! mobile
communication in(rastructures! high-security locations! human resources! trusted computing! and any logical
processes 'hich all cover multiple channels and re+uire a di((erent ,ind o( security test. A set o( attac, sur(ace
metrics! called ravs! provide a po'er(ul and highly (le1ible tool that can provide a graphical representation o(
state! and sho' changes in state over time. This integrates 'ell 'ith a KdashboardK (or management and is
bene(icial (or both internal and e1ternal testing! allo'ing a comparison5combination o( the t'o. Muantitative
ris, management can be done (rom the %##T&& Audit report (indings! providing a much improved result due
to more accurate! error (ree results ho'ever you 'ill (ind the proposed trust management here to be superior
to ris, management. The %##T&& includes in(ormation (or pro*ect planning! +uanti(ying results! and the rules o(
engagement (or per(orming security audits. The methodology can be easily integrated 'ith e1isting la's and
policies to assure a thorough security audit through all channels.
;egal and industry speci(ic regulations also commonly re+uire a security audit as a component o( becoming
compliant. An %##T&& audit is 'ell suited (or most all o( these cases. #peci(ic %##T&& tests can there(ore be
connected 'ith particular security standard re+uirements! ma,ing the %##T&& itsel( a 'ay to gain
compliance to those re+uirements. This applies to regulations and policies (rom physical security li,e the :#
6ederal $nergy /eserve CommissionKs ruling to pure data security e((orts such as the latest 3C"-D## and
including cross-channel re+uirements as (ound in many N"#T recommendations and in(ormation security
management speci(ications li,e "#%5"$C 2O00)200N! "#%5"$C 2O002)200N! and "#%5"$C 2O00N)2007.
"t is recommended that you read through the %##T&& once completely be(ore putting it into practice. "t
aims to be a straight-(or'ard tool (or the implementation and documentation o( a security test. 6urther
assistance (or those 'ho need help in understanding and implementing this methodology is available at
the "#$C%& 'ebsite.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 11
OSSTMM 3 The Open Source Security Testing Methodology Manual
A Short Note About Language in the OSSTMM
-hat is an au%it2 (o"e o& the /or%s use% in this %ocu"ent "a! stra! &ro" the
%e&inition !ou are &a"iliar /ith. 3e/ research o&ten re4uires up%atin$, enhancin$,
or retractin$ in&or"ation &ro" the /orl% as /e thou$ht /e ha.e kno/n it. ,his is a
nor"al occurrence an% to assist !ou /ith the chan$es, this %ocu"ent %oes tr! to
%e&ine these /or%s properl! in their ne/ conte5t. 'n this %ocu"ent, an *((,MM
au%it or 6au%it7 is the result o& the anal!sis per&or"e% a&ter an *((,MM test. ,he
person /ho per&or"s this &unction o& test an% anal!sis is re&erre% to as the (ecurit!
Anal!st or 8ust 6Anal!st7.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
'urpose
The primary purpose o( this manual is to provide a scienti(ic methodology (or the accurate
characteri0ation o( operational security -%p#ec. through e1amination and correlation o( test results in a
consistent and reliable 'ay. This manual is adaptable to almost any audit type! including penetration
tests! ethical hac,ing! security assessments! vulnerability assessments! red-teaming! blue-teaming! and so
(orth. "t is 'ritten as a security research document and is designed (or (actual security veri(ication and
presentation o( metrics on a pro(essional level.
A secondary purpose is to provide guidelines 'hich! 'hen (ollo'ed correctly! 'ill allo' the analyst to
per(orm a certi(ied %##T&& audit. These guidelines e1ist to assure the (ollo'ing)
. The test 'as conducted thoroughly.
2. The test included all necessary channels.
3. The posture (or the test complied 'ith the la'.
8. The results are measurable in a +uanti(iable 'ay.
N. The results are consistent and repeatable.
C. The results contain only (acts as derived (rom the tests themselves.
An indirect bene(it o( this manual is that it can act as a central re(erence in all security tests regardless o(
the si0e o( the organi0ation! technology! or protection.
.ocument Scope
The scope o( this document is to provide speci(ic descriptions (or operational security tests over all
operational channels! 'hich include 2uman! 3hysical! 4ireless! Telecommunications! and Data Net'or,s!
over any vector! and the description o( derived metrics. This manual only (ocuses on %p#ec and the use
o( the 'ords sa(ety and security are 'ithin this conte1t.
2iability
This manual describes certain tests 'hich are designed to elicit a response. #hould these tests cause harm
or damage! the Analyst may be liable according to the la's governing the AnalystKs location as 'ell as
the location o( the tested systems. "#$C%& ma,es no guarantee as to a harmless outcome o( any test.
Any Analyst applying this methodology cannot hold "#$C%& liable (or problems 'hich arise during
testing. "n using this methodology! the Analyst agrees to assume this liability.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 13
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ertification and &ccreditation
To produce an %##T&& certi(ied test 'hich can receive accreditation (or the operational security o( the
target! a #TA/ is re+uired to be signed by the Analyst-s. 'ho per(ormed the test. The #TA/ must also meet
the reporting re+uirements in this manual. The #TA/ can be submitted to "#$C%& (or revie' and o((icial
"#$C%& certi(ication. A certi(ied test and an accredited report does not need to sho' that this entire
manual or any speci(ic subsections 'ere (ollo'ed. "t needs only sho' 'hat 'as and 'as not tested to be
applicable (or certi(ication. -#ee Chapter C! &a,ing the #TA/ (or details and an e1ample o( a #TA/..
A certi(ied %##T&& audit provides the (ollo'ing bene(its)
- #erves as proo( o( a (actual test
- 2olds Analyst responsible (or the test
- 3rovides a clear result to the client
- 3rovides a more comprehensive overvie' than an e1ecutive summary
- 3rovides understandable metrics
Test revie'! certi(ication! and accreditation by "#$C%& or an accredited third party is sub*ect to (urther
conditions and operations (ees. Contact "#$C%& (or (urther in(ormation.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Certifications for Professionals
Anyone 'ho uses this methodology (or security testing and analysis and completes a valid #TA/ is said to have
per(ormed an %##T&& audit. 2o'ever! individual certi(ication is also available through "#$C%& (or the applied
s,ills in pro(essional security testing! analysis! methodical process! and pro(essional standards as outlined in the
%##T&& /ules o( $ngagement. "#$C%& is the authority (or a variety o( s,ill and applied ,no'ledge certi(ication
e1ams based on %##T&& research. Classes and the o((icial e1ams are provided by certi(ied training partners in
various regions around the 'orld. The current certi(ication e1ams available are)
OPST
The %##T&& 3ro(essional #ecurity Tester proves a candidate has the s,ill and
,no'ledge to per(orm accurate D e((icient security tests on data net'or,s.
http)55'''.opst.org
OPSA
The %##T&& 3ro(essional #ecurity Analyst proves a candidate can apply the
principles o( security analysis and attac, sur(ace metrics accurately D e((iciently.
http)55'''.opsa.org
OPSE
The %##T&& 3ro(essional #ecurity $1pert proves a candidate has learned all the
security concepts 'ithin the most current! publicly available %##T&& and the
bac,ground to the research.
http)55'''.opse.org
OWSE
The %##T&& 4ireless #ecurity $1pert proves a candidate has the s,ill and
,no'ledge to analy0e and test the operational security o( 'ireless technologies
across the electromagnetic spectrum accurately D e((iciently.
http)55'''.o'se.org
CTA
The Certi(ied Trust Analyst proves a candidate has the s,ills and ,no'ledge to
e((iciently evaluate the trust properties o( any person! place! thing! system! or
process and ma,e accurate and e((icient trust decisions.
http)55'''.trustanalyst.org
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 19
OSSTMM 3 The Open Source Security Testing Methodology Manual
Certifications for Organiations
Certi(ications (or organi0ations! in(rastructure! and products is also available through "#$C%&. The (ollo'ing
certi(ications are available)
Security Test Audit !eport
%##T&& certi(ication is available (or organi0ations or parts o( organi0ations that
validate their security 'ith the #TA/ (rom "#$C%&. Ealidation o( security tests and
+uarterly metrics are sub*ect to the "#$C%& validation re+uirements to assure a
high level o( trust'orthiness in an organi0ation.
"SECOM Licensed Auditors
";As have proven to "#$C%& to have the competence and capacity to per(orm
%##T&& audits (or themselves and (or others. This provides (or an easy and
e((icient 'ay to maintain #ecurity Test Audit /eports and have those reports
certi(ied by "#$C%&.
OSSTMM Seal of Appro#al
%##T&& evaluation seals are available (or products! services! and business
processes. This seal de(ines an operational state o( security! sa(ety! trust! and
privacy. The success(ully evaluated products! services! and processes carry their
visible certi(ication seal and rav score. This allo's a purchaser to see precisely
the amount and type o( change in security that the evaluated solutions present.
"t removes the guess'or, (rom procurement and allo's one to (ind and
compare alternative solutions.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
)elated 'ro(ects
To properly test the security o( anything! you (irst need to ,no' ho' that thing operates! 'hat itKs
comprised o(! and 'hat is the environment it e1ists in. This is ho' the %##T&& itsel( had been approached
as a means o( understanding the best! most e((icient! and most thorough 'ay to test security. There(ore!
'e needed to understand security. This research see,ing the Rsecurity particleS as it turns out has brought
about the application and design o( more pro*ects beyond the %##T&&.
4hile not all applications o( the %##T&& to areas outside o( security testing are 'orthy o( being pro*ects.
2o'ever! some do provide a testament to the (act that 'e are no' only limited by our o'n imaginations.
The %##T&& has become a tool 'ith 'hich 'e can ta,e ne' approaches to many ne' means o(
protection.
Source Code Analysis !is$ E#aluation %SCA!E&
The #CA/$ pro*ect applies the %##T&& ravs to source code analysis. The end result is a
#CA/$ value 'hich is the amount o( the source code 'ith unprotected operations.
httpBCCwww.isecom.orgCscare
'ome Security Methodology and (acation )uide %'SM&
The 2#& pro*ect applies the %##T&& ravs! 6our 3oint 3rocess! Trust &etrics! and analysis
process to protecting and (orti(ying a home. The end result is to create a home that is
sa(er and more secure 'ithout restricting the (reedoms o( the occupants.
httpBCCwww.isecom.orgChsm
'ac$er 'ighschool %''S&
22# is a di((erent ,ind o( security a'areness program (or teens. "t uses the %##T&&
testing and analysis research to provide ,no'ledge and s,ills through hands-on lessons
and access to an "nternet-based test net'or,. 2o'ever 'hile doing so! it rein(orces
resource(ulness and critical thin,ing s,ills.
httpBCCwww.hac"erhighschool.org
The *ad People Pro+ect %*PP&
The <33 is a di((erent ,ind o( security and sa(ety a'areness program (or children and
parents. "t uses %##T&& ravs and Trust &etrics to create better rules (or children about
sa(ety and security to be e1plained through games! stories! and role play. The rules are
easier to remember and (ree o( contradictions and cultural biases. The parents can visit
and contribute to the gallery o( childrenKs dra'ings 'hich e1amines 'hat children thin,
'hat a bad person loo,s li,e. These dra'ings are the (urther used to (ind ne' 'ays to
reach children and improve the rules taught to them.
httpBCCwww.badpeoplepro(ect.org
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1;
OSSTMM 3 The Open Source Security Testing Methodology Manual
Security Operations Maturity Architecture %SOMA&
The #%&A pro*ect aims to provide the %##T&& operational processes at the strategic
level. This pro*ect applies ravs and Trust &etrics to determining security maturity by ho'
'ell protection strategy and tactics 'or, and not *ust ho' they should 'or, according
to policy.
httpBCCwww.isecom.orgCsoma
*usiness "ntegrity Testing %*"T&
The <"T pro*ect e1tends the %##T&& operational testing and analysis to business
processes and transactions. This adds ne' strategic insight to the security o( business
conduct by employees and in the development o( ne' business plans.
httpBCCwww.isecom.orgCbit
Smarter Safer *etter
This pro*ect provides the sa(ety and security tools and s,ills people need every day to
combat (raud! lies! and deception. The tools are based on the %##T&& research 'hich
is (ocused on avoiding persuasive tric,s and manipulation techni+ues. The pro*ect is
uni+ue in ho' it utili0es support groups (or people to discuss issues they have
encountered and 'or, together to analy0e the problems.
httpBCCwww.smartersaferbetter.org
Mastering Trust
This pro*ect is to create seminar materials and 'or,boo,s on ho' to use the %##T&&
Trust &etrics in every day li(e to ma,e better decisions. This pro*ect addresses 'hy our
gut instincts are bro,en and ho' 'e can (i1 and improve them. 4hether its in business
or private relationships! ,no'ing 'ho you can trust and ho' much is more than
protecting yoursel( (rom being hurt! itTs a competitive edge.
httpBCCwww.isecom.orgCseminars
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Security doesnDt have to last foreverE (ust
longer than everything else that might
notice itDs gone.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1@
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 1 < 6hat =ou 5eed to 7now
This manual is about operational security -%p#ec.. "t is about measuring ho' 'ell security 'or,s. 4hile this
may seem plain and obvious) RDonKt 'e all do operational securityUS it is a distinction 'hich must be
made because most compliance ob*ectives re+uire no more than matching processes and
con(igurations to a set o( best practices. This manual and the testing process it outlines re+uires that you
ma,e no assumptions that a security solution! product! or process 'ill behave during operational use as it
has been designated to do on paper. &ore simply! this methodology 'ill tell you i( 'hat you have does
'hat you 'ant it to do and not *ust 'hat it 'as told to do.
%p#ec is a combination o( separation and controls. :nder %p#ec! (or a threat to be e((ective! it must
interact either directly or indirectly 'ith the asset. To separate the threat (rom the asset is to avoid a
possible interaction. There(ore it is possible to have total -00V. security i( the threat and the asset are
completely separated (rom each other. %ther'ise 'hat you have is sa(ety o( the asset 'hich is provided
by the controls you put on the asset or the degree to 'hich you lessen the impact o( the threat.
6or e1ample! to be secure (rom lightning! one must move to 'here lightning canKt reach such as deep in
a mountain. Threats 'hich canKt be separated (rom the assets must be made sa(er so that their
interactions and any e((ects (rom interactions do little or no harm. "n this same e1ample! to be sa&e (rom
lightning! one must stay indoors during storms! avoid 'indo's or other openings! and use lightning rods on
the roo(. There(ore! under the conte1t o( operational security! 'e call securit! the separation o( an asset
and a threat and sa&et! the control o( a threat or its e((ects.
To have true sa(ety o( the assets di((erent types o( controls are re+uired. 2o'ever! controls also may
increase the number o( interactions 'ithin the scope 'hich means more controls are not necessarily
better. There(ore it is recommended to use di((erent types o( operational controls rather than *ust more
controls. &ore controls o( the same type o( operational controls do not provide a de(ense in depth as
access through one is o(ten access through all o( that type. This is 'hy it is so important to be able to
categori0e controls by 'hat they do in operations to be certain o( the level o( protection provided by
them.
To better understand ho' %p#ec can 'or, 'ithin an operational environment! it must be reduced to its
elements. These elements allo' one to +uanti(y the &ttac" Surface! 'hich is the lac, o( speci(ic
separations and (unctional controls that e1ist (or that $ector! the direction o( the interaction. The
reductionist approach resolves to us needing to see security and sa(ety in a ne' 'ay! one that allo's (or
them to e1ist independent o( ris, and (ully capable o( creating 'erfect Security! the e1act balance o(
security and controls 'ith operations and limitations. 2o'ever! to see security in a ne' 'ay re+uires ne'
terminology as 'ell.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Term .efinition
Attac, #ur(ace
The lac, o( speci(ic separations and (unctional controls that e1ist (or that
vector.
Attac, Eector
A sub-scope o( a vector created in order to approach the security testing
o( a comple1 scope in an organi0ed manner. "t is based on the divide and
con+uer algorithm design paradigm that consists in recursively brea,ing
do'n a problem into t'o or more sub-problems o( the same -or related.
type! until these become simple enough to be solved directly.
Controls
"mpact and loss reduction controls. The assurance that the physical and
in(ormation assets as 'ell as the channels themselves are protected (rom
various types o( invalid interactions as de(ined by the channel. 6or
e1ample! insuring the store in the case o( (ire is a control that does not
prevent the inventory (rom getting damaged or stolen but 'ill pay out
e+uivalent value (or the loss. Ten controls have been de(ined. The (irst (ive
controls are Class A and control interactions. The (ive Class < controls are
relevant to controlling procedures. #ee section .2 belo' (or (urther
in(ormation regarding controls.
;imitations
This is the current state o( perceived and ,no'n limits (or channels!
operations! and controls as veri(ied 'ithin the audit. ;imitation types are
classi(ied by ho' they interact 'ith security and sa(ety on an operational
level. There(ore! opinions as to impact! availability in the 'ild! di((iculty to
per(orm! and comple1ity are not used to classi(y them. 6or e1ample! an old
rusted loc, used to secure the gates o( the store at closing time has an
imposed security limitation providing a (raction o( the protection strength
necessary to delay or 'ithstand an attac,. Determining that the loc, is old
and 'ea, through visual veri(ication is re(erred to as an identi(ied limitation.
Determining it is old and 'ea, by brea,ing it using 00 ,g o( (orce 'hen a
success(ul deterrent re+uires 000 ,g o( (orce sho's a veri(ied limitation.
%ne o( its limitations is then classi(ied based on the conse+uence o( the
operational action! 'hich in this case is Access.
%perations
%perations are the lac, o( security one must have to be interactive! use(ul!
public! open! or available. 6or e1ample! limiting ho' a person buys goods
or services (rom a store over a particular channel! such as one door (or
going in and out! is a method o( security 'ithin the storeKs operations.
3er(ect #ecurity
The e1act balance o( security and controls 'ith operations and limitations.
3orosity
All interactive points! operations! 'hich are categori0ed as a Eisibility!
Access! or Trust.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %1
OSSTMM 3 The Open Source Security Testing Methodology Manual
Term .efinition
#a(ety
A (orm o( protection 'here the threat or its e((ects are controlled. "n order
to be sa(e! the controls must be in place to assure the threat itsel( or the
e((ects o( the threat are minimi0ed to an acceptable level by the asset
o'ner or manager. This manual covers sa(ety as RcontrolsS 'hich are the
means to mitigate attac,s in an operational or live environment.
#ecurity
A (orm o( protection 'here a separation is created bet'een the assets and
the threat. This includes but is not limited to the elimination o( either the
asset or the threat. "n order to be secure! the asset is removed (rom the
threat or the threat is removed (rom the asset. This manual covers security
(rom an operational perspective! veri(ying security measures in an
operating or live environment.
/av
The rav is a scale measurement o( an attac, sur(ace! the amount o(
uncontrolled interactions 'ith a target! 'hich is calculated by the
+uantitative balance bet'een porosity! limitations! and controls. "n this
scale! 00 rav -also sometimes sho'n as 00V rav. is per(ect balance and
anything less is too (e' controls and there(ore a greater attac, sur(ace.
&ore than 00 rav sho's more controls than are necessary 'hich itsel( may
be a problem as controls o(ten add interactions 'ithin a scope as 'ell as
comple1ity and maintenance issues.
Target
That 'ithin the scope that you are attac,ing! 'hich is comprised o( the
asset and any protections the asset may have.
Eector
The direction o( an interaction.
Eulnerability
%ne classi(ication o( ;imitation 'here a person or process can access!
deny access to others! or hide itsel( or assets 'ithin the scope. &ore details
and e1amples are available in the ;imitations table in 8.2.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
1.1 Security
#ecurity is a (unction o( a separation. $ither the separation bet'een an asset and any threats e1ists or it
does not. There are 3 logical and proactive 'ays to create this separation)
. &ove the asset to create a physical or logical barrier bet'een it and the threats.
2. Change the threat to a harmless state.
3. Destroy the threat.
4hen analy0ing the state o( security 'e can see 'here there is the possibility (or interaction and 'here
there is not. 4e ,no' some! all! or even none o( these interactions may be re+uired (or operations. ;i,e
doors into a building! some o( the doors are needed (or customers and others (or 'or,ers. 2o'ever! each
door is an interactive point 'hich can increase both necessary operations and un'anted ones! li,e the(t.
#ince the security tester may not ,no' at this point the business *usti(ication (or all these interactive points!
'e re(er to this as the porosity. The porosity reduces the separation bet'een a threat and an access. "t is
(urther categori0ed as one o( 3 elements! visibility! access! or trust 'hich describes its (unction in
operations 'hich (urther allo's the proper controls to be added during the remediation phase o(
improving protection.
#o consider that i( the separation e1ists properly (rom the threats! such as a man inside a mountain
avoiding lightning! then that security is trueL it is 00V. 6or every hole in the mountain! every means (or
lightning to cause harm to that man! the porosity increases as an Access. $ach point o( interaction
reduces the security belo' 00V! 'here 00V represents a (ull separation. There(ore! the increase in
porosity is the decrease in security and each pore is either a Eisibility! Access! or Trust.
Term .efinition
Eisibility
3olice science places RopportunityS as one o( the three elements 'hich
encourage the(t! along 'ith Rbene(itS! and Rdiminished ris,S. Eisibility is a
means o( calculating opportunity. "t is each targetKs asset ,no'n to e1ist
'ithin the scope. :n,no'n assets are only in danger o( being discovered as
opposed to being in danger o( being targeted.
Access
#ince security is the separation o( a threat and an asset then the ability to
interact 'ith the asset directly is to access it. Access is calculated by the
number o( di((erent places 'here the interaction can occur. /emoving
direct interaction 'ith an asset 'ill halve the number o( 'ays it can be
ta,en a'ay.
Trust
4e measure trust as part o( %p#ec as each relationship that e1ists 'here
the target accepts interaction (reely (rom another target 'ithin the scope.
4hile a trust may be a security hole! it is a common replacement (or
authentication and a means (or evaluating relationships in a rational and
repeatable manner. There(ore! the use o( trust metrics is encouraged 'hich
'ill allo' (or one to measure ho' valid a trust is by calculating the amount
o( reliability in the trust.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %3
OSSTMM 3 The Open Source Security Testing Methodology Manual
1.% ,ontrols
4hen the threat is all around then it is controls 'hich 'ill provide sa(ety in operations. Controls are a
means to in(luence the impact o( threats and their e((ects 'hen interaction is re+uired.
Just ecause !ou can9t %irectl! control it %oesn9t
"ean it can9t e controlle%. Control the en.iron"ent
an% !ou control e.er!thin$ in it.
4hile there are many di((erent names and types o( operation controls! there are only 2 main categories
'hich contain all possible controls. T'o o( the categories ho'ever! dentification! the veri(ication o( an
e1isting identity! and &uthori1ation! the granting o( permissions (rom the right(ul authority! cannot stand
alone in an operational environment and instead! in operations! combine and are added to the
Authentication control. This leaves %p#ec 'ith ten possible controls an Analyst 'ill need to identi(y and
understand.
The reason 'hy "denti(ication and Authori0ation cannot be e1pressed operationally is because neither
can be trans(erred. "dentity e1ists as is and 'hile the means o( identi(ication! as a process! is an
operational aspect! the actual process is to veri(y a previously provided identity (rom another source or
(rom the latest in a chain o( sources. $ven under circumstances 'here a government agency o((icially
changes the identity o( a person! they are still the same person (rom identi(ying mar,s to their DNA and
only their documentation changes. There(ore! a security process can attempt to identi(y someone by
veri(ying their identity but nothing in this case is granted or provided. There is no true RgrantingS o( identity
*ust as there can be no true Rthe(tS o( identity. 6urthermore! identity is a collection o( thoughts! emotions!
e1periences! relationships! and intentions! as 'ell as physical shape or mar,s. 9ou are 'ho you are
because you e1ist not because someone granted that to you. A per(ect duplicate or clone o( you is still
not you because (rom origin your e1periences 'ill di((er. 4hile this may sound more li,e philosophy than
security! it is very important that Analysts understand this. "denti(ication processes only veri(y against a
(ormer identi(ication process. "( that process has been corrupted or can be circumvented! then the entire
security (oundation that re+uires proper identi(ication is (la'ed.
Authori0ation! li,e "denti(ication! is another operations control 'hich cannot be trans(erred. "t is the control
to grant permissions. An employee authori0ed to enter a room may hold the door open (or another
person to enter. This does not authori0e the ne' person. Authori0ation did not get trans(erred. This ne'
person is trespassing in a restricted area and the employee 'ho held open the door actually 'as part o(
a limitation in the Authentication process to grant Access.
Another property o( Authori0ation is that it re+uires identi(ication to 'or,. 4ithout identi(ication!
authori0ation is a blan,et Rpermit allS 'ithout even ,no'ing 'hat all is. 2o'ever in operations this is itsel( a
parado1 because to authori0e all 'ithout scrutiny means that there is no authori0ation. There(ore to not
authori0e you do not use authori0ation.
The Authentication control combines both identi(ication and authori0ation to map Access. The process is
simply ,no'ing 'ho -or 'hat. it is and 'hat! 'here! 'hen! and ho' they can access be(ore they are
granted access. <ecause authentication is a control (or interactivity! it is one o( the (ive Class A controls!
also ,no'n as the R"nteractive ControlsS.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
"nteracti#e Controls
The Class A "nteractive Controls ma,e up e1actly hal( o( all the operation controls. These controls directly
in(luence visibility! access! or trust interactions. The Class A categories are Authentication! "ndemni(ication!
#ub*ugation! Continuity! and /esilience.
. &uthentication is a control through the challenge o( credentials based on identi(ication and
authori0ation.
2. ndemnification is a control through a contract bet'een the asset o'ner and the interacting
party. This contract may be in the (orm o( a visible 'arning as a precursor to legal action i( posted
rules are not (ollo'ed! speci(ic! public legislative protection! or 'ith a third-party assurance
provider in case o( damages li,e an insurance company.
3. )esilience is a control over all interactions to maintain the protection o( assets in the event o(
corruption or (ailure.
8. Sub(ugation is a control assuring that interactions occur only according to de(ined processes. The
asset o'ner de(ines ho' the interaction occurs 'hich removes the (reedom o( choice but also the
liability o( loss (rom the interacting party.
N. ,ontinuity is a control over all interactions to maintain interacti.it! 'ith assets in the event o(
corruption or (ailure.
Process Controls
The other hal( o( operation controls are the Class < controls 'hich are used to create de(ensive processes.
These controls do not directly in(luence interactions rather they protect the assets once the threat is
present. These are also ,no'n as 3rocess Controls and include Non-repudiation! Con(identiality! 3rivacy!
"ntegrity! and Alarm.
C. 5onArepudiation is a control 'hich prevents the interacting party (rom denying its role in any
interactivity.
O. ,onfidentiality is a control (or assuring an asset displayed or e1changed bet'een interacting
parties cannot be ,no'n outside o( those parties.
7. 'rivacy is a control (or assuring the means o( ho' an asset is accessed! displayed! or e1changed
bet'een parties cannot be ,no'n outside o( those parties.
P. ntegrity is a control to assure that interacting parties ,no' 'hen assets and processes have
changed.
0. &larm is a control to noti(y that an interaction is occurring or has occurred.
4hile controls are a positive in(luence in %p#ec! minimi0ing the attac, sur(ace! they can themselves add
to the attac, sur(ace i( they themselves have limitations. %(ten times this e((ect is not noticed and i( the
protection mechanisms arenKt tested thoroughly as to ho' they 'or, under all conditions! this may not
become apparent. There(ore the use o( controls must assure that they do not insinuate ne' attac,
vectors into the target. There(ore! sometimes no controls are better than bad controls.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %9
OSSTMM 3 The Open Source Security Testing Methodology Manual
The *ad Loc$ E,ample
"s a bad loc, on a door better than no loc, at allU An Analyst must use critical security thin,ing!
a (orm o( logic s,ills to overcome the innate sense o( security 'e carry to understand 'hy bad
controls can increase the attac, sur(ace to greater than no control at all.
Common thought is that adding controls 'ith limitations are better than having none at all. "s it
not better to have a poor loc, than to have no loc, at allU A(ter all! as conventional 'isdom
suggests! a 'isdom borne o( emotion rather than veri(ication! some RsecurityS is better than
none. This is 'hy the analogy o( the loc, is such a good e1ample and actually does better to
ans'er the +uestion then any other because it sho's so 'ell ho' 'e misunderstand controls
that are so common around us.
As, anyone 'ho has had to brea, open a loc,ed door 'here they ,ic, or hit the door to open
itU That ans'er di((ers 'hether it is a ,ey loc, opened (rom the outside as opposed to a bolt
loc, on the inside. ThereKs a reason (or this.
4hen a loc, -'hich is considered the authentication control. is added to a door! the heavy!
solid door needs to have a space hollo'ed out and the loc, inserted. That creates a limitation!
a 'ea, spot in the door. #o does adding a handle. Doors 'ith no handles or internal loc,s do
not have this limitation. 2o'ever they re+uire the door to be opened (rom the inside in another
means. #o to open a door 'ith that ,ind o( loc,! you ,ic, or hit the door at the handle or loc,
mechanism.
"( there is a bolt loc,! that limitation does not e1ist because the door remains solid. Those doors
o(ten re+uire a (orce to open that 'ill sooner brea, the door than the loc,. Doors made to
'ithstand high pressures have the bolts on the outside and the opening mechanism in the
center o( the door as a small hole! li,e doors on a boat or submarine! to avoid the 'ea,nesses
o( hollo'ing out part o( the door.
No' to more directly ans'er the +uestion) i( it is better to have a 'ea, loc, than no loc,. This
+uestion re(ers to a door 'ith the minimum! a cheap or simple ,ey loc, -authentication. that
can be bypassed by someone 'ho 'ants to enter. #o i( 'e ,no' the authentication is 'ea,!
then 'e ,no' somebody can get in and even 'orse! they can do it 'ithout damaging the
loc, or the door 'hich means 'e may have no ,no'ledge o( the intrusion. "( you thin,! 'ell!
thatKs o,ay because our problem isnKt the real croo,s! itKs the opportunists loo,ing (or the lo'-
hanging (ruit then youKre ma,ing a ris, decision and that does not a((ect your attac, sur(ace
'hich is made (rom 'hat you have and not 'hat you 'ant. 6urthermore! by having a loc, at
all implies! most o( all to the opportunists! that there is something o( value inside.
"( you add a control! any control! you increase the attac, sur(ace o( anything. "( that ne' thing
you add brings a ne' attac, vector then you 'ere probably better o(( 'ithout. "n some cases!
the ne' attac, vector is smaller than the actual amount o( sa(ety the ne' control gives you.
2o'ever! a good control 'ill have no limitations and can shrin, the attac, sur(ace.
A loc, in a door should not be easily subverted or add to the attac, sur(ace in a signi(icant
'ay. #uch a loc, re+uires (orce to open and that adds another control then 'hich the loc,
provides! alarm. A bro,en loc, is also a good noti(ication o( a brea,-in.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
1.3 nformation &ssurance Ob(ectives
To (acilitate understanding o( operation controls! they can be matched bac, to the three "n(ormation
Assurance %b*ectives o( Con(identiality! Availability! and "ntegrity. These ob*ectives are used across the
in(ormation security industry although due in part to their over-simpli(ication! they are more (or the bene(it
o( managing it rather than creating it or testing it. The mapping is not a per(ect ) ho'ever it is su((icient
to demonstrate operation controls according to the basic C"A Triad. <ecause the de(initions used (or C"A
are very broad the mappings appear to be as such)
nformation &ssurance Ob(ectives Operation ,ontrols
Con(identiality
Con(identiality
3rivacy
Authentication
/esilience
"ntegrity
"ntegrity
Non-repudiation
#ub*ugation
Availability
Continuity
"ndemni(ication
Alarm
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %;
OSSTMM 3 The Open Source Security Testing Methodology Manual
1.- 2imitations
The inability o( protection mechanisms to 'or, are their limitations. There(ore the state o( security in regard
to ,no'n (la's and restrictions 'ithin the operations scope is called ;imitation. "t is the holes!
vulnerabilities! 'ea,nesses! and problems in ,eeping that separation bet'een an asset and a threat or in
assuring controls continue 'or,ing correctly.
;imitations have been classi(ied into (ive categories and these categories de(ine the type o( vulnerability!
mista,e! miscon(iguration! or de(iciency by operation. This is di((erent (rom ho' limitations are classi(ied
under most security management (rame'or,s and best practices 'hich is 'hy 'e use the term ;imitation
rather than more common terms to avoid con(usion. Those other terms re(er to vulnerabilities or
de(iciencies because they are categori0ed by the type o( attac, or o(ten the threat itsel(. There is a (ocus
on the ris, (rom the attac,. 2o'ever! to remove bias (rom security metrics and provide a more (air
assessment 'e removed the use o( ris,. /is, itsel( is heavily biased and o(ten highly variable depending on
the environment! assets! threats! and many more (actors. There(ore! under %p#ec! 'e use the term
;imitations to e1press the di((erence o( categori0ing ho' %p#ec (ails rather than by the type o( threat.
#ince the number and type o( threats cannot be ,no'n it ma,es more sense to understand a security or
sa(ety mechanism based on 'hen it 'ill (ail. This allo's the Analyst to test (or the conditions in 'hich it 'ill
no longer sustain the necessary level o( protection. %nly once 'e have this ,no'ledge can 'e begin to
play the 'hat-i( game o( threats and ris,s. Then 'e can also invest in the appropriate type o( separation
or controls re+uired and create precise plans (or disasters and contingencies.
Although the ;imitations are categori0ed here as through N this does not mean they are in a hierarchical
(ormat o( severity. /ather they are numbered only to di((erentiate them both (or operational planning and
metrics. This also means it is possible that more than one type o( ;imitation can be applied to a single
problem. 6urthermore! the 'eight -value. o( a particular ;imitation is based on the other available and
corresponding controls and interactive areas to the scope! there can be no speci(ic hierarchy since the
value o( each is speci(ic to the protective measures in the scope being audited.
4ithin the %##T&& the (ive ;imitation classi(ications are)
. $ulnerability is the (la' or error that) -a. denies access to assets (or authori0ed people or processes!
-b. allo's (or privileged access to assets to unauthori0ed people or processes! or -c. allo's
unauthori0ed people or processes to hide assets or themselves 'ithin the scope.
2. 6ea"ness is the (la' or error that disrupts! reduces! abuses! or nulli(ies speci(ically the e((ects o( the
(ive interactivity controls) authentication! indemni(ication! resilience! sub*ugation! and continuity.
3. ,oncern is the (la' or error that disrupts! reduces! abuses! or nulli(ies the e((ects o( the (lo' or
e1ecution o( the (ive process controls) non-repudiation! con(identiality! privacy! integrity! and
alarm.
8. +Fposure is an un*usti(iable action! (la'! or error that provides direct or indirect visibility o( targets or
assets 'ithin the chosen scope channel.
N. &nomaly is any unidenti(iable or un,no'n element 'hich has not been controlled and cannot be
accounted (or in normal operations.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Limitations Mapping
To better understand ho' ;imitations (it into the %p#ec (rame'or,! it can be seen mapping bac, to
security and sa(ety)
,ategory OpSec 2imitations
%perations
Eisibility $1posure
Access
Trust
Eulnerability
Controls
Class A -
"nteractive
Authentication
"ndemni(ication
/esilience
#ub*ugation
Continuity
4ea,ness
Class < -
3rocess
Non-/epudiation
Con(identiality
3rivacy
"ntegrity
Alarm
Concern
Anomalies
This mapping sho's ho' ;imitations e((ect security and ho' there values are determined.
A .ulnerailit! is the (la' or error that) -a. denies access to assets (or authori0ed people or processes -b.
allo's (or privileged access to assets to unauthori0ed people or processes! or -c. allo's unauthori0ed
people or processes to hide assets or themselves 'ithin the scope. This means that Eulnerability must be
mapped to all points o( interaction or %p#ec and because Eulnerability can circumnavigate or nulli(y the
Controls! these must also be considered in the 'eighting o( Eulnerability.
A /eakness is a (la' in Class A Controls ho'ever can impact %p#ec there(ore it is mapped to all %p#ec
parameters as 'ell as being mapped to this interactive class o( controls.
A concern can only be (ound in Class < Controls ho'ever can impact %p#ec there(ore it is mapped to all
%p#ec parameters as 'ell as being mapped to this process class o( controls.
An e5posure gives us intelligence about the interaction 'ith a target and thus maps directly to Eisibility
and Access. This intelligence can also help an attac,er navigate around some or all controls and so
$1posure is also mapped to both Control classes. 6inally! $1posure has no value itsel( unless there is a 'ay
to use this intelligence to e1ploit the asset or a Control and so Eulnerabilities! 4ea,nesses and Concerns
also play a role in the 'eighting o( $1posureKs value.

An ano"al! is any unidenti(iable or un,no'n element 'hich has not been controlled and cannot be
accounted (or in normal operations. The (act that it has not been controlled and cannot be accounted
(or signi(ies a direct lin, 'ith Trust. This ;imitation can also cause anomalies in the 'ay Controls (unction
and so they are also included in the 'eighting. 6inally! as 'ith an $1posure! an Anomaly alone does not
a((ect %p#ec 'ithout the e1istence o( either a Eulnerability! 4ea,ness or Concern 'hich can e1ploit this
unusual behavior.
Additionally! more than one category can apply to a limitation 'hen the (la' brea,s %p#ec in more than
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %@
OSSTMM 3 The Open Source Security Testing Methodology Manual
one place. 6or e1ample! an Authentication control 'hich allo's a person to hi*ac, another personKs
credentials has a 4ea,ness and should the credentials allo' Access then it also has a Eulnerability.
"n another e1ample! an Authentication control uses a common list o( names corresponding to e-mail
addresses. $very address 'hich can be (ound or guessed and used as a log-in is an $1posure 'hile the
control itsel( has a 4ea,ness (or its inability to identi(y the correct user o( the Authentication mechanism o(
the log-in. "( any o( those credentials allo' Access then 'e include this as a Eulnerability as 'ell.
-ustification for Limitations
The concept that limitations are only limitations i( they have no business *usti(ication is (alse. A limitation is a
limitation i( it behaves in one o( the limiting (actors as described here. A *usti(ication (or a limitation is a ris,
decision that is met 'ith either a control o( some ,ind or merely acceptance o( the limitation. /is,
decisions that accept the limitations as they are o(ten come do'n to) the damage a limitation can
cause does not *usti(y the cost to (i1 or control the limitation! the limitation must remain according to
legislation! contracts! or policy! or a conclusion that the threat does not e1ist or is unli,ely (or this particular
limitation. #ince ris, *usti(ications are not a part o( calculating an attac, sur(ace! all limitations discovered
must still be counted 'ithin the attac, sur(ace regardless i( best practice! common practice! or legal
practice denotes it as not a ris,. "( it is not then the audit 'ill not sho' a true representation o( the
operational security o( the scope.
Managing Limitations
Another concept that must be ta,en into consideration is one o( managing (la's and errors in an audit.
The three most straight(or'ard 'ays to manage limitations is to remove the problem area providing the
interactive point altogether! (i1 them! or accept them as part o( doing business ,no'n as the business
*usti(ication.
An audit 'ill o(ten uncover more than one problem per target. The Analyst is to report the limitations per
target and not *ust 'hich are the 'ea, targets. These limitations may be in the protection measures and
controls themselves! thus diminishing %p#ec. $ach limitation is to be rated as to 'hat occurs 'hen the
problem is invo,ed! even i( that invocation is theoretical or the veri(ication is o( limited e1ecution to restrict
actual damages. Theoretical categori0ation! 'here no veri(ication could be made! is a slippery slope and
should be limited to cases 'here veri(ication 'ould reduce the +uality o( operations. Then! 'hen
categori0ing the problems! each limitation should be e1amined and calculated in speci(ic terms o(
operation at its most basic components. 2o'ever! the Analyst should be sure never to report a R(la'
'ithin a (la'S 'here the (la's share the same component and same operational e((ect. An e1ample o(
this 'ould be a door bro,en open 'ith a bro,en 'indo'. The door opening is an Access even i( the
bro,en 'indo' is also but both are (or the same component! the door 'ay! and same operational e((ect!
an opening. An e1ample (rom Data Net'or,s 'ould be a computer system 'hich sends a ,ernel reply!
such as an "C&3 Rclosed portS T03C03 pac,et (or a particular port. This interaction is not counted (or all
such ports since the Access comes (rom the same component! the ,ernel! and has the same operational
e((ect! sending a T03C03 pac,et per port +ueried.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
3> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
1.9 &ctual Security
The role o( the Controls is to control the porosity in %p#ec. "tKs li,e having ten 'ays o( controlling threats
that come through a hole in a 'all. 6or each hole! a ma1imum o( ten di((erent controls can be applied
'hich bring security bac, up to'ards and sometimes above 00V. ;imitations then reduce the
e((ectiveness o( %p#ec and Controls. The result o( an audit 'hich discovers and sho's the #ecurity!
Controls! and ;imitations is e((ectively demonstrating Actual #ecurity.
Actual #ecurity is a term (or a snapshot o( an attac, sur(ace in an operational environment. "t is a
logarithmic representation o( the Controls! ;imitations! and %p#ec at a particular moment in time. "t is
logarithmic because it represents the reality o( si0e 'here a larger scope 'ill have a larger attac, sur(ace
even i( mathematically the Controls 'ill balance the %p#ec. :sing this as building bloc,s to better
understand ho' security 'or,s! the visuali0ation that 'e create (rom this is the e((ective balance created
bet'een 'here an attac, can occur! 'here the Controls are in place to manage an attac,! and the
limitations o( the protective measures.
Another bene(it o( mathematical representation o( an attac, sur(ace as Actual #ecurity is that besides *ust
sho'ing 'here protection measures are lac,ing it can also sho' the opposite. #ince it is possible to have
more controls than one needs this can be mathematically represented as more than 00V rav. 4hether a
ris, assessment may ma,e this point seem impossible! the mathematical representation is use(ul (or
sho'ing 'aste. "t can be used to prove 'hen money is being overspent on the 'rong types o( controls or
redundant controls.
1.: ,ompliance
Compliance is a di((erent thing than security and e1ists separate (rom security. "t is possible to be
compliant yet not secure and it is possible to be relatively secure but non-compliant and there(ore o( lo'
trust'orthiness.
Compliance pro*ects are not the time to rede(ine operational security re+uirements as a result o( an
%##T&& test! they may ho'ever be the time to speci(y the use o( %##T&& testing! on a periodic basis! to
(ul(ill a control re+uirement dra(ted as a result o( a trust assessment that has scoped the minimum number
o( controls re+uired to achieve a compliant -but not necessarily secure. state.
The big problem 'ith compliance is it re+uires a lot o( documentation that has to be versioned and
updated. This documentation can be o( business processes! narratives! trust assessments! ris, assessments!
signed o(( design tests! operational audits! attestations! and so on and on. This documentation is
scrutini0ed by internal and e1ternal auditors and has to logically (ul(ill its e1istence in the 'orld o( a
compliant state.
&ost recent compliance e((orts have been driven by the short term re+uirements o( imposed regulations
'ith short term implementation re+uirements. This has created a lot o( resource re+uirements and cost.
@iven time to thin, about it 'e try to build compliance and evidence production into a process and
manage this resource re+uirement and cost.
Compliance is a broad brush approach to the application o( best practice (rom! as (ar as "n(ormation
Technology is concerned! the li,es o( C%<"T and "T";L an %##T&& test should provide documentation that
provides an understandable! veri(iable level o( +uality. The use o( the %##T&&! ho'ever! is designed to
allo' the Analyst to vie' and understand security and sa(ety. There(ore! 'ith the use o( this methodology!
any compliance is! at least! the production o( evidence o( governance 'ithin the business process o(
security.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 31
OSSTMM 3 The Open Source Security Testing Methodology Manual
3act does not come from the grand leaps
of discovery but rather from the small,
careful steps of verification.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
3% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter % < 6hat =ou 5eed to .o
4here do you startU Testing is a complicated a((air and 'ith anything complicated! you approach it in
small! comprehensible pieces to be sure you donKt ma,e mista,es.
Conventional 'isdom says comple1ity is an enemy o( security. 2o'ever! it is only at odds 'ith human
nature. Anything 'hich is made more comple1 is not inherently insecure. Consider a computer managing
comple1 tas,s. The problem as 'e ,no' it is not that the computer 'ill ma,e mista,es! con(use the tas,s!
or (orget to complete some. As more tas,s are added to the computer! it gets slo'er and slo'er! ta,ing
more time to complete all the tas,s. 3eople! ho'ever! do ma,e mista,es! (orget tas,s! and purposely
abandon tas,s 'hich are either not important or re+uired at the moment. #o 'hen testing security! 'hat
you need to do is properly manage any comple1ity. This is done by properly de(ining the security test.
%.1 .efining a Security Test
These O steps 'ill ta,e you to the start o( a properly de(ined security test.
. De(ine 'hat you 'ant to protect. These are the assets. The protection mechanisms (or these assets
are the ,ontrols you 'ill test to identi(y 2imitations.
2. "denti(y the area around the assets 'hich includes the protection mechanisms and the processes
or services built around the assets. This is 'here interaction 'ith assets 'ill ta,e place. This is your
engagement 1one.
3. De(ine everything outside the engagement 0one that you need to ,eep your assets operational.
This may include things you may not be able to directly in(luence li,e electricity! (ood! 'ater! air!
stable ground! in(ormation! legislation! regulations and things you may be able to 'or, 'ith li,e
dryness! 'armth! coolness! clarity! contractors! colleagues! branding! partnerships! and so on. Also
count that 'hich ,eeps the in(rastructure operational li,e processes! protocols! and continued
resources. This is your test scope.
8. De(ine ho' your scope interacts 'ithin itsel( and 'ith the outside. ;ogically compartmentali0e the
assets 'ithin the scope through the direction o( interactions such as inside to outside! outside to
inside! inside to inside! department A to department <! etc. These are your vectors. $ach vector
should ideally be a separate test to ,eep each compartmentali0ed test duration short be(ore too
much change can occur 'ithin the environment.
N. "denti(y 'hat e+uipment 'ill be needed (or each test. "nside each vector! interactions may occur
on various levels. These levels may be classi(ied in many 'ays! ho'ever here they have been
classi(ied by (unction as (ive channels. The channels are 2uman! 3hysical! 4ireless!
Telecommunications! and Data Net'or,s. $ach channel must be separately tested (or each
vector.
C. Determine 'hat in(ormation you 'ant to learn (rom the test. 4ill you be testing interactions 'ith
the assets or also the response (rom active security measuresU The test type must be individually
de(ined (or each test! ho'ever there are si1 common types identi(ied here as <lind! Double <lind!
@ray <o1! Double @ray <o1! Tandem! and /eversal.
O. Assure the security test you have de(ined is in compliance to the )ules of +ngagement! a guideline
to assure the process (or a proper security test 'ithout creating misunderstandings!
misconceptions! or (alse e1pectations.
The end result 'ill be a measurement o( your &ttac" Surface. The attac, sur(ace is the unprotected part
o( the #cope (rom a de(ined Eector.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 33
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.% Scope
The scope is the total possible operating security environment (or any interaction 'ith any asset 'hich
may include the physical components o( security measures as 'ell. The scope is comprised o( three
classes o( 'hich there are (ive channels) Telecommunications and Data Net'or,s security Channels o(
the C%&#$C class! 3hysical and 2uman #ecurity Channels o( the 329##$C class! and the (ull spectrum
4ireless #ecurity Channel o( the #3$C#$C class. Classes are (rom o((icial designations currently in use in the
security industry! government! and the military. Classes are used to de(ine an area o( study! investigation!
or operation. 2o'ever! Channels are the speci(ic means o( interacting 'ith assets. An asset can be
anything that has value to the o'ner. Assets can be physical property li,e gold! people! blueprints!
laptops! the typical P00 &20 (re+uency phone signal! and moneyL or intellectual property such as
personnel data! a relationship! a brand! business processes! pass'ords! and something 'hich is said over
the P00 &20 phone signal. %(ten! the scope e1tends (ar beyond the reach o( the asset o'ner as
dependencies are beyond the asset o'nerKs ability to provide independently. The scope re+uires that all
threats be considered possible! even i( not probable. Although! it must be made clear that a security
analysis must be restricted to that 'hich is 'ithin a type o( certainty -not to be con(used 'ith ris, 'hich is
not a certainty but a probability.. These restrictions include)
. Non-events such as a volcano eruption 'here no volcano e1ists!
2. Non-impact li,e moonlight through data center 'indo'! or
3. @lobal-impacting such as a catastrophic meteor impact.
4hile a thorough security audit re+uires testing all (ive channels! realistically! tests are conducted and
categori0ed by the re+uired e1pertise o( the Analyst and the re+uired e+uipment (or the audit.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
3- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Channels
,lass ,hannel .escription
3hysical #ecurity
-329##$C.
2uman
Comprises the human element o( communication
'here interaction is either physical or psychological.
3hysical
3hysical security testing 'here the channel is both
physical and non-electronic in nature. Comprises the
tangible element o( security 'here interaction
re+uires physical e((ort or an energy transmitter to
manipulate.
#pectrum #ecurity
-#3$C#$C.
4ireless
Comprises all electronic communications! signals!
and emanations 'hich ta,e place over the ,no'n
$& spectrum. This includes $;#$C as electronic
communications! #"@#$C as signals! and $&#$C
'hich are emanations untethered by cables.
Communications
#ecurity -C%&#$C.
Telecommunications
Comprises all telecommunication net'or,s! digital or
analog! 'here interaction ta,es place over
established telephone or telephone-li,e net'or, lines.
Data Net'or,s
Comprises all electronic systems and data net'or,s
'here interaction ta,es place over established cable
and 'ired net'or, lines.
Data Net'or,s
4hile the channels and their divisions may be represented in any 'ay! 'ithin this manual they are
organi0ed as recogni0able means o( communication and interaction. This organi0ation is designed to
(acilitate the test process 'hile minimi0ing the ine((icient overhead that is o(ten associated 'ith strict
methodologies.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 39
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.3 ,ommon Test Types
These si1 types di((er based on the amount o( in(ormation the tester ,no's about the targets! 'hat the
target ,no's about the tester or e1pects (rom the test! and the legitimacy o( the test. #ome tests 'ill test
the testerKs s,ill more than actually testing the security o( a target.
Do note 'hen reporting the audit! there is o(ten a re+uirement to identi(y e1actly the type o( audit
per(ormed. Too o(ten! audits based on di((erent test types are compared to trac, the delta -deviations.
(rom an established baseline o( the scope. "( the precise test type is not available to a third-party revie'er
or regulator! the audit itsel( should be considered a <lind test! 'hich is one 'ith the least merit to'ards a
thorough security test.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
3: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Type .escription
<lind
The Analyst engages the target 'ith no prior ,no'ledge o( its de(enses! assets! or
channels. The target is prepared (or the audit! ,no'ing in advance all the details o(
the audit. A blind audit primarily tests the s,ills o( the Analyst. The breadth and depth
o( a blind audit can only be as vast as the AnalystKs applicable ,no'ledge and
e((iciency allo's. "n C%&#$C and #3$C#$C! this is o(ten re(erred to as $thical 2ac,ing
and in the 329##$C class! this is generally scripted as 6ar 4aming or )ole 'laying.
2 Double <lind
The Analyst engages the target 'ith no prior ,no'ledge o( its de(enses! assets! or
channels. The target is not noti(ied in advance o( the scope o( the audit! the
channels tested! or the test vectors. A double blind audit tests the s,ills o( the Analyst
and the preparedness o( the target to un,no'n variables o( agitation. The breadth
and depth o( any blind audit can only be as vast as the AnalystKs applicable
,no'ledge and e((iciency allo's. This is also ,no'n as a Blac" BoF test or 'enetration
test.
3 @ray <o1
The Analyst engages the target 'ith limited ,no'ledge o( its de(enses and assets
and (ull ,no'ledge o( channels. The target is prepared (or the audit! ,no'ing in
advance all the details o( the audit. A gray bo1 audit tests the s,ills o( the Analyst. The
nature o( the test is e((iciency. The breadth and depth depends upon the +uality o(
the in(ormation provided to the Analyst be(ore the test as 'ell as the AnalystKs
applicable ,no'ledge. This type o( test is o(ten re(erred to as a $ulnerability Test and
is most o(ten initiated by the target as a sel(-assessment.
8
Double @ray
<o1
The Analyst engages the target 'ith limited ,no'ledge o( its de(enses and assets
and (ull ,no'ledge o( channels. The target is noti(ied in advance o( the scope and
time (rame o( the audit but not the channels tested or the test vectors. A double
gray bo1 audit tests the s,ills o( the Analyst and the targetKs preparedness to
un,no'n variables o( agitation. The breadth and depth depends upon the +uality o(
the in(ormation provided to the Analyst and the target be(ore the test as 'ell as the
AnalystKs applicable ,no'ledge. This is also ,no'n as a 6hite BoF test.
N Tandem
The Analyst and the target are prepared (or the audit! both ,no'ing in advance all
the details o( the audit. A tandem audit tests the protection and controls o( the
target. 2o'ever! it cannot test the preparedness o( the target to un,no'n variables
o( agitation. The true nature o( the test is thoroughness as the Analyst does have (ull
vie' o( all tests and their responses. The breadth and depth depends upon the
+uality o( the in(ormation provided to the Analyst be(ore the test -transparency. as
'ell as the AnalystKs applicable ,no'ledge. This is o(ten ,no'n as an "n-2ouse Audit
or a ,rystal BoF test and the Analyst is o(ten part o( the security process.
C /eversal
The Analyst engages the target 'ith (ull ,no'ledge o( its processes and operational
security! but the target ,no's nothing o( 'hat! ho'! or 'hen the Analyst 'ill be
testing. The true nature o( this test is to audit the preparedness o( the target to
un,no'n variables and vectors o( agitation. The breadth and depth depends upon
the +uality o( the in(ormation provided to the Analyst and the AnalystKs applicable
,no'ledge and creativity. This is also o(ten called a )ed Team eFercise.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 3;
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.- )ules Of +ngagement
These rules de(ine the operational guidelines o( acceptable practices in mar,eting and selling testing!
per(orming testing 'or,! and handling the results o( testing engagements.
A. Sales and Mar$eting
. The use o( (ear! uncertainty! doubt! and deception may not be used in the sales or mar,eting
presentations! 'ebsites! supporting materials! reports! or discussion o( security testing (or the
purpose o( selling or providing security tests. This includes but is not limited to highlighting crimes!
(acts! glori(ied criminal or hac,er pro(iles! and statistics to motivate sales.
2. The o((ering o( (ree services (or (ailure to penetrate the target is (orbidden.
3. 3ublic crac,ing! hac,ing! and trespass contests to promote security assurance (or sales or
mar,eting o( security testing or security products are (orbidden.
8. To name past or present clients in the mar,eting or sales (or potential customers is only allo'ed i(
the 'or, (or the client 'as speci(ically the same as being mar,eted or sold and the named client
has provided 'ritten permission to do so.
N. "t is re+uired that clients are advised truth(ully and (actually in regards to their security and security
measures. "gnorance is not an e1cuse (or dishonest consultancy.
*. Assessment / Estimate 0eli#ery
C. 3er(orming security tests against any scope 'ithout e1plicit 'ritten permission (rom the target
o'ner or appropriate authority is strictly (orbidden.
O. The security testing o( obviously highly insecure and unstable systems! locations! and processes is
(orbidden until the proper security in(rastructure has been put in place.
C. Contracts and Negotiations
7. 4ith or 'ithout a Non-Disclosure Agreement contract! the security Analyst is re+uired to provide
con(identiality and non-disclosure o( customer in(ormation and test results.
P. Contracts should limit liability to the cost o( the *ob! unless malicious activity has been proven.
0. Contracts must clearly e1plain the limits and dangers o( the security test as part o( the statement o(
'or,.
. "n the case o( remote testing! the contract must include the origin o( the Analysts by address!
telephone number or "3 address.
2. The client must provide a signed statement 'hich provides testing permission e1empting the
Analysts (rom trespass 'ithin the scope! and damages liability to the cost o( the audit service 'ith
the e1ception 'here malicious activity has been proven.
3. Contracts must contain emergency contact names and phone numbers.
8. The contract must include clear! speci(ic permissions (or tests involving survivability (ailures! denial
o( service! process testing! and social engineering.
N. Contracts must contain the process (or (uture contract and statement o( 'or, -#%4. changes.
C. Contracts must contain veri(ied con(licts o( interest (or a (actual security test and report.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
3? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
0. Scope 0efinition
O. The scope must be clearly de(ined contractually be(ore veri(ying vulnerable services.
7. The audit must clearly e1plain the limits o( any security tests according to the scope.
E. Test Plan
P. The test plan may not contain plans! processes! techni+ues! or procedures 'hich are outside the
area o( e1pertise or competence level o( the Analyst.
1. Test Process
20. The Analyst must respect and maintain the sa(ety! health! 'el(are! and privacy o( the public both
'ithin and outside the scope.
2. The Analyst must al'ays operate 'ithin the la' o( the physical location-s. o( the targets in addition
to rules or la's governing the AnalystKs test location.
22. To prevent temporary raises in security (or the duration o( the test! only noti(y ,ey people about the
testing. "t is the clientKs *udgment 'hich discerns 'ho the ,ey people areL ho'ever! it is assumed
that they 'ill be in(ormation and policy gate,eepers! managers o( security processes! incident
response personnel! and security operations sta((.
23. "( necessary (or privileged testing! the client must provide t'o! separate! access to,ens 'hether
they be pass'ords! certi(icates! secure "D numbers! badges! etc. and they should be typical to the
users o( the privileges being tested rather than especially empty or secure accesses.
28. 4hen testing includes ,no'n privileges! the Analyst must (irst test 'ithout privileges -such as in a
blac, bo1 environment. prior to testing again 'ith privileges.
2N. The Analysts are re+uired to ,no' their tools! 'here the tools came (rom! ho' the tools 'or,! and
have them tested in a restricted test area be(ore using the tools on the client organi0ation.
2C. The conduct o( tests 'hich are e1plicitly meant to test the denial o( a service or process or
survivability may only be done 'ith e1plicit permission and only to the scope 'here no damage is
done outside o( the scope or the community in 'hich the scope resides.
2O. Tests involving people may only be per(ormed on those identi(ied in the scope and may not
include private persons! customers! partners! associates! or other e1ternal entities 'ithout 'ritten
permission (rom those entities.
27. Eeri(ied limitations! such as discovered breaches! vulnerabilities 'ith ,no'n or high e1ploitation
rates! vulnerabilities 'hich are e1ploitable (or (ull! unmonitored or untraceable access! or 'hich
may immediately endanger lives! discovered during testing must be reported to the customer 'ith
a practical solution as soon as they are (ound.
2P. Any (orm o( (lood testing 'here a scope is over'helmed (rom a larger and stronger source is
(orbidden over non-privately o'ned channels.
30. The Analyst may not leave the scope in a position o( less actual security than it 'as 'hen
provided.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 3@
OSSTMM 3 The Open Source Security Testing Methodology Manual
). !eporting
3. The Analyst must respect the privacy o( all individuals and maintain their privacy (or all results.
32. /esults involving people untrained in security or non-security personnel may only be reported via
non-identi(ying or statistical means.
33. The Analyst may not sign test results and audit reports in 'hich they 'ere not directly involved.
38. /eports must remain ob*ective and 'ithout untruths or any personally directed malice.
3N. Client noti(ications are re+uired 'henever the Analyst changes the testing plan! changes the
source test venue! has lo' trust (indings! or any testing problems have occurred. Noti(ications must
be provided previous to running ne'! dangerous! or high tra((ic tests! and regular progress updates
are re+uired.
3C. 4here solutions and recommendations are included in the report! they must be valid and
practical.
3O. /eports must clearly mar, all un,no'ns and anomalies.
37. /eports must clearly state both discovered success(ul and (ailed security measures and loss
controls.
3P. /eports must use only +uantitative metrics (or measuring security. These metrics must be based on
(acts and void o( sub*ective interpretations.
80. The client must be noti(ied 'hen the report is being sent as to e1pect its arrival and to con(irm
receipt o( delivery.
8. All communication channels (or delivery o( the report must be end to end con(idential.
82. /esults and reports may never be used (or commercial gain beyond that o( the interaction 'ith
the client.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
-> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.9 The Operational Security Testing 'rocess
4hy test operationsU :n(ortunately! not everything 'or,s as con(igured. Not everyone behaves as
trained. There(ore the truth o( con(iguration and training is in the resulting operations. ThatKs 'hy 'e need
to test operations.
The %p#ec testing process is a discrete event test o( a dynamic! stochastic system. This means that you
'ill be ma,ing a chronological se+uence o( tests on a system that changes and does not al'ays give the
same output (or the input provided. The target is a system! a collection o( interacting and co-dependent
processes 'hich is also in(luenced by the stochastic environment it e1ists in. <eing stochastic means the
behavior o( events in a system cannot be determined because the ne1t environmental state can only be
partially but not (ully determined by the previous state. The system contains a (inite but possibly e1tremely
large number o( variables and each change in variables may present an event and a change in state.
#ince the environment is stochastic! there is an element o( randomness and there is no means (or
predetermining 'ith certainty ho' all the variables 'ill a((ect the system state.
&ost o( 'hat people understand o( %p#ec comes (rom the de(ensive aspect 'hich is understandable
since security is generally considered a de(ensive strategy. Aggressive testing o( %p#ec is then relegated
to the same class as the e1ploitation and circumvention o( the current design or con(iguration. 2o'ever!
the (undamental problem 'ith this techni+ue is that a design or con(iguration does not e+uate to
operation.
4e encounter many instances in li(e 'here operation does not con(orm to con(iguration. A simple
e1ample is a typical *ob description. "t is more common than not that the policy 'hich dictates oneKs *ob!
also ,no'n as a *ob description! (alls short (rom actually re(lecting 'hat 'e do on the *ob. Another
e1ample is the TE channel. <ecause a channel is set to a particular (re+uency -con(igured. it does not
mean 'e 'ill receive the sho' broadcast on that channel or only that sho'.
This security testing methodology is designed on the principle o( veri(ying the security o( operations. 4hile
it may not al'ays test processes and policy directly! a success(ul test o( operations 'ill allo' (or analysis o(
both direct and indirect data to study the gap bet'een operations and processes. This 'ill sho' the si0e
o( the ri(t bet'een 'hat management e1pects o( operations (rom the processes they developed and
'hat is really happening. &ore simply put! the AnalystKs goal is to ans'er) Rho' do current operations
'or, and ho' do they 'or, di((erently (rom ho' management thin,s they 'or,US
A point o( note is the e1tensive research available on change control (or processes to limit the amount o(
indeterminable events in a stochastic system. The Analyst 'ill o(ten attempt to e1ceed the constraints o(
change control and present R'hat i(S scenarios 'hich the change control implementers may not have
considered. A thorough understanding o( change control is essential (or any Analyst.
An operational security test there(ore re+uires thorough understanding o( the testing process! choosing
the correct type o( test! recogni0ing the test channels and vectors! de(ining the scope according to the
correct inde1! and applying the methodology properly.
#trangely! no'here! besides in security testing is the echo process considered the de(acto test. ;i,e yelling
into a cavernous area and a'aiting the response! the echo process re+uires interacting and then
monitoring emanations (rom the target (or indicators o( a particular state such as secure or insecure!
vulnerable or protected! on or o((! and le(t or right. The echo process is o( a cause and e((ect type o(
veri(ication. The Analyst ma,es the cause and analy0es the e((ect on the target. "t is strange that this is the
primary means o( testing something as critical as security because although it ma,es (or a very (ast test! it is
also highly prone to errors! some o( 'hich may be devastating to the target. Consider that in a security
test using the echo process! a target that does not respond is considered secure. 6ollo'ing that logic! a
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org -1
OSSTMM 3 The Open Source Security Testing Methodology Manual
target needs only to be non-responsive to a particular type o( re+uest to give the appearance o( security
ho'ever still be (ully interactive 'ith other types o( re+uests 'hich sho's there has been no separation.
"( hospitals used the echo process to determine the health o( an individual! it 'ould rarely help people!
but at least the 'aiting room time 'ould be very short. 2ospitals ho'ever! li,e most other scienti(ic
industries! apply the 6our 3oint 3rocess 'hich includes a (unction o( the echo process called the
RinteractionS as one o( the (our tests. The other three tests are) the Rin+uestS o( reading emanations (rom
the patient such as pulse! blood pressure! and brain 'avesL the RinterventionS o( changing and stressing
operating conditions such as the patientKs homeostasis! behavior! routine! or com(ort levelL and the
RinductionS o( e1amining the environment and ho' it may have a((ected the target such analy0ing 'hat
the patient has interacted 'ith! touched! eaten! dran,! or breathed in. 2o'ever! in security testing! the
ma*ority o( tests are based on the echo process alone. There is so much in(ormation lost in such one-
dimensional testing 'e should be than,(ul that the health care industry has evolved past *ust the RDoes it
hurt i( " do thisUS manner o( diagnosis.
The security test process in this methodology does not recommend the echo process alone (or reliable
results. 4hile the echo process may be used (or certain! particular tests 'here the error margin is small
and the increased e((iciency allo's (or time to be moved to other time-intensive techni+ues! it is not
recommended (or tests outside o( a deterministic environment. The Analyst must choose care(ully 'hen
and under 'hat conditions to apply the echo process.
4hile many testing processes e1ist! the 6our 3oint 3rocess (or security testing is designed (or optimum
e((iciency! accuracy! and thoroughness to assure test validity and minimi0e errors in uncontrolled and
stochastic environments. "t is optimi0ed (or real-'orld test scenarios outside o( the lab. 4hile it also uses
agitation! it di((ers (rom the echo process in that it allo's (or determining more than one cause per e((ect
and more than one e((ect per cause.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
-% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.: 3our 'oint 'rocess
The 6our 3oint 3rocess -833. brea,s do'n a test (rom start to conclusion. These are things that an
e1perienced testing group already does. DonKt con(use the (ormality in the dissection o( the process 'ith
the (ormality o( the reporting. 9ou donKt have to sho' every step being done but you should understand
ho' you got (rom A to C. "t is li,e giving people driving directions. 9ou tell them the steps on 'here they
turn and relative pro1imity to things that they 'ill see to ,no' they are going the right 'ay but you donKt
tell them every street they drive do'n and every tra((ic signal they must obey to get to the end. 4ell! the
833 is the speci(ic directions and the means and reporting are actually the relativistic ones.
. nductionB -A. establishing principle truths about the target (rom environmental la's and (acts. The
Analyst determines (actual principles regarding the target (rom the environment 'here the target
resides. As the target 'ill be in(luenced by its environment! its behavior 'ill be determinable 'ithin this
in(luence. 4here the target is not in(luenced by its environment! there e1ists an anomaly to be
understood.
2. n*uestB -C. investigating target emanations. The Analyst investigates the emanations (rom the
target and any trac,s or indicators o( those emanations. A system or process 'ill generally leave a
signature o( its e1istence through interactions 'ith its environment.
3. nteractionB -A5<. li,e echo tests! standard and non-standard interactions 'ith the target to trigger
responses. The Analyst 'ill in+uire or agitate the target to trigger responses (or analysis.
8. nterventionB -W595A. changing resource interactions 'ith the target or bet'een targets. The
Analyst 'ill intervene 'ith the resources the target re+uires (rom its environment or (rom its
interactions 'ith other targets to understand the e1tremes under 'hich it can continue operating
ade+uately.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org -3
'nteractions /ithin the : +oint +rocess
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.; The Trifecta
This security testing methodology has a solid base 'hich may seem +uite involved! but it is actually simple
in practice. "t is designed as a (lo'chartL ho'ever! unli,e the standard (lo'chart! the (lo'! represented by
the arro's! may go bac,'ard as 'ell as (or'ard. "n this 'ay! it is more integrated and 'hile the
beginning and the end are clear! the audit has greater (le1ibility. The Analyst creates a uni+ue path
through the methodology based on the target! the type o( test! the time allotted (or the audit! and the
resources applied to the test. 6or an orchestra! the composer 'rites the sheet music to designate the
order and duration o( notes! but only the conductor can control the e1ecution o( the per(ormance. This
methodology is li,e the sheet music! designating the necessary tests! but the Analyst controls the order!
the duration! as 'ell as the e1ecution. The main reason (or re+uiring this level o( (le1ibility in the %##T&& is
because no methodology can accurately presume the *usti(ications (or the operations o( channel
gate'ays in a target and their ade+uate level o( security. &ore directly! this methodology cannot
presume a best practice (or conducting all audits! as best practice is based on a speci(ic con(iguration o(
operations.
<est practice is only best (or someL generally the originator o( the practice. %perations dictate ho'
services should be o((ered! and those services dictate the re+uirements (or operational security. There(ore!
a methodology that is invo,ed di((erently (or each audit and by each Analyst can still have the same end
result i( the Analyst completes the methodology. 6or this reason one o( the (oundations o( the %##T&& is
to record precisely 'hat 'as not tested. <y comparing 'hat 'as tested and the depth o( the testing 'ith
other tests! it is possible to measure operational security -%p#ec. based on the test results.
Applying this methodology 'ill there(ore meet the AnalystKs goal to ans'er the (ollo'ing three +uestions
'hich ma,e up the Trifecta! the ans'er to %p#ec needs.
2. 'o3 do current operations 3or$4
The derived metrics can be applied to determine the problem areas 'ithin the
scope and 'hich problems must be addressed. The metrics in this methodology are
designed to map the problems in di((erent 'ays so as to sho' i( the problem is a
general one or more speci(ic! li,e an overloo, or a mista,e.
5. 'o3 do they 3or$ differently from ho3 management thin$s they 3or$4
Access to policies or a trust -or even a ris,. assessment 'ill map bac, to the
di((erent categories o( the metrics. The categories provide the current state values
'here a comparison can be made 'ith both an optimum state according to the
policies and one according to assessed threats.
6. 'o3 do they need to 3or$4
4here the metrics sho' no gap bet'een policy or trust -or ris,. assessmentKs
optimum values yet the security test sho's that there is indeed a protection
problem regardless o( controls as implemented in policy! it is possible to clearly
denote a problem. %(ten! 'ithout even mapping to policy! a discrepancy
bet'een the implemented controls and the loss o( protection is simply evident.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
-- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Combining the Trifecta and the 7 Point Process
The Tri(ecta combined 'ith the 6our 3oint 3rocess provide a substantially thorough application o( this
methodology. The steps in this application can be summari0ed as (ollo's)
. 3assively collect data o( normal operations to comprehend the target.
2. Actively test operations by agitating operations beyond the normal baseline.
3. Analy0e data received directly (rom the operations tested.
8. Analy0e indirect data (rom resources and operators -i.e. 'or,ers! programs..
N. Correlate and reconcile intelligence (rom direct -step 3. and indirect -step 8. data test results to
determine operational security processes.
C. Determine and reconcile errors.
O. Derive metrics (rom both normal and agitated operations.
7. Correlate and reconcile intelligence bet'een normal and agitated -steps and 2. operations to
determine the optimal level o( protection and control 'hich 'ould best be implemented.
P. &ap the optimal state o( operations -step 7. to processes -step N..
0. Create a gap analysis to determine 'hat enhancements are needed (or processes governing
necessary protection and controls -step N. to achieve the optimal operational state -step 7. (rom
the current one.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org -9
Co"inin$ the ,ri&ecta an% the : +oint +rocess
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.? +rror 0andling
The veracity in a security test is not in the sum o( its errors! but rather in the accounting (or its errors. #ince
errors may not be the (ault o( the Analyst! the understanding o( ho' and 'here errors can e1ist 'ithin a
test is much more reasonable than e1pecting an Analyst to test 'ithout error. 6urthermore! it is the Analyst
'ho attempts 'hat should not be possible that is most li,ely to encounter errorsL there(ore! denoting errors
as a negative thing discounts the practice o( thorough testing.
+rror Type .escription
6alse 3ositive
(o"ethin$ %eter"ine% as true is actuall! re.eale% &alse.
The target response indicates a particular state as true although in reality
the state is not true. A (alse positive o(ten occurs 'hen the AnalystKs
e1pectations or assumptions o( 'hat indicates a particular state do not
hold to real-'orld conditions 'hich are rarely blac, and 'hite.
2 6alse Negative
(o"ethin$ %eter"ine% as &alse is actuall! re.eale% as true.
The target response indicates a particular state as not true although in
reality the state is true. A (alse negative o(ten occurs 'hen the AnalystKs
e1pectations or assumptions about the target do not hold to real-'orld
conditions! the tools are not ade+uate (or the test! the tools are misused! or
the Analyst lac,s e1perience. A (alse negative can be dangerous as it is a
misdiagnosis o( a secure state 'hen it does not e1ist.
3 @ray 3ositive
(o"ethin$ ans/ers true to e.er!thin$ e.en i& &alse.
The target response indicates a particular state as true! ho'ever the target
is designed to respond to any cause 'ith this state 'hether it is true or not.
This type o( security through obscurity may be dangerous! as the illusion
cannot be guaranteed to 'or, the same (or all stimuli.
8 @ray Negative
(o"ethin$ ans/ers &alse to e.er!thin$ e.en i& true.
The target response indicates a particular state as not true! ho'ever the
target is designed to respond to any cause 'ith this state 'hether it is true
or not. This type o( security through obscurity may be dangerous! as the
illusion cannot be guaranteed to 'or, the same (or all stimuli.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
-: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
+rror Type .escription
N #pecter
(o"ethin$ ans/ers either true or &alse ut the real state is re.eale% as
unkno/n.
The target response indicates a particular state as either true or (alse
although in reality the state cannot be ,no'n. A specter o(ten occurs
'hen the Analyst receives a response (rom an e1ternal stimulus that is
perceived to be (rom the target. A specter may be intentional! an
anomaly (rom 'ithin the channel! or the result o( carelessness or
ine1perience (rom the Analyst. %ne o( the most common problems in the
echo process is the assumption that the response is a result o( the test.
Cause and e((ect testing in the real 'orld cannot achieve consistently
reliable results since neither the cause nor the e((ect can be properly
isolated.
C "ndiscretion
(o"ethin$ ans/ers either true or &alse %epen%in$ /hen it9s aske%.
The target response indicates a particular state as either true or (alse but
only during a particular time! 'hich may or may not (ollo' a pattern. "( the
response cannot be veri(ied at a time 'hen the state changes! it may
prevent the Analyst (rom comprehending the other state. An Analyst may
also determine that this is an anomaly or a problem 'ith testing
e+uipment! especially i( the Analyst (ailed to calibrate the e+uipment prior
to the test or per(orm appropriate logistics and controls. An indiscretion
can be dangerous as it may lead to a (alse reporting o( the state o(
security.
O $ntropy $rror
,he ans/er is lost or con&use% in si$nal noise.
The target response cannot accurately indicate a particular state as either
true or (alse due to a high noise to signal ratio. A,in to the idea o( losing a
(lashlight beam in the sunlight! the Analyst cannot properly determine state
until the noise is reduced. This type o( environmentally caused error rarely
e1ists in a lab! ho'ever it is a normal occurrence in an uncontrolled
environment. $ntropy can be dangerous! i( its e((ects cannot be
countered.
7 6alsi(ication
,he ans/er chan$es %epen%in$ on ho/ an% /here the 4uestion is aske%.
The target response indicates a particular state as either true or (alse
although in reality the state is dependent upon largely un,no'n variables
due to target bias. This type o( security through obscurity may be
dangerous! as the bias 'ill shi(t 'hen tests come (rom di((erent vectors or
employ di((erent techni+ues. "t is also li,ely that the target is not a'are o(
the bias.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org -;
OSSTMM 3 The Open Source Security Testing Methodology Manual
+rror Type .escription
P #ampling $rror
,he ans/er cannot represent the /hole ecause the scope has een
altere%.
The target is a biased sample o( a larger system or a larger number o(
possible states. This error normally occurs 'hen an authority in(luences the
operational state o( the target (or the duration o( the test. This may be
through speci(ic time constraints on the test or a bias o( testing only
components designated as RimportantS 'ithin a system. This type o( error
'ill cause a misrepresentation o( the overall operational security.
0 Constraint
,he ans/er chan$es %epen%in$ on the li"itations o& the tools use%.
The limitations o( human senses or e+uipment capabilities indicate a
particular state as either true or (alse although the actual state is un,no'n.
This error is not caused by poor *udgment or 'rong e+uipment choices
rather it is a (ailure to recogni0e imposed constraints or limitations.
3ropagation
,he ans/er is presu"e% to e o& one state or the other althou$h no test
/as "a%e.
The Analyst does not ma,e a particular test or has a bias to ignore a
particular result due to a presumed outcome. This is o(ten a blinding (rom
e1perience or a con(irmation bias. The test may be repeated many times
or the tools and e+uipment may be modi(ied to have the desired
outcome. As the name implies! a process that receives no (eedbac,
'here the errors remain un,no'n or ignored 'ill propagate (urther errors as
the testing continues. 3ropagation errors may be dangerous because the
errors propagated (rom early in testing may not be visible during an
analysis o( conclusions. 6urthermore! a study o( the entire test process is
re+uired to discover propagation errors.
2 2uman $rror
,he ans/er chan$es %epen%in$ on the skill o& the Anal!st.
An error caused by lac, o( ability! e1perience! or comprehension is not one
o( bias and is al'ays a (actor that is present! regardless o( methodology or
techni+ue. 4hile an e1perienced Analyst may ma,e propagation errors!
one 'ithout e1perience is more li,ely to not recogni0e human error!
something that e1perience teaches to recogni0e and compensate (or.
#tatistically! there is an indirect relationship bet'een e1perience and
human error. The less e1perience an Analyst has! the greater the amount
o( human error an audit may contain.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
-? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Wor$ing 3ith Test Errors
During the analysis phase! an Analyst can ,eep trac, o( the +uantity and severity o( operation errors (rom
the test. A simple sel(-assessment can create a margin o( operation errors caused during the test 'hich
the Analyst can use to either (rame the thoroughness o( the current audit or other audits o( similar systems.
#ince it is a sel( assessment it 'ill have a tendency to be biased. The Analyst should ta,e great care (or it
to be as (actual as possible as a (orm o( +uality assurance o( the test and the test process. Although some
may try to dismiss test errors 'hich 'ere on the (ault o( the Analyst! ,eeping trac, o( all errors can only
improve (uture tests and is not something to hide. $rrors 'ill happen and are no more than the AnalystKs
attempt to interact 'ith an ever-changing system. /egardless o( the number and severity o( errors! the
trac,ing o( test errors 'ill serve as a record o( the di((iculty and comple1ity o( the audit and the
competency o( the Analyst to deduce the errors.
A record o( test errors (rom the scope 'ill also help sum up the environment in a simplistic 'ay. "t is a
straight-(or'ard reduction o( the $1ecutive #ummary 'hich o(ten describes the AnalystKs opinion about
the state o( security 'herein (e' to no errors 'ill sho' a (airly static target and environment. &any errors
sho' a chaotic environment and one that may lac, controls (or managing change or loss.
%verall! test error records are use(ul (or understanding the comple1ity o( the audit and change control
bet'een audits o( regular intervals.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org -@
OSSTMM 3 The Open Source Security Testing Methodology Manual
Test !esults
Test results are o(ten accompanied by recommended solutions or consulting o((ers! neither o( 'hich is re+uired
in an %##T&& audit. /ecommended solutions may be provided as a value-add to a security test but are not
considered mandatory. %(ten there are no proper solutions based on the limited vie' an Analyst has o( the
client environment. There(ore! solutions are not re+uired as part o( an %##T&& audit.
6re+uently! a test 'ill e1ceed the limits o( a security control. 4ithin an engagement! the Analyst must al'ays
report the (actual current state o( security! any limitations 'ithin that current state! and any o( the processes
'hich caused those limitations o( the applied controls and protections.
To measure both the thoroughness o( the test and the security o( the target! use o( this methodology should
conclude 'ith the Security Test &udit )eport -#TA/.! available 'ithin this manual or at the "#$C%& 'ebsite.
#TA/ re+uires the (ollo'ing in(ormation)
. Date and time o( test
2. Duration o( test
3. Names o( responsible Analysts
8. Test type
N. #cope o( test
C. "nde1 -method o( target enumeration.
O. Channel tested
7. Test Eector
P. Attac, sur(ace metric
0. 4hich tests have been completed! not completed! or partially completed! and to 'hat e1tent
. Any issues regarding the test and the validity o( the results
2. Any processes 'hich in(luence the security limitations
3. Any un,no'ns or anomalies
#uccess(ul use o( the %##T&& sho's an actual measurement o( security and controls. &isrepresentation o(
results in reporting may lead to (raudulent veri(ication o( security controls! and an inaccurate security level. 6or
this! the Analyst must accept responsibility and limited liability (or inaccurate reporting.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
9> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
%.@ .isclosure
During a security test the advent o( previously un,no'n or non-publici0ed security limitations may come to
light. 4hat an Analyst does 'ith these is (irst and (oremost a result o( the legal regulations o( the AnalystK s
region and the region 'here the 'or, is being per(ormed.
0isclosure !ights
4hat you do have to do is ma,e sure that your access to and use o( the product or solution did not
re+uire any sort o( provisions! Non-Disclosure contract! or $nd :ser ;icense Agreement -$:;A. that denies
you the right to claim! announce! or distribute any vulnerabilities discovered. "( it did and you or the client
accepted this contract then you canKt disclose to anyone! perhaps even the manu(acturer! 'ithout
potential legal repercussions. 6urthermore i( you 'or, (or the company ma,ing that product or are a legal
client o( theirs then you may not be able to legally disclose anything either. 6urthermore! your rights in any
case may be challenged according to the process o( la' in your region rather than e1isting legal
precedent.
!esponsibilities
2o'ever! i( those cases do not apply then you e((ectively o'n that vulnerability and the sooner you ma,e
it public the more rights you have as the o'ner. "n many countries! processes and in(ormation can be
protected by la' and o(ten the legal process re+uires publication or legally (iling such 'ith attribution. "(
your disclosure can do no 329#"CA; harm -li,e yelling (ire in a cro'ded movie theater.! it is yours to ma,e
and no legal posturing need sha,e you 'hen youKre right. 2o'ever! to be sa(est! you should also
promote! 'ith the disclosed vulnerability! the controls 'hich one can apply to (i1 the problem. 6or
e1ample! i( itKs a problem 'ith ho' one authenticates 'ith a solution then suggest an alternative
authentication scheme and ho' it can be success(ully integrated. 9ou do not need to 'ait (or the
manu(acturer to release a (i1 or a recall to let people (i1 the problem. 2o'ever! should you choose to
'or, 'ithin the conte1t o( noti(ying the manu(acturer! you 'ill need to give them ample time to address
the problem be(ore ma,ing it public. There is a valid argument that the vulnerability may already be
,no'n in criminal circles and need immediate attention. There(ore should you choose to publish 'ithout
the manu(acturerKs assistance! do note that including a (i1 'ill also sho' legally that you had good
intentions and much o( the legal system (ocuses on implied intent.
9our choice depends on 'hether (rivolous la'suits are accepted or prevalent in your region. /emember!
it is not you the Analyst 'ho is re+uired to do the +uality assurance testing (or the manu(acturer there(ore
you do not o'e them any in(ormation (rom 'or, youKve done even i( it includes their product.
6ull disclosure is help(ul as long as it can do no human! physical harm. 6urthermore! consumers should not
have to 'ait on manu(acturer (i1es (or their products to be secure. "( the product is not sold as a security
speci(ic solution then itKs up to the consumers to ma,e it secure and sa(e! or not use it. "( it is sold as secure
and sa(e then it is up to the manu(acturer to (i1 it ho'ever! the consumer may not 'ant to 'ait until the
manu(acturer can do so. 6ull disclosure allo's (or this choice.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 91
OSSTMM 3 The Open Source Security Testing Methodology Manual
The wea"ness is not found by analy1ing
what it is but rather in analy1ing what it
does.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
9% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 3 < Security &nalysis
#ecurity analysis here re(ers to the s,ill to turn in(ormation into security intelligence. This re+uires
understanding more than *ust the in(ormation but also 'here it came (rom! ho' and 'hen it 'as
collected! and any constraints o( the collection process. The (inal part o( the analysis process is to create
actionable intelligence! in(ormation derived (rom (act that can be used to ma,e decisions. This is the
clear distinction bet'een security and ris, analysis. "n security analysis! you produce (acts even i( that (act
states something canKt be ,no'n (rom the in(ormation provided. "n ris, analysis! you speculate and derive
opinions based on in(ormation. /is, analysis can use security analysis to come up 'ith better! more
accurate ans'ers ho'ever security analysis cannot use ris, analysis to improve accuracy. 6or this reason
'e recommend trust analysis.
Analying the Security of E#erything
The (undamental di((erence bet'een doing a ris, analysis versus a security analysis is that in security
analysis you never analy0e the threat. This is because assuming you ,no' 'hat threats e1ist! 'hen they
may hit! ho' they 'ill come! and 'here they 'ill go is something reserved (or ris, analysis. "n security
analysis! you study and measure the attac, sur(ace o( and around a target. This 'ill allo' you then to
understand 'here the threats! any threats! can attac, i( they do attac,. 6or e1ample! consider a long!
high 'all. The ris, analysis 'ill consider 'hat can get through the 'all but the security analysis 'ill (ocus on
'here the crac,s are! i( the (oundation is solid! and i( the 'all is thic, or tall enough to prevent Access
long enough (or help to arrive and respond to the attac,. A security analysis 'ill also allo' you to assure
the right controls e1ist! 'or, the 'ay they should! and properly cover the interactive points o( the various
accessible vectors and channels.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 93
OSSTMM 3 The Open Source Security Testing Methodology Manual
3.1 ,ritical Security Thin"ing
Critical security thin,ing as used here is a term (or the practice o( using logic and (acts to (orm an idea
about security. That idea may be an ans'er! a conclusion! or a characteri0ation o( something or
someone so that veri(ication tests can be 'ell de(ined. As an ans'er or a conclusion! critical security
thin,ing 'ill provide that 'hich ma,es the most sense. As a characteri0ation! it 'ill sho' you 'hat you
need to veri(y! according to 'hat you need to veri(y! according to 'hat vector! ho'! and 'hat the
targets 'ill be. "t 'ill also help you respect di((erent opinions or vie'points beyond security itsel( to the
interconnectedness security ma,es 'ith people! places! processes! and money. "t 'ill help you address
contradictory conclusions and e1plore alternate conse+uences. #o even i( the critical security thin,ing
model canKt provide an ans'er it should tell you 'hat (acts are still missing and (rom 'here you need to
get them.
The process o( critical security thin,ing is dependent on the Analyst being able to discern true statements
or at least recogni0e the degree o( possible (alsity or dynamic properties in a statement. %ne 'ay to do
this is to recogni0e the amount o( trust you can have in a (act through the use o( trust metrics. Another
'ay is to be able to deconstruct a statement! separating out (allacious arguments. "n practice! an Analyst
'ill need to do both. The Analyst 'ill need to have a good understanding o( 'hat is being analy0ed and
a good understanding o( logical (allacies used to ma,e +uali(iers! statements based on (allacious
concepts usually in the (orm o( a1ioms or best practices.
The Si, Step Analysis Techni8ue
:n(ortunately! the 'orld is not prescriptive. Not every +uestion has a right ans'er. The correctness o( an
ans'er is dependent on many things including! most importantly! ho' it is as,ed. This is a problem
a((ecting all industries but none so obviously as security 'hich is 'hy critical security thin,ing is so
important. As a techni+ue (or analysis it can be reduced to C simple steps to ascertain (actual results 'ith
a high trust level (or correctness even 'hen solutions are not linear li,e 'hen there is no connection (rom
point A to point <. There(ore the ability to validate sources and measure trust is crucial (or ma,ing proper!
actionable intelligence out o( tests. "n these steps! RtargetS re(ers to 'hatever you are analy0ing in
preparation o( a test! be it people! computers! buildings! or processes.
. <uild your ,no'ledge o( the target (rom a variety o( the most contemporary! (actual resources
'hile avoiding commercially biased and speculative in(ormation.
2. Determine the global level o( e1perience (or the type o( target and the amount o( in(ormation
possibly ,no'n about it.
3. Determine any bias or ulterior motives in the in(ormation sources.
8. Translate *argon (rom in(ormation sources to similar or ,no'n 'ords (or comparison because 'hat
may sound ne' or complicated may *ust be a tric, to di((erentiate something common.
N. <e sure the test e+uipment has been properly calibrated and the test environment veri(ied to
assure the results are not contaminated by the test itsel(.
C. Assure that the translation state o( tools or test processes has been removed as much as possible
so that the results do not come (rom the indirect sources in a process or the pre-analysis (rom some
tools.
4hatKs most important to understand here is 'hen ma,ing a characteri0ation donKt 'orry about being
right. "tKs more important to be right about being 'rong or right 'hich means the right tests 'ere made to
veri(y the characteri0ation. Then i( the characteri0ation is 'rong 'e at least ,no' (or sure it is 'rong and
can re-characteri0e. ThatKs ho' the scienti(ic method 'or,s. "tKs not about believing or relying on your
e1perience! no matter ho' vast! but on ,no'ing (acts 'e can build upon.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
9- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
1allacies as 9ualifiers
An additional problem o( the humani0ation o( testing into an art (orm rather than handled as a science is
that it introduces all sorts o( ne' errors. :nderstanding our o'n limitations as humans and ho' 'e thin,
in(luences ho' security can be perceived and de(ined. This leads many security pro(essionals to provide
+uali(iers (or 'hat they donKt understand or canKt deliver. &ost o(ten though they are *ust repeated as
a1ioms 'ithout (urther thought! eventually accepted as truths o( security. This (urther hurts our ability to
provide proper security because our analysis is perverted by catch phrases and best practices that may
have no basis in (act no' or ever.
6or e1ample! some common a1ioms still in use 'ill seem much less li,e golden rules and more li,e e1cuses
'hen put to the light o( critical security thing. These a1ioms are so common because there is a general
inability to thin, critically about security or separate it (rom ris, as a concept. #ecurity is not about ris,. "t is
about protection and controls. /is, is about ris,. /is, is speculated! contrived! derived! and correlated. /is,
is also sub*ective. #ecurity should not be. To better understand ho' these +uali(iers taint our ability to
ma,e good security analysis! 'e can e1amine the (allacies in the common +uali(iers)
1. There is no such thing as 1>>G secure.
The statement (ails to provide conditions such as time and the metric (or 'hich percentages
can be used as the scale. As a ris, statement! it could hold true- RThere is no such thing as
al'ays being 00V ris, (ree.S because under the de(inition o( ris,! even our o'n bodies are
sub*ect to time and sel(-in(licted in*uries. 2o'ever as a security statement it can have (ar too
many e1ceptions to be true.
%. +ven if you are secure, if an attac"er wants in badly enough theyDll get in.
The statement (ails to provide the condition o( time! 'hich (or any human attac,er 'ould be
(inite! and includes a (orm o( the e+uivocation (allacy 'hich +uali(ies the attac,erKs desire.
There(ore! i( no attac,er has entered then they apparently didnKt 'ant in Rbadly enoughS.
6urthermore! the statement ma,es a use o( the phrase Rget inS too broadly so that the idea is
gaining entry but could be (urther applied to any number o( potential! harm(ul attac,s.
3. There is no perfect security.
The statement (ails to provide the condition o( time implying the a1iom means ReverS 'hich is
itsel( an absolute and di((icult to prove. This short statement also (alls into the categories o( t'o
logical (allacies! the Nirvana (allacy and the 3er(ect #olution (allacy. "n the Nirvana (allacy! 'e
are mislead to re*ect something because it cannot be per(ect. 2o'ever! it can be good
enough (or oneKs needs. "n the 3er(ect #olution (allacy! the argument assumes a per(ect
solution even e1ists. This assumption is easy to argue in terms o( products (or those 'ho only
understand security concepts in terms o( products. "n reality! Rper(ectS is a sub*ective concept
and 'hat may not be per(ect (or one person may indeed be per(ect (or another. 4ithin the
conte1t o( this manual! Rper(ectS means a per(ectly balanced e+uation 'hen calculating the
attac, sur(ace consisting o( %p#ec and ;imitations against Controls.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 99
OSSTMM 3 The Open Source Security Testing Methodology Manual
-. Security is a process not a product.
4hile this statement is meant to in(orm those 'ho thin, o( security in terms o( products! this
catchphrase actually uses the (allacies o( 6alse Dilemma and 3resumption to persuade. As a
6alse Dilemma! it states that there are only t'o choices! a product and a process and
there(ore security must be one or the other. As a 3resumption! the conclusion o( the statement
is already presumed as a process being the means to security. Together! these (allacies do not
allo' (or products and processes to combine in the (ormation o( security nor does it allo' (or
something else entirely di((erent. "n reality! the public de(inition o( security is ill de(ined and not
actually achievable! 'hich is the li,ely reason (or all these a1ioms in the (irst place. This leaves
room (or many interpretations o( 'hat security can be and the main reason 'hy the Analyst
must commit to an achievable! measurable de(inition o( security. To state then that security is
one thing or another is (alse especially 'hen security itsel( is unde(ined and lends itsel( to
standard! dictionary interpretations. "t is also 'hy this manual clearly de(ines security as
something measurable.
An Analyst is re+uired to apply critical security thin,ing s,ills to in(ormation as it is provided as 'ell as to
statements 'hich are made about the analy0ed in(ormation to (orm (actual intelligence. "ntelligence
created in such a manner 'ill provide accurate and unbiased metrics as 'ell as a clear understanding o(
ho' security is de(icient 'ithout the need (or +uali(iers.
3.% )ecogni1e the OpSec Model
There are t'o problems 'ith security analysis in practical use on operations. The (irst is that technology is
o(ten (ar ahead o( every AnalystKs ability to understand ho' all o( it 'or,s! i( this ,no'-ho' is even
possible to obtain under the current closed-bo1 status o( most commercial technology products. The
second problem is that ironically! the deconstruction o( ho' something 'or,s! including business
processes! may be illegal in order to protect the (inancial ris, and privacy o( the manu(acturer (rom the
buyer even though as a user o( the product! the buyer may actually need that in(ormation to protect
themselves (rom real threats 'hich are probably not their customers. 2o'ever! even in cases 'here a
technology or process cannot be analy0ed directly! the product can be analy0ed 'ithin the environment
'ith 'hich it interacts.
6or each vector and channel that is analy0ed! the Analyst 'ill be putting an overlay o( the %p#ec model
over the targets. To apply the %p#ec model is simply to count the controls (or each interactive point o(
Access or Trust as 'ell as the discovery o( opportunity in the (orm o( Eisibility. 4here a target is an
un,no'n li,e a blac, bo1 'hich canKt be opened! the Analyst needs to address the controls over the
systemKs interactions in its environment. The process 'ill loo, li,e this)
. 4hat is visible in the scopeU 4hat is o( possible value that is ,no'nU 4hat targets can be
determinedU
2. 4hat are the interactive Access points to those targets and (rom 'hat vector or channelU
3. 4hat are the Trusts 'ithin the scope and over 'hat vector or channelU
8. 4hich are the controls (or those Accesses and TrustsU
N. Are the controls complete or do they have limitationsU
$ven a +uic, application o( the %p#ec model 'ill tell you i( an Access or a Trust is balanced 'ith controls.
This 'ill tell you the si0e o( the attac, sur(ace and 'hich interactive points are open 'ithout any controls
to govern them.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
9: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
3.3 2oo" for 'attern Matching as a Sign of +rrors
"( you begin by loo,ing (or e1actly 'hat you see, then you may only (ind 'hat you e1pect to (ind. This is
ade+uate 'hen loo,ing (or matching soc,s but not so good 'hen loo,ing at the big picture o( an attac,
sur(ace. "t is the ma*or problem ,no'n as pattern matching! the human trait to s,ip over steps! sometimes
un,no'ingly! 'hich are considered unnecessary due to an RobviousS outcome. "t also ma,es people see
cause and e((ect 'here there may be none. "t is a blind spot 'hich Analysts 'ill develop a(ter years o(
doing initial! basic! or redundant tas,s. These tas,s are made more e((icient through short-cuts 'hich
a((ect the +uality o( the veri(ication tests and ultimately the analysis.
6or actionable intelligence! a result is only as good as the methods used to get them. Not ,no'ing ho'
you got a particular result 'ill severely limit the action you can ta,e to (i1 it. 4hen an Analyst uses pattern
matching to s,ip steps! the method cannot be properly ,no'n. #till! the desire to Rcut to the chaseS to get
to the meat o( a problem 'hile presuming a state 'hich is actually un,no'n is a problem in many areas
o( science. #ecurity is no e1ception. There(ore an Analyst must recogni0e 'hen tests have been s,ipped
or the data (udged to provide unveri(ied results.
To detect pattern matching! e1amine the test methods and result data (or the (ollo'ing)
. Tests using speci(ic threats instead o( a thorough interaction 'ith the attac, sur(ace.
2. The lac, o( details on resulting processes behind interactions 'ith the target.
3. ;ittle or no in(ormation about controls (or various targets.
8. %nly some o( the targets are reported (or certain tests and those have completely negative results.
N. Targets not tested (or reasons 'hich are anecdotal -notes 'here a person has said there is nothing
there to test or has been secured..
C. Tests o( targets 'hich have obviously not been secured.
3.- ,haracteri1e the )esults
The scienti(ic method is not a chec,list. "t is a process 'hich allo's (or intelligence and imagination. A
hypothesis is made and then data is collected through testing and observation to evaluate that
hypothesis. "n a security test! a hypothesis is essentially made 'henever a veri(ication is made against a
direct or indirect interactive point in the scope. The Analyst has the empirical data (rom those tests and
must consider i( the tests actually veri(ied the hypothesis. 4ere the right tests madeU 4ere enough tests
madeU 4ere the right channels or vectors testedU 4ere ne' interactions created that 'ere also then
testedU To do this! 'e characteri0e the results.
To characteri0e a security test using the scienti(ic method is to discover the properties o( the scope to
assure the correct tests 'ere made (or it. The tester ma,es a hypothesis as to the interactivity o( a point in
the attac, sur(ace. The test 'ill return that the point is interactive and adds to the attac, sur(ace or not
interactive and 'hether it still adds to the attac, sur(ace! controls in place! any limitations in those
controls! any limitations in the de(ined security! and any anomalies. At this point the Analyst may be
'rong about the (unction o( the process in operation ho'ever the Analyst may not be 'rong in 'hich
tests should be used to veri(y 'hat the (unction actually is. This is 'hy both ,no'ledge o( the process and
creatively imagining the indirect interaction are necessary.
6or e1ample! the Analyst may characteri0e a process as including the interaction bet'een a visitor and
the net'or, via the access card. #o 'hile this visitor does not have the credentials to access the net'or,!
because the card reader is tied into the computer system! that visitor does access the net'or, by s'iping
the card. The Analyst must consider ho' to test 'hat happens 'hen the visitor interacts 'ith the card
reader to gain access as 'ell as the side e((ects o( having the card read. 2o'ever! even i( the tests sho'
that the card reader is connected to a stand-alone computer system and is not attached to the net'or,!
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 9;
OSSTMM 3 The Open Source Security Testing Methodology Manual
the Analyst has properly veri(ied that the right tests 'ere made against the right targets to get that
ans'er.
There(ore! the Analyst 'ill e1amine the scope (or 'here an interaction might occur as 'ell as 'here
operations sho' interactions do occur. This 'ill allo' a characteri0ation o( the points o( interaction! any
possible indirect interactions! and all side e((ects (rom such interactions. This characteri0ation must be
then matched 'ith the tests made to determine i( all the correct tests 'ere made.
3.9 2oo" for Signs of ntuition
%ne thing that machines are clearly better than humans at is consistency. 2umans generally get bored!
con(used! or careless. 4hen a machine counts coins! it doesnKt lose count and need to start over. "t
doesnKt doubt itsel( and start over. "t also 'onKt use intuition. Also called Rgut instinctS the po'er o(
intuition is incredible. "t allo's people to imagine! apply creativity to a *ob! and ,no' 'hen something
(eels 'rong. "tKs part o( the human condition to subconsciously detect problems and prepare
accordingly. 2o'ever itKs e1actly this that sometimes leads us to ma,e mista,es. This is never more
obvious than 'hen 'e count large amounts o( similar-loo,ing ob*ects. 4ithout total concentration! 'e
may begin to (eel uneasy about the tally and eventually 'e may (eel compelled to either start over or *ust
accept a particular correct-sounding number 'here 'e thin, 'e le(t o(( and continue (rom there.
There is a time 'hen a test re+uires precise concentrationL during a large number o( repetitive se+uences.
@enerally! 'e tend to create tools to handle this type o( repetition ho'ever it may not al'ays be possible
due to the dynamic nature o( the test li,e 'hen interacting 'ith people instead o( inanimate ob*ects or
machines. #o as the test progresses! the tester may use intuition to ma,e the presumption that the test 'ill
be unnecessary. The Analyst must pay special attention to these tests and loo, (or signs o( intuition in part
o( the tester.
#igns o( trouble (rom intuition in tests are)
. "nconsistencies o( types o( tests per(ormed across multiple! similar targets.
2. The number o( tests decrease bet'een targets.
3. The length o( time (or tests decrease bet'een targets.
8. The same target tested more than once 'ith the same tests.
Detection o( intuition in tests 'ill sho' an inade+uate testing process and the +uality o( the results should
be regarded 'ith suspicion. /e-testing may be necessary.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
9? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
3.: Transparent )eporting
/arely 'ill a security analysis end 'ith all the ans'ers. #ince the tests 'ill depend on the %p#ec and
controls o( a particular channel and vector there 'ill be un,no'ns. There may be a visible target 'hich
provides no interaction and no (urther in(ormation about that target can be determined (rom this vector
and this channel. This is correct. The Analyst should report 'hat has been (ound 'ith certainty and not
merely 'hat could be. There is no place (or guessing 'hen measuring an attac, sur(ace.
"n addition to in(ormation about the test itsel( as to ho' it 'as made! the Analyst 'ill need to report the
(ollo'ing O test results)
1. #n"nowns
As more vectors and channels are analy0ed! more in(ormation 'ill be available and that 'hich is
reported 'ill change and provide actionable intelligence. Conversely! maybe more results are
inconclusive or the correlation o( results provide con(licting ans'ers! the resulting actionable intelligence is
un,no'n. :n,no'n is a valid ans'er to report. 4hat cannot be ,no'n is as valid and as important in
security as 'hat is discovered. 4hat is un,no'n sho's 'hat is di((icult to test or analy0e. The un,no'n
need not be seen as a (ailure o( the tester rather it may be caused by superior protection or an attac,
that uses a large cost o( time or resources not possible in a test. No Analyst should (ear reporting
something is un,no'n. "t is a po'er(ul result to base (urther ris, analysis upon.
%. #ntested Targets
Additionally! the Analyst needs to report another type o( un,no'n - targets in the scope 'hich have not
been tested in a particular vector or channel. "( a test cannot be completed because o( time constraints!
tool limitations! targets being unstable! the test environment being too dynamic or too noisy to collect
proper results! or because the tests 'ere not 'anted by the target o'ner then this needs to be ,no'n. <y
reporting 'hat 'as not tested! it is possible to do proper test comparisons 'ith (uture tests. "t 'ill also help
avoid cheating by only testing the 'ell protected segment o( a scope and ignoring the rest to create the
illusion o( a small attac, sur(ace.
3. dentified and $erified 2imitations
<esides un,no'ns! the Analyst must also report any identi(ied and veri(ied limitations such as vulnerabilities
in the targets. An identi(ied limitation is one 'hich has been determined through ,no'ledge and
correlation. This is use(ul 'hen the tests themselves are dangerous or very costly. #ometimes a test can be
damaging to a target or cause unacceptable or even criminal collateral damage. A veri(ied limitation is
one 'here the problem has been speci(ically tested to determine i( it e1ists.
-. 3alse 'ositives and the Means to 4enerate Them
During tests! some identi(ied limitations 'ill not be vulnerable to those particular attac,s during
veri(ication. This! ho'ever does not conclude that the target does not have those limitations. "t only
means that particular test at that particular time and (rom that particular tester did not e1pose the
vulnerability as identi(ied. "t could also mean the target is vulnerable but is protected by a particular
control. #uch determined (alse positives should be reported so that during (urther development o(
protective and de(ensive techni+ues! the problem can be loo,ed at more closely! particularly (rom a
di((erent vector.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 9@
OSSTMM 3 The Open Source Security Testing Methodology Manual
9. 3ailed Security 'rocesses and 'rocedures
During analysis! test results 'ill sho' more than *ust the %p#ec! types o( controls! and number o( limitations.
"t 'ill sho' a bigger picture! one o( processes and procedures that are in use to (ormali0e protective
measures. These can be about anything that are designed to get the protection measures to their current
state. This includes but is not limited to maintenance! procurement! identi(ication! authori0ation!
house,eeping! disaster recovery! partner relations! policy generation! climate control! and human
resources. 4hen a target has a limitation o(ten times there is a (ailed process or procedure behind it. The
Analyst should be able to determine e1actly 'hat it is (rom the aggregate test results.
:. 4ood 'ractices
The term R<est 3racticesS is used to e1plain the best 'ay (or a person or organi0ation to do something.
:n(ortunately! this has been abused to the point 'here it no' means that itKs best (or everyone. This itsel(
has caused problems and 'asted resources. %ne 'ay to counter this problem is to use the aggregate
test results to sho' practices 'hich are success(ul. This 'ill sho' 'hat can be repeated (or e+uivalent
success in other areas o( the organi0ation and de(ining a customi0ed R<est 3racticeS (or them. "t 'ill also
lessen their reliance on industry-'ide <est 3ractices in (avor o( 'hat 'or,s best (or them.
;. ,ompliance
#hould speci(ic compliance ob*ectives need to be reached! the Analyst needs to use the correlated test
results to determine i( these ob*ectives have been met. This may need to be provided in a special (ormat
as determined by the auditor ho'ever the Analyst is best e+uipped to sho' 'hich test results provide the
necessary in(ormation.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
:> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
)is" assessment is a concept for selecting
security and controls based on presumed
ris". t wor"s for defining strategy. Security
testing however is verifying to what
completeness that security or those
controls eFist. t wor"s for defining
operations. To test you donDt ma"e a ris"
assessment because doing so would
restrict your potential and your findings.
&fter all, you shouldnDt be ma"ing the
same guesses they are.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org :1
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter - < Operational Security Metrics
%perational security metrics are the metrics 'e are most (amiliar 'ith in our lives. 4hen 'e measure the
height! 'idth! or length o( an ob*ect 'e are using an operational metric. 4hen 'e 'rite the date! have a
birthday! or as, the score o( a game 'e are using operational metrics. An operational metric is a constant
measurement that in(orms us o( a (actual count in relation to the physical 'orld 'e live in. They are
operational because they are numbers 'e can 'or, 'ith consistently (rom day to day and person to
person. "t is di((icult to 'or, 'ith relative or inconsistent measurements li,e choosing a speci(ic hue o(
yello' to paint a room! starting 'or, at sunrise! having the right (lavor o( stra'berry (or a mil,sha,e! or
preparing (or the ne1t threat to a((ect your organi0ationKs pro(its because the (actors have many
variables 'hich are biased or (re+uently changing bet'een people! regions! customs! and locations. 6or
this reason! many pro(essions attempt to standardi0e such things li,e (lavors! colors! and 'or, hours. This is
done through reductionism! a process o( (inding the elements o( such things and building them up (rom
there by +uanti(ying those elements. This 'ay! colors become (re+uencies! 'or, hours become hours and
minutes! (lavors become chemical compounds! and an attac, sur(ace becomes porosity! controls! and
limitations. The only real problem 'ith operational metrics is the re+uirement (or ,no'ing ho' to properly
apply the metric (or it to be use(ul.
The completion o( a thorough security test has the advantage o( providing accurate metrics on the state
o( security. As 'ith the use o( any metric. the less thorough the test! the less accurate the overall metric.
;ess s,illed or less e1perienced Analysts 'ill also adversely a((ect the +uality o( the metric *ust as people
'ho canKt tell time canKt build cloc,s! designers 'ithout the right tools canKt match colors e1actly! and
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
:% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
;sin$ ra.s to "easure an% track the securit! o& an!thin$ o.er ti"e.
OSSTMM 3 The Open Source Security Testing Methodology Manual
bre' masters 'ho canKt measure the ingredients in beer canKt ma,e similar batches repeatedly (or
mar,et. There(ore a success(ul security metric re+uires a test 'hich can be described as measuring the
appropriate vectors 'hile accounting (or inaccuracies and misrepresentations in the collected test data
as 'ell as the s,ills or e1perience o( the security pro(essionals per(orming the test. 6aults in these
re+uirements result in lo'er +uality measurements and (alse security determinations there(ore the metric
must also be simple enough to use 'ithout ma,ing it so simple that it tells nothing. 6urthermore! a proper
security metric must avoid the biases inherent in ris, assessments by assuring measurements have integrity.
These +ualities have been combined to create the ravs! an unbiased! (actual description o( an attac,
sur(ace.
-.1 4etting to 7now the )av
The rav is a scale measurement o( the attac, sur(ace! the amount o( uncontrolled interactions 'ith a
target! 'hich is calculated by the +uantitative balance bet'een operations! limitations! and controls.
2aving the ravs is to understand ho' much o( the attac, sur(ace is e1posed. "n this scale! 00 rav -also
sho'n as 00V rav (or simplicity o( understanding although not precisely a percentage. is per(ect
balance and anything less is too (e' controls and there(ore a greater attac, sur(ace. &ore than 00 rav
sho's more controls than are necessary 'hich itsel( may be a problem as controls o(ten add interactions
'ithin a scope as 'ell as comple1ity and maintenance issues.
The rav does not measure ris, (or an attac, sur(ace! rather it enables the measurement o( it. "t cannot say i( a
particular target 'ill be attac,ed ho'ever it can say 'here on a target it 'ill be attac,ed! 'hat types o(
attac,s the target can success(ully de(end against! ho' deep an attac,er can get! and ho' much damage
can be done. 4ith that in(ormation it is then possible to assess the trusts -and ris,s. much more accurately.
The rav is actually multiple separate calculations o( 3orosity! Controls! and ;imitations! that 'hen combined 'ill
sho' the si0e o( an attac, sur(ace in t'o practical 'ays. The (irst 'ay is in a straight calculation. "t is the
calculation o( the Delta! a number that describes the speci(ic e1posure o( that target. This is use(ul (or
determining ho' a ne' person! thing! or process 'ill change the operational security o( a ne' scope or as a
comparison bet'een multiple! single targets. This is also the easiest 'ay to see 3er(ect #ecurity! the per(ect
balance bet'een 3orosity! Controls! and ;imitations. The rav is displayed as a positive or negative number
'hich sho's ho' (ar a'ay the target is (rom a per(ect security balance. A positive delta sho's too much is
spent on controls in general or even i( the overspending is on too much o( one type o( control. A negative
delta sho's a lac, o( controls or controls themselves 'ith limitations 'hich cannot protect the target
ade+uately. This is a po'er(ul tool (or ,no'ing e1actly 'here and ho' resources are being spent to protect a
particular target. 2o'ever this is not ho' the rav is most use(ulL that is done best the second 'ay.
The second practical 'ay to display the attac, sur(ace is (or understanding the big picture. This is represented
as Actual #ecurity. 4here the Delta calculation is based on per(ect balance! the Actual #ecurity calculation
uses the Delta but also includes additional and redundant controls to provide a metric more people (riendly
and (amiliar. 2ere the rav representation is similar to ho' people use percentages. The rav is calculated 'ith a
base 0 logarithm! 'hich ma,es a more comprehensible representation. 4hile the rav is still a balance! per(ect
balance is set at 00 and calculations are made in respect to that. This 'ill allo' most people to have a +uic,
and easy overvie' o( all the targets in a scope or o( *ust a single target in relation to other targets. "t is
e1tremely (le1ible so multiple attac, sur(aces can be compared by Actual #ecurity even i( the scope or the
targets are very di((erent) PNV rav o( a scope 'ith 000 computer systems is comparable to PNV rav 'ith *ust 0
systems! 'hich can be again compared to a building 'ith a PNV rav. All three 'ill provide the same
in(ormation to a person that the protection o( the target is NV de(icient and there(ore e1posed to attac,. 4ith
this ,no'ledge! one can begin to assess ris, and determine 'hat is e1posed! 'hat is le(t uncontrolled! and i(
that NV is acceptable. #o (or 'hatever threat there is! it can only occur 'here the openings are and that 'ill
sharpen the e1actness o( a ris, analysis (rom broad s'ord to scalpel.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org :3
OSSTMM 3 The Open Source Security Testing Methodology Manual
What "s a !a# Li$e4
A rav is a little di((erent (rom other security measurements because the count is uni+ue (rom the scope. That is
li,e determining the overall si0e o( a person by counting all the cells in them and categori0ing them by 'hat
they do to determine the personKs overall health. 6or a rav! both the count and the operation are re+uired. This
is 'hy the rav can only be derived (rom operational security testing.
"magine a machine e1ists that can audit all the cells in
a human body. This machine 'or,s by monitoring the
cells in their environment and even prodding each cell
in a 'ay it can react to better categori0e its purpose.
4e could then see 'hat various cells do and ho' they
contribute to the overall ma,e-up o( the human body.
#ome cells ma,e up tissue 'alls li,e s,in cells do. #ome!
li,e 'hite blood cells! provide authentication and
attac, other cells 'hich are on its RbadS list. Then some
cells are (oreigners! li,e bacteria 'hich have entered at
some point and thrived. The machine 'ould classi(y all
the cells that ma,e up the person! a de(ined scope!
rather than say 'hich are RbadS or RgoodS.
<y counting the cells the machine can tell mostly ho'
'ell the person as an organism 'or,s -health. and ho'
'ell they (it into their current environment. "t can also
determine 'hich cells are bro,en! 'hich are
super(luous! and o( 'hich type more might be re+uired
(or the person to be more e((icient! prepared (or the
une1pected! or (or any number o( speci(ic
re+uirements. #ince the cells are dividing and dying all
the time! the machine must also ma,e regular tests and
chart the personKs ability to improve or at least maintain
homeostasis.
No' in addition to counting cells and seeing ho' they
'or,! the machine 'ill also see 'ith 'hich other cells or
under 'hat conditions they interact and ho' 'ell. "n
each operation o( the cellKs duties the machine can
determine 'hat the cells limitations are. #o i( it 'as
possible (or the machine to also repair a problem in
(aulty cells directly! (orti(y the body by changing the
process o( the cells! or removing the unnecessary cells! 'e 'ould be able to directly a((ect the health o( the
body as a 'hole 'ith each change. %r perhaps 'e might change the environment that the body is e1posed
to instead o( the cells to ma,e more global changes. <y sub*ecting the person to better nutrition! diet! or
e1ercise 'e 'ill also change the body on a cellular level. All this is possible by ,no'ing ho' things 'or, inside
the body and 'hatKs there in these operations.
:n(ortunately there is no such machine (or counting all cells in a human body. 2o'ever it does e1ist (or security.
Analysts can count and veri(y the operations o( targets in a scope as i( it is a super-organism. They record its
interactions and the controls surrounding those interactions. They classi(y them by operation! resources!
processes! and limitations. Those numbers the Analysts generate are combined so that controls add to
operational security and limitations ta,e a'ay (rom it. $ven the value o( the limitations! ho' badly each type
o( problem hurts! is also not arbitrary because itKs based on the combination o( security and controls 'ithin that
particular scope. #o a bad problem in a protective environment 'ill provide less over-all e1posure than one in
a less controlled environment.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
:- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
,he ra.s are like countin$ cells an% classi&!in$ the" ! /hat the!
%o to %eter"ine ho/ /ell the or$anis" &its into an en.iron"ent.
OSSTMM 3 The Open Source Security Testing Methodology Manual
Eight 1undamental Security Ans3ers
The rav does not represent ris, 'here ris, is ,no'n as /is, X Threat 1 Eulnerability 1 Asset. "n that e+uation!
ris, is the result o( an in(ormed! ho'ever highly biased! e+uation. "( 'e can remove most o( the bias by
,no'ing the level o( protection and there(ore the level o( vulnerability impact! 'e can reduce the bias in
that e+uation and give a much better ris, assessment. There(ore! the rav is actually the (actual
(oundation (or a ris, assessment 'here an Analyst has (acts to 'or, 'ith. The real po'er o( the rav
ho'ever is ho' it can provide ans'ers to the (ollo'ing eight (undamental security +uestions 'ith great
accuracy.
. <o/ "uch "one! shoul% e spent on securit!2
The rav 'ill sho' the current amount o( protection to ma,e security pro*ections and
de(ine milestones even be(ore buying a particular solution or implementing some
ne' process. 6rom these pro*ections and milestones! (inancial restrictions can be
created to meet the goals and get the most speci(ic results (rom the investment. <y
,no'ing e1actly 'hat is controlled based on the current e1penditure! you can also
see 'hat is not being controlled (or that money. R&oreS then becomes that 'hich
is missing. "t is then possible to (orecast the cost o( (illing in the missing controls to
achieve a per(ect balance or at least a decidedly acceptable level o( coverage.
2. -hat shoul% e protecte% &irst2
The rav can be used to see security as part o( the big picture and as a macro lens
on a particular part o( a target! or any combination thereo(. A(ter analysis! the rav
'ill sho' 'hich particular part o( the scope has the greatest porosity and the
'ea,est controls. Comparing that to oneKs needs and asset 'orth! a ratio o(
protection strength to value can be generated to decide e1actly 'here to start.
=. -hat protection solutions %o /e nee% an% ho/ shoul% /e set the" up &or "a5i"u"
e&&ecti.eness2
A (ully completed rav 'ill sho' the 0 possible operational controls applied (or
each target and the limitations o( those controls. 9ou can then choose solutions
based on 'hich types o( controls you 'ant to put in place. The di((erence no' is
that you no longer need to loo, at a solution in terms o( 'hat it is rather than as the
protection or controls it can provide. This allo's you to vie' products (or the
controls you need to provide in the areas 'here controls are currently de(icient.
8. <o/ "uch i"pro.e"ent is $aine% ! speci&ic securit! procure"ents an% processes2
A ,ey (eature o( the rav is that you can ma,e a RDeltaS by mapping out the
bene(its and limitations o( a particular solution (or comparison prior to procurement.
This means you can see 'hat changes that solution 'ill ma,e to the scope to
compare 'ith other solutions. Combining that map to a rav o( the scope 'here the
solution 'ould be placed! the amount o( improvement can be gauged even prior
to purchase. 9ou can even predict the value o( that protection by dividing the
price o( the solution by the rav delta.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org :9
OSSTMM 3 The Open Source Security Testing Methodology Manual
5. <o/ %o /e "easure the perio%ic securit! e&&orts an% i"pro.e"ents2
4ith regular audits! the rav can be recalculated and compared to the older value.
Thereby the cost o( ne' solutions and processes can be *usti(ied regularly as 'ell as
the cost o( maintaining the current security level.
C. <o/ %o /e kno/ i& /e are re%ucin$ our e5posure to our threats2
4ith speci(ic ,no'ledge o( your controls! you can easily tell 'hat part or vector o(
the scope is 'ea, to speci(ic and most un,no'n threats. "n rav terminology! an
un,no'n threat is *ust one that can appear 'here interactions e1ist but controls do
not. There(ore a map can be dra'n bet'een the threats determined by the /is,
Assessors and the controls in place. /egular metric revie's 'ill sho' any change in
this map and can be done so regularly. Then it is possible to gauge the cost each
o( those threats has on security by the e1penditure on controls.
7. Can the ra. tell us ho/ /ell so"ethin$ resists attacks2
Technically! yes. The more you can balance controls 'ith interactions! the smaller
the attac, sur(ace 'ill be and the more capable the target 'ill have to control
,no'n and un,no'n types o( interactions.
>. Can the ra. help "e /ith re$ulator! co"pliance2
Anything that helps you classi(y all controls and Access points in a scope 'ill help
you 'ith compliance audits. The rav helps you do such a good *ob o( getting your
security under control that you may even (ind the ma*or (la's in compliance
regulations. 4hile there is no particular compliance right no' that as,s you to have
a particular rav score! sho'ing the %##T&& #TA/ 'ith its rav score 'ill help you
meet various compliance re+uirements (or a third-party audit and documentation.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
:: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
-.% 0ow to Ma"e a )av
The rav re+uires a security test in order to have the right things counted and the right operations analy0ed.
Any security test can be used but the more thorough and accurate the test the more the conclusive the
results 'ill be. The rav 'as originally designed (or operations tests! li,e the %##T&&! 'here the auditor
(ocuses on the behavior o( the target rather than the con(iguration. 2o'ever e1periments sho' it is
possible to apply the rav to non-operational tests as 'ell such as in static code analysis to determine the
level o( so(t'are security and comple1ity or in physical security chec,list audits to determine the level o(
protection a physical space 'ill provide. The #CA/$ -#ource Code Analysis /is, $valuation. pro*ect does
e1actly this by applying the ravs to C source code.
The minimum rav is made by the calculation o( porosity 'hich are the holes in the scope. The problem
'ith security metrics is generally in the determination o( the assessors to count 'hat they canKt possibly
really ,no'. This problem does not e1ist in the rav. 9ou get 'hat you ,no' (rom 'hat is there (or a
particular vector and you ma,e no assumptions surrounding 'hat is not there. 9ou count all that 'hich is
visible and interactive outside o( the scope and allo's (or unauthenticated interaction bet'een other
targets in the scope. That becomes the porosity. This porosity value ma,es the (irst o( 3 parts o( the (inal
rav value. The ne1t part is to account (or the controls in place per target. This means going target by
target and determining 'here any o( the 0 controls are in place such as Authentication! #ub*ugation!
Non-repudiation! etc. $ach control is valued as 0V o( a pore since each provides 50
th
o( the total
controls needed to prevent all attac, types. This is because having all 0 controls (or each pore is
(unctionally the same as closing the pore provided the controls have no limitations. The third part o( the
rav is accounting (or the limitations (ound in the protection and the controls. These are also ,no'n as
RvulnerabilitiesS. The value o( these limitations comes (rom the porosity and established controls
themselves. 4ith all counts completed! the rav is basically subtracting porosity and limitations (rom the
controls. This is most easily done 'ith the rav spreadsheet calculator.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org :;
,he si"plicit! o& "akin$ a ra. &ro" a securit! test.
OSSTMM 3 The Open Source Security Testing Methodology Manual
:n(ortunately! an uns,illed analyst can provide the 'rong in(ormation 'hich 'ill translate into a bad rav.
This is a possibility! *ust li,e itKs possible a carpenter doesnKt measure a board right or a mechanic (ails to
read the gauges right. The 'orld is (ull o( 'hat-i( scenarios. There(ore the rav is designed to be minimally
in(luenced by bad auditing or cheating by eliminating the direct scope si0e (rom the metric calculation.
2o'ever! no metric can be immune (rom (udging and the only 'ay to assure the most accurate rav is to
have multiple tests over time to ma,e the counts and to be sure the auditor 'ill ta,e responsibility over the
accuracy o( the test.
"t is possible to ta,e a short-cut in testing and still ma,e a representative rav. "( you donKt mind the error
margin because you only 'ant to ma,e a +uic, comparison! you can *ust calculate the 3orosity 'hich
means counting the visible and accessible targets. 6or e1ample! those 'ho run vulnerability scanners can
count porosity and limitations relatively easily and assign de(ault controls (or discovered services. Analysts
can also create a chec,list 'hich o((ers de(ault controls (or di((erent common solutions (ound. These are
all shortcuts to reduce the time to calculation but 'ill a((ect the overall rav 'ith an un,no'n! but perhaps
acceptable! error margin.
The end result is a calculation (or Actual #ecurity. "t applies multiple controls o( the same type to satis(y
double-en(orcement re+uirements li,e 2-(actor Authentication. "t also uses ;og0 to reduce large
numbers into human-manageable (orm. 3eople generally li,e to 'or, 'ith smaller numbers and
especially as percentages 'hich are easier to visuali0e. 6or a small scope! the accuracy o( using ;og0 as
a reduction techni+ue is negligible. 2o'ever! i( you have a very large scope 'ith many targets you may
'ant to 'or, 'ith the very large numbers (or greater accuracy. Additionally i( you 'ant to see the true
balance 'here multiple controls o( the same type are not measured! that calculation can be (ound
under the heading o( True 3rotection.
Combining Channels and (ectors
%ne important re+uirement in applying the rav is that Actual #ecurity can only be calculated per scope.
A change in channel! vector! or inde1 is a ne' scope and a ne' calculation (or Actual #ecurity.
2o'ever! once calculated! multiple scopes can be combined together in aggregate to create one
Actual #ecurity that represents a (uller vision o( the operational security all scopes. 6or e1ample! a test can
be made o( "nternet-(acing servers (rom both the "nternet side and (rom 'ithin the perimeter net'or,
'here the servers reside. That is 2 vectors. Assume that! the "nternet vector is inde1ed by "3 address and
contains N0 targets. The intranet vector is inde1ed by &AC address and is made o( 00 targets because
less controls e1ist internally to allo' (or more collaborative interaction bet'een systems. %nce each test is
completed and the rav is counted they can be combined into one calculation o( N0 targets as 'ell as
the sums o( each limitations and controls. This 'ill give a (inal Actual #ecurity metric 'hich is more
complete (or that perimeter net'or, than either test 'ould provide alone. "t 'ould also be possible to
add the analysis (rom physical security! 'ireless! telecommunications! and human security tests in the
same 'ay. #uch combinations are possible to create a better understanding o( the total security in a
holistic 'ay.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
:? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
!a# Calculator
A straight-(or'ard and simpler 'ay to ma,e ravs is to use the speci(ically created spreadsheets to
calculate the Attac, #ur(ace and various! popular re+uired metrics (rom the test data. This spreadsheet is
available at the "#$C%& 'ebsite. The Analyst need only enter the values into the empty! 'hite bo1es and
the rest o( the calculations 'ill be handled automatically.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org :@
,he ra. calculation sheet &or %eter"inin$ the alance et/een porosit!, controls, an% li"itations.
OSSTMM 3 The Open Source Security Testing Methodology Manual
-.3 Turning Test )esults into an &ttac" Surface Measurement
Operational Security
The measurement o( the Attac, #ur(ace re+uires the measurements o( Eisibility! Trust! and Access relative to the
scope. The number o( targets in the scope that can be determined to e1ist by direct interaction! indirect
interaction! or passive emanations is its visibility. As visibility is determined! its value represents the number
o( targets in the scope. Trust is any non-authenticated interaction to any o( the targets. Access is the
number o( interaction points 'ith each target.
,ategory .escription
(isibility
The number o( targets in the scope. Count all targets by inde1 only once
and maintain the inde1 consistently (or all targets. "t is generally unrealistic
to have more targets visible than there are targets in the de(ined scopeL
ho'ever! it may be possible due to vector bleeds 'here a target 'hich is
normally not visible (rom one vector is visible due to a miscon(iguration or
anomaly.
A 2:&#$C audit employs N0 peopleL ho'ever! only 37 o( them are
interactive (rom the test vector and channel. This 'ould ma,e a visibility
o( 37.
2 Access
This di((ers (rom visibility 'here one is determining the number o( e1isting
targets. 2ere! the auditor must count each Access per uni+ue interaction
point per uni+ue probe.
"n a 329##$C audit! a building 'ith 2 doors and N 'indo's 'hich all open
has an Access o( O. "( all the doors and 'indo's are sealed! then it is an
Access o( 0 as these are not points 'here one can gain entry.
6or a C%&#$C audit o( data net'or,s! the auditor counts each port
response as an Access regardless o( ho' many di((erent 'ays the auditor
can probe that port. 2o'ever! i( a service is not hosted at that port
-daemon or an application.! then all replies instead come (rom the "3
#tac,. There(ore! a server that responds 'ith a #9N5ACB and service
interactivity to only one o( the TC3 ports scanned and 'ith a /#T to the
rest does not have an Access count o( CNN3C -including port 0. since
CCN3N o( the ports respond 'ith the same response o( /#T (rom the ,ernel.
To simpli(y! count only ports 'ith service responses and only one "3 #tac,
response regardless o( the number o( ports 'hich can initiate this ,ind o(
interactivity.
4ith 2:&#$C audits! this is much more simpli(ied. A person 'ho responds
to a +uery counts as an Access 'ith all types o( +ueries -all the di((erent
+uestions you may as, or statements made count as the same type o(
response on the same channel.. There(ore! a person can only be an
Access o( per channel and vector. %nly a person 'ho completely
ignores the re+uest by not ac,no'ledging the channel is not counted.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
;> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ategory .escription
3 Trust
This di((ers (rom visibility 'here one is determining the number o( e1isting
targets. 2ere! the auditor must count each Trust per uni+ue interaction
point per uni+ue probe.
"n a 329##$C audit! a building 'ith 2 internal doors separating rooms
'hich open has a Trust o( 2. "( those doors are sealed then it is a Trust o( 0
as these are not points 'here one can pass.
6or a C%&#$C audit o( data net'or,s! the auditor counts each type o(
service (or'ard or port (or'ard as a Trust.
4ith 2:&#$C audits! a person 'ho acts as a gate'ay to interact 'ith
other people or to access property is a trust per channel. There(ore! a
person can only be a Trust o( per channel and vector. %nly a person
'ho does not comply to the Trust re+uest is not counted.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ;1
OSSTMM 3 The Open Source Security Testing Methodology Manual
Controls
The ne1t step in calculating the rav is to de(ine the ControlsL the security mechanisms put in place to
provide assurance and protection during interactions.
,ategory .escription
Authentication
Count each instance o( authentication re+uired to gain access. This
re+uires that authori0ation and identi(ication ma,e up the process (or the
proper use o( the authentication mechanism.
"n a 329##$C audit! i( both a special "D card and a thumb print scan is
re+uired to gain access! then add t'o (or authentication. 2o'ever! i(
Access *ust re+uires one or the other! then only count one.
2 "ndemnification
Count each instance o( methods used to e1act liability and insure
compensation (or all assets 'ithin the scope.
A basic 329##$C e1ample is a 'arning sign threatening to prosecute
trespassers. Another common e1ample is property insurance. "n a scope
o( 200 computers! a blan,et insurance policy against the(t applies to all
200 and there(ore is a count o( 200. 2o'ever! do not con(use the method
'ith the (la' in the method. A threat to prosecute 'ithout the ability or
'ill to prosecute is still an indemni(ication method-- ho'ever! it is 'ith a
limitation.
3 Sub+ugation
Count each instance (or Access or Trust in the scope 'hich strictly does
not allo' (or controls to (ollo' user discretion or originate outside o( itsel(.
This di((ers (rom being a security limitation in the target since it applies to
the design or implementation o( controls.
"n a C%&#$C data net'or,s audit! i( a log-in can be made in 2TT3 as 'ell
as 2TT3# but re+uires the user to ma,e that distinction! then it (ails to count
to'ard #ub*ugation. 2o'ever! i( the implementation re+uires the secured
mode by de(ault! such as a 3B" internal messaging system! then it does
meet the re+uirement o( the #ub*ugation control (or that scope.
&ore simply! in 2:&#$C! a non-repudiation process 'here the person
must sign a register and provide an identi(ication number to receive a
document is under #ub*ugation controls 'hen the provider o( the
document records the identi(ication number! rather than having the
receiver do so! to eliminate the recording o( a (alse number 'ith a (alse
name.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
;% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ategory .escription
8 Continuity
Count each instance (or Access or Trust in the scope 'hich assures that
no interruption in interaction over the channel and vector can be
caused! even under situations o( total (ailure. Continuity is the umbrella
term (or characteristics such as survivability! load balancing! and
redundancy.
"n a 329##$C audit! i( it is discovered that an entry 'ay into a store
becomes bloc,ed such that no alternate entry 'ay is possible and
customers cannot enter! that Access does not have Continuity.
"n a C%&#$C data net'or,s audit! i( a 'eb server service (ails (rom high-
load and an alternate 'eb server provides redundancy so no interactions
are lost! this Access has Continuity.
N !esilience
Count each instance (or Access or Trust in the scope that does not (ail
open or provide ne' accesses upon security (ailure. "n common
language! to R(ail securelyS.
"n a 329##$C audit 'here 2 guards control Access to a door! i( one is
removed and the door cannot be opened by the remaining guard! then
it has resilience.
"n a C%&#$C data net'or,s audit! i( a 'eb service re+uiring a log-in or
pass'ord loses communication 'ith its authentication database! then all
Access should be denied rather than permitted in order to have
resilience.
C Non:repudiation
Count each instance (or the Access or Trust that provides a non-
repudiation mechanism (or each interaction to provide assurance that
the particular interaction did occur at a particular time bet'een the
identi(ied parties. Non-repudiation depends upon identi(ication and
authori0ation to be properly established (or it to be properly applied
'ithout limitations.
"n a 329##$C audit! the Non-repudiation control e1ists i( the entrance to a
building re+uires a camera 'ith a biometric (ace scan to gain entry and
each time it is used! the time o( entry is recorded 'ith the "D. 2o'ever! i( a
,ey-card is used instead! the Non-repudiation control re+uires a
synchroni0ed! time-coded camera to assure the record o( the card-userKs
identity to avoid being a (la'ed implementation. "( the door is tried
'ithout the ,ey card! not having the synchroni0ed camera monitoring the
door 'ould mean that not all interactions 'ith the entry'ay have the
Non-repudiation control and there(ore does not count (or this control.
"n a C%&#$C data net'or,s audit! there may be multiple log (iles (or non-
repudiation. A port scan interacting at the "3 #tac, is recorded in one log
'hile interaction 'ith the 'eb service is recorded to another log (ile.
2o'ever! as the 'eb service may not log the interactions (rom the 3%#T
method! the control is still countedL ho'ever! so is the security limitation.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ;3
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ategory .escription
O Confidentiality
Count each instance (or Access or Trust in the scope that provides the
means to maintain the content o( undisclosed interactions bet'een the
interacting parties.
A typical tool (or Con(identiality is encryption. Additionally! ob(uscation o(
the content o( an interaction is also a type o( con(identiality! albeit a
(la'ed one.
"n 2:&#$C! ho'ever! a method o( Con(identiality may include 'hispering
or using hand signals.
7 Pri#acy
Count each instance (or Access or Trust in the scope that provides the
means to maintain the method o( undisclosed interactions bet'een the
interacting parties. 4hile Rbeing privateS is a common e1pression! the
phrase is a bad e1ample o( privacy as a loss control because it includes
elements o( con(identiality. As a loss control! 'hen something is done Rin
privateS it means that only Rthe doingS is private but the content o( the
interaction may not be.
A typical tool (or 3rivacy is obscuring the interaction! that is! having the
interaction ta,e place outside o( the visibility o( third parties. Con(usion o(
the means o( interaction as ob(uscation is another method o( applying
the 3rivacy control.
"n 2:&#$C! a method o( 3rivacy may be simply ta,ing the interaction into
a closed room a'ay (rom other people. "n movies! 'e see techni+ues to
create the 3rivacy control by setting t'o identical suitcases side by side!
some type o( incident to create con(usion ta,es place! and the t'o
people s'itch the suitcases in seemingly plain vie'.
P "ntegrity
Count each instance (or Access or Trust in the scope 'hich can assure
that the interaction process and Access to assets has (inality and cannot
be corrupted! stopped! continued! redirected! or reversed 'ithout it
being ,no'n to the parties involved. "ntegrity is a change control process.
"n C%&#$C data net'or,s! encryption or a (ile hash can provide the
"ntegrity control over the change o( the (ile in transit.
"n 2:&#$C! segregation o( duties and other corruption-reduction
mechanisms provide "ntegrity control. Assuring integrity in personnel
re+uires that t'o or more people are re+uired (or a single process to
assure oversight o( that process. This includes that no master Access to
the 'hole process e1ists. There can be no person 'ith (ull access and no
master ,ey to all doors.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
;- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ategory .escription
0 Alarm
Count each instance (or Access or Trust 'hich has a record or ma,es a
noti(ication 'hen unauthori0ed and unintended porosity increases (or the
vector or restrictions and controls are compromised or corrupted.
"n C%&#$C data net'or,s! count each server and service 'hich a
net'or,-based intrusion detection system monitors. %r! count each
service that maintains a monitored log o( interaction. access logs count!
even i( they are not used to send a noti(ication alert immediately! unless
they are never monitored. 2o'ever! logs 'hich are not designed to be
used (or such noti(ications! such as a counter o( pac,ets sent and
received! do not classi(y as an alarm as there is too little data stored.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ;9
OSSTMM 3 The Open Source Security Testing Methodology Manual
Limitations
6inally! the limitations are veri(ied 'here possible. The values o( each ;imitation are dependent on 3orosity
and Controls. This is di((erent (rom the more common ris, perspective 'here a vulnerability may be
assigned a ris, level based on 'hat damage it can do! ho' easy it is to do! and the distance in range (or
the attac,. There(ore the ;imitation values are calculated based on the 3orosity and Controls o( the
target they can be (ound on.
,ategory .escription
(ulnerability
Count separately each (la' or error that de(ies protections 'hereby a
person or process can access! deny access to others! or hide itsel( or
assets 'ithin the scope.
"n 329##$C! a vulnerability can be as simple as a glass door! a metal gate
corroded by the 'eather! a door that can be sealed by 'edging coins
into the gap bet'een it and its (rame! electronic e+uipment not sealed
(rom pests such as ants or mice! a bootable CD drive on a 3C! or a
process that allo's an employee to ta,e a trashcan large enough to hide
or transport assets out o( the scope.
"n 2:&#$C! a vulnerability can be a cultural bias that does not allo' an
employee to +uestion others 'ho loo, out o( place or a lac, o( training
'hich leaves a ne' secretary to give out business in(ormation classi(ied
(or internal use only.
"n C%&#$C data security! a vulnerability can be a (la' in so(t'are that
allo's an attac,er to over'rite memory space to gain access! a
computation (la' that allo's an attac,er to loc, the C3: into 00V
usage! or an operating system that allo's enough data to be copied
onto the dis, until it cannot operate anymore.
"n C%&#$C telecommunications! a vulnerability can be a (la' in the pay
phone system that allo's sounds through the receiver to mimic coin
drops! a telephone bo1 that allo's anyone to access anyone elseKs
phone line! a voice mail system that provides messages (rom any phone
any'here! or a 6AW machine that can be polled remotely to resend the
last thing in memory to the callerKs number.
"n #3$C#$C! a vulnerability can be hard'are 'hich can be overloaded
and burnt out by higher po'ered versions o( the same (re+uency or a
near (re+uency! a standard receiver 'ithout special con(igurations 'hich
can access the data in the signal! a receiver 'hich can be (orced to
accept a third-party signal in place o( the intended one! or a 'ireless
access point dropping connections near a micro'ave oven.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
;: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ategory .escription
2 Wea$ness
Count each (la' or error in the controls (or interactivity) authentication!
indemni(ication! resilience! sub*ugation! and continuity.
"n 329##$C! a 'ea,ness can be a door loc, that opens 'hen a card is
'edged bet'een it and the door (rame! a bac,-up generator 'ith no
(uel! or insurance that doesnKt cover (lood damage in a (lood 0one.
"n 2:&#$C! a 'ea,ness can be a process (ailure o( a second guard to
ta,e the post o( the guard 'ho runs a(ter an intruder or a cultural climate
'ithin a company (or allo'ing (riends into posted restricted spaces.
"n C%&#$C data security! a 'ea,ness can be a log-in that allo's
unlimited attempts or a 'eb (arm 'ith round-robin DN# (or load
balancing yet each system also has a uni+ue name (or direct lin,ing.
"n C%&#$C telecommunications! a 'ea,ness can be a 3<W that still has
the de(ault administration pass'ords or a modem ban, (or remote
access dial-in 'hich does not log the caller numbers! time! and duration.
"n #3$C#$C! a 'ea,ness can be a 'ireless access point authenticating
users based on &AC addresses -'hich can be spoo(ed. or an /6"D
security tag that no longer receives signals and there(ore (ails RopenS
a(ter receiving a signal (rom a high po'er source.
3 Concern
Count each (la' or error in process controls) non-repudiation!
con(identiality! privacy! integrity! and alarm.
"n 329##$C! a concern can be a door loc, mechanism 'hose operation
controls and ,ey types are public! a bac,-up generator 'ith no po'er
meter or (uel gauge! an e+uipment process that does not re+uire the
employee to sign-out materials 'hen received! or a (ire alarm not loud
enough to be heard by machine 'or,ers 'ith ear plugs.
"n 2:&#$C! a concern can be a process (ailure o( a guard 'ho maintains
the same schedule and routine or a cultural climate 'ithin a company
that allo's employees to use public meeting rooms (or internal business.
"n C%&#$C data security! a concern can be the use o( locally generated
'eb server certi(icates (or 2TT3# or log (iles 'hich record only the
transaction participants and not the correct date and time o( the
transaction.
"n C%&#$C telecommunications! a concern can be the use o( a 6AW
machine (or sending private in(ormation or a voice mail system that uses
touch tones (or entering a 3"N or pass'ord.
"n #3$C#$C! a concern can be a 'ireless access point using 'ea, data
encryption or an in(rared door opener that cannot read the sender in the
rain.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ;;
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ategory .escription
8 E,posure
Count each un*usti(iable action! (la'! or error that provides direct or
indirect visibility o( targets or assets 'ithin the chosen scope channel.
"n 329##$C! an e1posure can be a 'indo' 'hich allo's one to vie'
assets and processes or a po'er meter that sho's ho' much energy a
building uses and its (luctuation over time.
"n 2:&#$C! an e1posure can be a guard 'ho allo's all visitors to vie' the
list o( names on the sign-in sheet or a company operator 'ho in(orms
callers that a particular person is out sic, or on vacation.
"n C%&#$C data security! an e1posure can be a descriptive and valid
banner about a service -disin(ormation banners are not e1posures. or an
"C&3 echo reply (rom a host.
"n C%&#$C telecommunications! an e1posure can be an automated
company directory sorted alphabetically! allo'ing anyone to cycle
through all persons and numbers! or a 6AW machine that stores the last
dialed numbers.
"n #3$C#$C! an e1posure can be a signal that disrupts other machinery or
an in(rared device 'hose operation is visible by standard video cameras
'ith night capability.
N Anomaly
Count each unidenti(iable or un,no'n element 'hich cannot be
accounted (or in normal operations! generally 'hen the source or
destination o( the element cannot be understood. An anomaly may be
an early sign o( a security problem. #ince un,no'ns are elements 'hich
cannot be controlled! a proper audit re+uires noting any and all
anomalies.
"n 329##$C! an anomaly can be dead birds discovered on the roo( a
building around communications e+uipment.
"n 2:&#$C! an anomaly can be +uestions a guard as,s 'hich may seem
irrelevant to either the *ob or standard small tal,.
"n C%&#$C data security! an anomaly can be correct responses to a
probe (rom a di((erent "3 address than 'as probed or e1pected.
"n C%&#$C telecommunications! an anomaly can be a modem response
(rom a number that has no modem.
"n #3$C#$C! an anomaly can be a local signal that cannot be properly
located nor does it do any ,no'n harm.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
;? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
-.- The Operational Security 3ormula
The rav is derived (rom three categories de(ined 'ithin the scope) %perational #ecurity! Controls and
;imitations. "n order to begin! 'e must (irst aggregate and associate all o( our input in(ormation into the
appropriate categories (or each input variable.
The rav e+uation re+uires that each o( the categories be assigned a logarithmic base value to scale the
three (actors o( Actual #ecurity in accordance 'ith the scope.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ;@
,he in&or"ation containe% /ithin the ra. is co"prise% o& ho/ operations alances /ith controls an% li"itations. ,here are no
?/ei$hts? to ske/ the results lea.in$ a &le5ile 4uanti&ication o& the attack sur&ace that allo/s it to e co"pare% to the securit! o&
an!thin$ else no "atter si#e, .ector, or Channel.
OSSTMM 3 The Open Source Security Testing Methodology Manual
Porosity
%perational #ecurity! also ,no'n as the scopeKs 3orosity! is the (irst o( the three (actors o( Actual #ecurity
that should be determined. "t is initially measured as the sum o( the scopeKs visibility -
V
P
.! access -
A
P .!and
trust -
T
P ..
T A V sum
P P P OpSec + + =
4hen calculating the rav it is ho'ever necessary to determine the %perational #ecurity base value!
base
OpSec
. The %perational #ecurity base value is given by the e+uation

base
OpSec
( )
sum
OpSec + = 100 1 log
2
.
#ince the logarithm o( 0 is not de(ined in the calculation 'e needed to include the Y00 here. The log o(
is 0. #o i( 'e have 0 3orosity and 'ant to e1press this lac, o( interaction as per(ect security o( 00 rav
then 'e needed to add Y to the e+uation. 4ithout the Y00 'e 'ould have unde(ined numbers in the
case that the sums o( any o( those (actors are 0. This is re+uired by the methodology because the
absence o( interactions represents per(ect security and there(ore the logarithm should e+ual 0 to provide
the 00 rav.
-.9 The ,ontrols 3ormula
The ne1t step in calculating the rav is to de(ine the ;oss ControlsL the security mechanisms put in place to
protect the operations. 6irst the sum o( the ;oss Controls!
sum
LC
! must be determined by adding together
the 0 ;oss Control categories.
Controls ,lass &
Authentication
Au
LC
"ndemni(ication
Id
LC
/esilience
Re
LC
#ub*ugation
Su
LC
Continuity
Ct
LC
,lass B
Non-/epudiation
NR
LC
Con(identiality
Cf
LC
3rivacy
Pr
LC
"ntegrity
It
LC
Alarm
Al
LC
Thus the ;oss Control sum
sum
LC
is given as
Al It Cf NR Ct Su Id Au sum
LC LC LC LC LC LC LC LC LC LC LC + + + + + + + + + =
Pr Re
.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
?> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Missing Controls
@iven that the combination o( each o( the 0 ;oss Controls balance the value o( %p#ec loss -visibility!
access! trust. it is necessary to determine the amount o( &issing Controls!
sum
MC
! in order to assess the
value o( the #ecurity ;imitations. This must be done individually (or each o( the 0 ;oss Control categories.
6or e1ample! to determine the &issing Controls (or Authentication -
Au
MC
. 'e must subtract the sum o(
Authentication Controls -
Au
LC
. o( the scope (rom the
sum
OpSec
. The &issing Controls can never be less
than 0ero ho'ever.
The e+uation (or determining the &issing Controls (or Authentication -
Au
MC
. is given by
"6
sum
OpSec
-
0 s
Au
LC

T2$N
0 =
Au
MC
$;#$
=
Au
MC
Au sum
LC OpSec
.
The resulting &issing Control totals (or each o( the 0 ;oss Controls must then be added to arrive at the
total &issing Control value -
sum
MC
. as seen belo'.
=
sum
MC
Al Cf It NR Ct Su Id Au
MC MC MC MC MC MC MC MC MC MC + + + + + + + + +
Pr Re
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ?1
OSSTMM 3 The Open Source Security Testing Methodology Manual
True Controls
True Controls -
sum
TC
. is the inverse o( &issing Controls 'hich means the True Controls (or each individual
control also need to be calculated be(ore the results can be tallied into
sum
TC
.
The e+uation (or determining the True Controls (or Authentication -
Au
TC
. is given by

Au sum Au
MC OpSec TC =
The resulting True Control totals (or each o( the 0 ;oss Controls must then be added to arrive at the total
True Control value -
sum
TC
. as seen belo'.
=
sum
TC
Al Cf It NR Ct Su Id Au
TC TC TC TC TC TC TC TC TC TC + + + + + + + + +
Pr Re
True Controls are used to measure the ideal placement o( controls. The base value also helps to eliminate
the in(luence o( a disproportionate placement o( controls on security. The True Controls base -
base
TC
.
value is given as)
=
base
TC ( ) ) 1 . 0 ( 100 1 log
2
+
sum sum
MC OpSec
.
<ased on the same idea as True Controls! True Coverage -TCvg. can be used to measure the percentage
o( controls in place regarding the optimal amount and placement o( controls. True Coverage is then
derived using the &issing Control totals and the (ollo'ing e+uation)
"6
s
sum
OpSec
0
T2$N
0 = TCvg
$;#$
sum
sum
OpSec
MC
TCvg

=
10
1
.
1ull Controls
6ull Controls! on the other hand! ta,e into account all controls in place regardless o( a balanced
distribution. This value is important (or measuring the 'orth o( t'o-(actor authentication! (or e1ample! and
other instances o( de(ense in depth (or the same visibility! access or trust. The 6ull Controls base -
base
FC
.
value is given as)
( )
sum base
LC FC + = 10 1 log
2

Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
?% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
-.: The 2imitations 3ormula
Ne1t! the ;imitations are individually 'eighted. The 'eighting o( the Eulnerabilities! 4ea,nesses and
Concerns are based on a relationship bet'een the 3orosity or
sum
OpSec
! the ;oss Controls and in the case
o( $1posures and Anomaly the e1istence o( other ;imitations also plays a role. An $1posure or Anomaly
poses no problems alone unless a Eulnerability! 4ea,ness or Concern is also present. Thin, o( an $1posure
li,e a pointer. "( there is a pointer that goes no'here! or in this case doesnKt lead to anything e1ploitable
-Eulnerability! 4ea,ness! Concern. and all Controls are accounted (or! then at the time o( the test the
$1posure has no e((ect on security and thus has no value in the rav.
The (ollo'ing value table is used to calculate the
sum
SecLim
variable! as an intermediate step bet'een
the #ecurity ;imitation inputs and the
base
SecLim
variable! 'hich is the #ecurity ;imitations basic input (or
the rav e+uation.
"6
0 s
sum
OpSec
T2$N
0 = MCvg
$;#$
sum
sum
OpSec
MC
MCvg
1 . 0
=

"nput 4eighted Ealue Eariables
$ulnerability
V
L
( )
sum
sum sum
OpSec
MC OpSec +
sum
MC ) sum o( &issing Controls
6ea"ness
W
L
( )
sum
A sum
OpSec
MC OpSec +
A
MC ) sum o( &issing Controls in Control Class A
,oncern
C
L
( )
sum
B sum
OpSec
MC OpSec +
B
MC ) sum o( &issing Controls in Control Class <
+Fposure
E
L
( ) ( )
sum
C W V A V
OpSec
L L L MCvg P P + + + +
V
P
) sum o( Eisibility
A
P ) sum o( Accesses
MCvg ) 3ercent &issing Coverage
&nomaly
A
L
( )
sum
C W V T
OpSec
L L L MCvg P + + +
T
P ) sum o( Eisibility
MCvg ) 3ercent &issing Coverage
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ?3
OSSTMM 3 The Open Source Security Testing Methodology Manual
Security Limitations *ase
sum
SecLim
is then calculated as the aggregated total o( each input multiplied by its corresponding
'eighted value as de(ined in the table above.
=
sum
SecLim
( ) ( ) ( )
+
|
|
.
|

\
| +
+
|
|
.
|

\
| +
+
|
|
.
|

\
| +

sum
B sum
C
sum
A sum
W
sum
sum sum
V
OpSec
MC OpSec
L
OpSec
MC OpSec
L
OpSec
MC OpSec
L
( ) ( ) ( )
|
|
.
|

\
| + + +
+
|
|
.
|

\
| + + + +

sum
C W V T
A
sum
C W V A V
E
OpSec
L L L MCvg P
L
OpSec
L L L MCvg P P
L
The #ecurity ;imitations base e+uation is given as)
base
SecLim ( )
sum
SecLim + = 100 1 log
2
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
?- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
-.; The &ctual Security 3ormula
This is the (inal part (or using all previous calculations in three di((erent 'ays.
Actual Security 0elta
The Actual #ecurity Delta is use(ul (or comparing products and solutions by previously estimating the
change -delta. the product or solution 'ould ma,e in the scope. 4e can (ind the Actual #ecurity Delta!
A ActSec ! 'ith the (ormula)
base base base
SecLim OpSec FC ActSec = A
.
True Protection
Can be used as a simpli(ied e1pression (or the optimal coverage o( a given scope 'here 00 signi(ies an
optimal relationship bet'een the 3orosity! True Controls and #ecurity ;imitations. True 3rotection is given
as)
base base base
SecLim OpSec TC + =100 TruPro
Actual Security
To measure the current state o( operations 'ith applied controls and discovered limitations! a (inal
calculation is re+uired to de(ine Actual #ecurity. As implied by its name this is the 'hole security value
'hich combines the three values o( operational security! controls! and limitations to sho' the actual state
o( security.
Actual #ecurity -total.! ActSec! is the true state o( security provided as a hash o( all three sections. A rav o(
00 signi(ies a per(ect balance o( security ho'ever the Actual #ecurity is not a true percentage value.
#cores above 00 are also possible 'hich signi(ies that the tested scope has more controls implemented
than necessary 'hich could also be proo( o( overspending. The (inal rav e+uation (or Actual #ecurity is
given as)
( )
base base base base base base
SecLim FC SecLim OpSec FC OpSec ActSec ActSec + A + =
100
1
100
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ?9
OSSTMM 3 The Open Source Security Testing Methodology Manual
Trusting everyone is insecure but not
trusting anyone is inefficient.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
?: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 9 < Trust &nalysis
6'& !ou coul% take a pill that /oul% "ake !ou "ore trustin$, /oul% !ou27 is ho/ an
in&or"al '()C*M stu%! e$an to help people etter un%erstan% ho/ the! "isuse
trust as a concept. ,he $eneral pulic ans/ers no to this 4uestion. *ne securit!
pro&essional ans/ere%, 60es ut onl! i& e.er!one else has to take it too.7
Trust can be both a problem and a solution. "t is a problem 'here it puts security in a compromising
position. ;i,e the concept o( potential energy in physics! trust creates a concentration o( authori0ation
'hich can e1plode into a big problem should the trust (ail or the trusted target be deceived into harming
the trust-giver. 2o'ever it can also reduce the need (or continuous! possibly redundant re-authentication!
increasing the e((iciency o( operations. 6or that reason! trust is o(ten seen as an Rauthenticate once and
'al, a'ayS protocol. This is most o(ten seen in 2uman #ecurity 'here 2uman /esources departments
research a candidate be(ore the hire and a(ter'ard that person has continuous access to resources until
they are no longer an employee. /e-authentication is then done seldom or sporadically and rarely at the
same depth as 'hen hired.
"n operational security! Trust is merely a contributor to porosity! *ust another interaction to control. "t di((ers
(rom Access -the other (orm o( interaction.! in ho' it relates to other targets 'ithin the scope. #o 'here
Access is interaction bet'een t'o sides o( a vector into and out o( the scope! Trust is measured as the
interactions bet'een targets 'ithin the scope. 2o'ever! most people donKt use trust so concretely. Trust is
usually applied to a speci(ic person or item and a speci(ic act such as! RCan " trust this employee to
deliver be(ore the deadlineUS or RCan " trust this computerUS. There are correct ans'ers (or these
+uestions but people o(ten lac, the s,ills needed to +uanti(y the level o( Trust (or that person or ob*ect
'hich 'ould let us ma,e a more rational and logical decision. 2o'ever! to +uanti(y trust! 'e need to (irst
understand it.
9.1 #nderstanding Trust
Trust is a decision. 4hile some people claim it is an emotion! li,e love! or a (eeling! li,e pain! its clearly a
comple1 +uality 'e humans are born 'ith. :nli,e an emotion or a (eeling! 'e can choose to trust or not
to trust someone or something even i( it (eels 'rong to do so. "t appears that 'e are capable to
rationali0e in a 'ay to supersede ho' 'e (eel about trusting a target. This means 'e can +uanti(y it by
applying a logical process. "t also means 'e can assign trust values to ob*ects and processes as 'ell as
people based on these values. This brings ne' po'er to those 'ho can analy0e trust and ma,e decisions
based on that analysis. "t also means Analysts 'ith this s,ill can better control bias! identi(y (allacies
-especially those (rom authoritative or trusted sources.! and handle un,no'ns (or transparent reporting.
%ne point to note! ho'ever once the trust is +uanti(ied! it is only a vehicle (or rationali0ing the trust. "t 'ill
not ma,e something (eel trust'orthy no' or in the (uture. #ome people have strong (eelings o( aversion or
attraction 'hich may be at odds 'ith the (acts.
As part o( %p#ec! trust is one part o( a targetKs porosity. 4here security is li,e a 'all that separates threats
(rom assets! trust is a hole in that 'all. "t is 'herever the target accepts interaction (rom other targets
'ithin the scope. 2o'ever! people tend to use improper or incomplete operational controls 'ith their
trusts li,e authentication that has been made 'ith improper identi(ication such as a voice over a
telephone! a business card! or even *ust the assumption that because a person is in the room that they
are authori0ed to be there. This opens people up to (raud and deceit. The use o( additional controls are
re+uired to secure a trust! to assure its integrity and resilience.
:n(ortunately! 'hile using more controls 'or,s 'ith ob*ects and processes! it may not 'or, bet'een
people. &any times social norms consider controls beyond simple authentication li,e matching a (ace or
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ?;
OSSTMM 3 The Open Source Security Testing Methodology Manual
voice 'ith an identity to be o((ensive to the person to be trusted. #ociety o(ten re+uires us to be more
trusting as individuals in order to bene(it society as a 'hole and sometimes at the e1pense o( everyoneKs
individual protection.
As stated earlier! operational trust is measured as a negative thing 'hich comes (rom an interaction
bet'een t'o entities in a scope. 4hen a trust has no controls! itKs 'hat people call Rblind trustS 'hich
may be good (or relationships and can speed interactions but is bad (or operational security. 3eople
generally apply controls to trusts even i( they donKt thin, o( it as such at the time. #ome controls are
inherently given more 'eight than others depending on the situation and need. 4hen selecting a person
'ho they need to depend on! they may put a larger value on integrity and resilience. 4hen ma,ing a
(inancial transaction! they may put a larger value on authentication! continuity! and con(identiality. They
may put a larger value on alarm and sub*ugation (or advice on a product unless itKs a medical
prescription then they 'ould pre(er privacy and non-repudiation. /ealistically though! they are not
actually giving more value to particular controls. "nstead they are actually evaluating on the ten trust
properties and loo,ing (or those speci(ic controls (or com(ort to their trust decisions. :sing the trust
properties allo's them to ma,e a decision to trust or not even 'hen the in(ormation they have about the
target is incomplete. #ince unin(ormed and unpracticed trust decision ma,ing is a dangerous gamble the
very least a (ormal process li,e applying the trust properties can provide is to in(orm the decision ma,er o(
e1actly ho' much they donKt ,no' and allo' them to see, more in(ormation be(ore continuing. This
means that the real need (or being able to +uanti(y operational trust occurs 'hen 'e must rely on many
un,no'ns to determine and rationali0e trust.
The trust properties are the +uanti(iable! ob*ective elements 'hich are used to create trust. 4e can say
these properties are 'hat 'e 'ould say give us Rreason to trustS. These properties are to be made into
baseline rules based on the target and situation 'hich 'e are veri(ying. :n(ortunately! many illogical trust
properties e1ist and are all too commonly in use 'hich ma,es it more di((icult (or us to ma,e proper trust
decisions 'ithout it &eelin$ 'rong. 2o'ever! itKs e1actly the (eeling part 'hich ma,es us more error prone.
During research! many potential trust properties 'ere discovered 'hich are commonly in use and even
o((icial! government and industry regulations recommend! ho'ever they (ailed logic tests and 'ere
discarded (rom our set o( properties leaving only ten.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
?? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
9.% 3allacies in Trust
:n(ortunately! most people are bad at understanding and using trust. &any illogical methods (or trust e1ist
and are popularly used. T'o e1amples o( the most common! (allacious! trust properties are co"posailit!
and transiti.it!. These properties are popularly used by people to ma,e trust decisions about the
un,no'n. "n composability! a person ma,es a trust choice based on 'hat a large number o( people
have to say about the thing or person in +uestion even i( those people arenKt individually trusted.
<asically! a person accepts the groupKs trusts as their o'n. This is similar to the pressure created by social
or political groups and mass media. The reason 'hy this is illogical is because the individual e1periences
o( others! especially strangers! are all relative and cannot veri(y the consistent trust'orthiness o( (uture
events.
The other common (allacious use o( trust is transitivity. "t is 'hen a person accepts the trust decision o( a
trusted person (or themselves. "t is also ,no'n as the chain o( trust) you trust Alice and Alice trusts >ac,
there(ore you can trust >ac,. 2o'ever! transitive trust is illogical as 'ell because you may trust Alice (or
some things but perhaps not the same things (or 'hich she trusts >ac,. There is also the possibility that
Alice has approached the trust (or some emotional bene(it not available to you.
3eople 'ho o(ten trust Rtheir gutS to ma,e trust decisions are lauded 'hen they are right as i( they have
some secret! po'er(ul sense above other humans. 2o'ever! other than *ust luc,! some people are better
at paying attention to details! seeing emotional micro-e1pressions in (aces! and applying logic +uic,ly to
common situations 'hich they themselves might not be able to e1press verbally as to ho' but rather they
do &eel 'hatKs 'rong. These people learned to do this naturally and built upon it 'ith e1perience (illed
'ith trial and error not really obvious to themselves any more than anyone notices the millions o( small
decisions they ma,e each day and their conse+uences. The trust properties allo' ordinary people 'ho
do not have this natural ability to analy0e any o( their trust decisions 'ith s,ill! distancing themselves (rom
their o'n under-developed Rgut instinctS until they can recondition themselves to do so automatically!
(luently! sharpening their instincts until they 'or, R(rom the gutS.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org ?@
Co""on e5a"ples o& &allacious trust use, &irst /ith Co"posailit! an% secon%l!, /ith ,ransiti.it!.
OSSTMM 3 The Open Source Security Testing Methodology Manual
9.3 The Ten Trust 'roperties
The ten trust properties to ma,e proper trust analysis are)
Trust 'roperty .escription
Sie
The number to be trusted. &ust the trust e1tend to *ust one or to
manyU "s the group to be a trusted one 'hich is meant to ma,e
collective decisionU
2 Symmetry
The vector -direction. o( the trust. Trust may be one 'ay
-asymmetrical. and de(ined as to 'hich 'ay the trust must travel or
both 'ays -symmetrical.. A person 'ho must also trust you has to
consider the reciprocation (rom brea,ing the trust.
3 (isibility
The level o( transparency o( all operational parts and processes o( the
target and its environment.
8 Sub+ugation
Also called control! the amount o( in(luence over the scope by the
operator.
N Consistency
The historical evidence o( compromise or corruption o( the target.
C "ntegrity
The amount and timely notice o( change 'ithin the target.
O Offsets
The o&&sets o& su&&icient assurance are compensation (or the trust giver
or punishment (or the trust brea,er. "t is a value placed on the trust
'ith the target.
7 (alue
The (inancial o((set (or ris,! the amount o( 'in or gain (or 'hich the ris,
o( putting trust in the target is su((icient to o((set the ris, o( (ailure in the
trust.
P Components
The number o( other elements 'hich currently provide resources (or
the target either through direct or indirect interactions! similar to
"ntervention o( the 6our 3oint 3rocess.
0 Porosity
The amount o( separation bet'een the target and the e1ternal
environment.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
@> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
9.- The Trust )ules
:sing the trust properties allo's us to create only +uanti(iable rules! not Rso(tS rules that can neither
substantiate the trust level nor disrupt it 'ith a biased! emotional 'eight. 2o'ever! the properties on their
o'n are useless i( they cannot become +uanti(iable properties! ob*ective! or understandable by the
common person not necessarily involved in the security (ield. There(ore 'e still need to turn the trust
properties into trust rules! calculations o( directly relevant operations made (rom all the trust properties. 4e
do this in the (orm o( +uestions 'here the ans'ers are unbiased numbers 'hich 'ill be used to create a
percentage (or easier comprehension and 'hich matches our common use o( +uali(iers o( trust in normal
speech li,e al"ost! so"eti"es! al/a!s! and ne.er.
4hen creating the trust rules (rom the trust properties it is important to note that trust decisions are not
linear. There is no building to'ards trust in a particular order or even an e((ort value system 'here it can
be determined that one level re+uires more e((ort than another. "n methodology terms! it appears
irrational 'hen calculated. A decision to trust there(ore may be concluded by an ans'er (rom *ust one o(
the (ollo'ing tests 'hich ma,es up the trust rules. 2o'ever! doing so is our conscious choice to ma,e a
trust 'here the calculation speci(ically says not to. This may ma,e most sense in a li(e or death situation
'here the result o( trust'orthiness is very lo' but the Ealue o( /e'ard -oneKs li(e. is so incredibly great that
no other choice can be made.
The trust rules must be created speci(ically (or the target. 4hile this may seem cumbersome! it is possible
to ma,e generically topic-speci(ic trust rules 'hich 'ill suit the purpose. The bene(it o( this is that the trust
properties can then be made into rules (itting any purpose and any situation 'here one must ma,e a trust
decision on another person! thing! process! system! or action. 4ith practice! these trust rules can be made
automatically and very +uic,ly as part o( oneKs decision process! (ocusing only on the rules 'hich can be
ans'ered and discovering the ones 'here there can be no ,no'n ans'er 'ith the in(ormation available.
The application o( the trust rules into speci(ic veri(ication tests that provide a +uantity is good ho'ever
ideally you need to determine a (inite +uantity. An in(inite +uantity may be too relative to the tester and
does not provide the constraints necessary (or e1pressing the result in a percentage. 6or e1ample! to
apply the third property! transparency! the components should be counted as inde1ed so that there is a
(inite amount. #o the parts o( a computer can have an end number be(ore the computer is completely
built and a process can have a precise! (inite number o( steps be(ore it is completed. 6or people!
ho'ever! this may not be so easy to do but it is possible i( applied properly to the situation. "n the case o(
a security clearance! you may count all relationships 'ithin a given time range and o( those! the number
'hich are 'ith people 'ho have criminal records. This allo's (or a (inite number even i( rather large. Then!
you may 'ant to complete other tests speci(ic to the third rule as that one may only give one type o(
in(luence. %thers may be (inancial necessities! 'or, e1periences! memberships! convictions! and anything
that 'ill give a good representation as to ho' transparent that person is. The (inal calculation ho'ever
has to be the sum total o( all tests 'hich 'ill provide a single transparency percentage (or that rule.
The resulting percentage (or each trust rule can be vie'ed individually to sho' 'here controls must be
applied to improve or maintain necessary levels o( trust'orthiness. This may also sho' 'here
improvements must be made be(ore a trust can be considered. 6or e1ample! a trust analysis (or a costly
and di((icult military campaign may sho' that rule (our! sub*ugation! is at 0V because some o( the
necessary participants are civilians and not under military control. This gives the theater operators o( the
campaign speci(ic! actionable in(ormation to ma,e the necessary ad*ustments to get that percentage
up to a level thatKs acceptable or else apply more controls to better assure compliance (rom those
civilian members.
Another result (rom analy0ing the percentages o( individual trust rules is that un,no'ns become glaringly
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org @1
OSSTMM 3 The Open Source Security Testing Methodology Manual
obvious because the less that is ,no'n! the lo'er the percentage 'ill be. This means un,no'ns 'ill be at
or very close to 0V.
The end metric ho'ever is one 'hich is the mean o( all percentages. This provides a big picture
understanding you could rationally have o( the target o( the trust. This is especially use(ul 'hen it is di((icult
to ma,e a trust decision because o( personal bias. :se o( trust rules in (ormal security analysis as 'ell as
regular decision ma,ing can greatly minimi0e bias and mista,es. There(ore! the Analyst should be
practiced in this s,ill so as to be able to apply them +uic,ly so that it can be used even in high-pressure or
emergency situations 'here a snap decision is necessary and a 'rong decision is tragedy.
E,ample Trust !ules
This is a sample o( generic trust rules anyone can employee to ma,e better hiring decisions beyond that
o( *ust the technical +uali(ication o( the applicant. "t (ollo's the 0 trust properties. The goal is to ma,e
+uanti(iable +uestions 'hich can be ans'ered (or each o( the properties and applied by any person and
on any potential ne' hire. #olid trust rules allo's (or consistency in +uality rather than relying on the Rgut
instinctS o( the gate ,eepers 'ho need to ma,e the trust decisions.
. Sie)
.. Calculate the applicant divided by the total group o( applicants.
.2. Calculate the number o( people the applicant appears to ,no' in the group divided by total
applicants (rom the total group.
.3. Calculate the number o( current employees the applicant ,no's -and is R(riendsS 'ith. in this
location and divide it by the total number o( employees in this location.
.8. /ecord the average o( these results.
2. Symmetry@
2.. The number o( people the applicant must rely on to do their *ob in this position -including the
applicant. divided by the number o( pro(essionals 'ho must rely on the applicant in this
position.
3. (isibility@
3.. The number o( hours per day the applicant 'ill be 'or,ing alone! unassisted! unmonitored
divided by the number o( 'or,ing hours.
8. Sub+ugation@
8.. The number o( decisions the employee 'ill be ma,ing daily! independently! 'ithout input!
divided by the total number o( decisions the position normally re+uires in a day.
8.2. The applicant divided by the number o( team members the applicant 'ill be 'or,ing 'ith
daily.
8.3. /ecord the average o( these results.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
@% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
N. Consistency@
N.. The total number o( months 'hich the applicant has not been employed divided by the total
number o( months the applicant has been on the 'or,(orce and eligible (or employment.
N.2. The total number o( criminal o((enses ,no'n divided by the current age less eighteen years -or
the legal age o( an adult in your region. o( the applicant.
N.3. The number o( neutral or negative re(erences (rom past employers divided by the total
number o( past employers.
N.8. /ecord the average o( these results.
C. "ntegrity@
C.. The number o( deliverables the applicant must produce or sho' (or on a 'ee,ly basis divided
by the 'or, 'ee,.
O. Offsets@
7.1. A"ount o& assets ! .alue the applicant /ill ha.e access to %i.i%e% ! a stan%ar%i#e% cost o&
prosecution an% cost o& reco.er!.

7. (alue@
7.. The monthly income created or saved by the applicant in the position divided by the monthly
cost o( the applicant. (-e %on9t "easure the a"ount pai% ! the position co"pare% to the
national a.era$e ecause no clear correlation e5ists et/een pa! $ra%e an% 8o satis&action
pre.entin$ an e"plo!ee &ro" lea.in$, stealin$, or saota$in$ the /orkplace.)
P. Components@
P.. The number o( processes 'hich re+uire the applicant divided by the total number o( processes
(or the position.
P.2. The number o( resources the employee 'ill use monthly divided by the total number o(
resources available (or all employees in that position.
P.3. /ecord the average o( these results.
0. Porosity)
0.. The amount o( time 'ee,ly the applicant 'ould spend interacting directly 'ith competitors!
partners! or clients divided by the total number o( 'ee,ly 'or, hours.
0.2. The number o( employees living in the same community as the applicant divided by the total
number people in the community.
0.3. /ecord the average o( these results.
)ach e5a"ple o& a calculation is to "ake a percenta$e /hich /ill e a.era$e% /ith the other
percenta$es o& all trust properties to create a &inal trust .alue. ,he &inal .alue /ill tell !ou ho/ "uch !ou
shoul% trust the ne/ e"plo!ee. Ae-e.aluations can then e "a%e re$ularl! to see ho/ "uch has
chan$e% an% i& this shoul% in&luence an! per"issions pro.i%e% to the e"plo!ee, pa! rate, or other
onuses.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org @3
OSSTMM 3 The Open Source Security Testing Methodology Manual
9.9 &pplying Trust )ules to Security Testing
#ecurity tests 'ill veri(y 'hich operational trusts e1ist ho'ever the use o( trust rules are re+uired to ,no' i(
they should e1ist. This is determined 'ith the use o( the Trust /ules during security testing.
#ecurity management and policy creation is generally based on ris, 'hich de(ines the permissible
interactions 'ithin and throughout an organi0ation. This method essentially de(ines rules (or users and
con(igurations (or systems 'hich 'ill provide the re+uired level o( protection 'hen (ollo'ed. The policy
may also dictate ho' to handle problems 'hich can occur should the rules or con(igurations be
insu((icient or not properly (ollo'ed. There(ore the security policy 'ill outline 'hat the organi0ation
determines as trust'orthy or not and 'hich operational trusts 'ill be allo'ed. 2o'ever to test operational
trust as established by the security policy is not security testing and it 'ill not help an organi0ation better
determine 'here its protection is limited.
#ecurity testing against a particular policy to assure the rules are (ollo'ed is called compliance testing
and it is not the same as security testing. The use o( the %##T&& audit 'ill determine the e1isting
operational trusts 'hether or not they are ac,no'ledged 'ithin the security policy. These (indings
sub*ected to trust analysis 'here the Trust /ules have been applied on people! systems! and processes 'ill
provide a precise measurement o( 'here controls need to be. This can then be compared to the security
policy to (ind the de(iciencies that impact current protection measures as 'ell as (uture security plans.
:ltimately the Analyst 'ould use trust metrics in place o( ris, analysis (or a more accurate means o(
protecting a scope.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
@- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
There are only % ways to steal somethingB
either you ta"e it yourself or you have
someone else ta"e it and give it to you.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org @9
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter : < 6or" 3low
The %##T&& (lo' begins 'ith a revie' o( the targetKs posture. The posture is the culture! rules! norms!
contracts! legislation! and policies de(ining the target. "t ends 'ith result comparisons to any alarms! alerts!
reports! or access logs. This is a (ull-circle concept 'here the (irst step is to be a'are o( the operational
re+uirements (or interacting 'ith the target! and the last step is the revie' o( the records o( the audit trail.
6or the Analyst! this is simply) you ,no' 'hat you need to do! you do it! and then you chec, 'hat you
have done.
This methodology separates 'hat needs to be done into this hierarchical (ormat)
. C2ANN$;
2. &%D:;$
3. TA#B
The 'or, is described in the module description (or each particular channel audit. #ome audits apply to
technologies 'hich may straddle the border bet'een t'o or more channels. 6or e1ample! commonly
(ound 'ireless ;ANs must be tested under both the Data Net'or,s channel and the 4ireless channel. This
is 'hy a properly de(ined testing plan is so important. Channel hybridi0ation is a constant and should not
be overloo,ed. The %##T&& is (ully capable o( a Rside'al, to ,ernelS security revie' and there(ore is
completely capable o( applying an analysis to a target 'hether its channels are clearly distinct and
separate or comprised o( multiple channels. There(ore! (or all targets! the Analyst should anticipate the
need to de(ine an audit to include multiple channels. #ometimes only under investigation 'ill it become
evident 'hether the scope contains any targets under a particular channel or i( the Analyst 'ill miss
targets only available under other channels.
This methodology applies to all (ive channels. "t has O modules and all the same properties apply to all
(ive channels. 4hile the methodology itsel( may be the same! each channel di((ers in tas,s. $ach module
has an input and an output. The input is the in(ormation used in per(orming each tas,. The output is the
result o( completed tas,s. This output may or may not be intelligence -analy0ed data. to serve as an input
(or another module and this output may (urther serve as the input (or more than one module or section.
There(ore! (ailure to complete certain modules or tas,s may limit the success(ul completion o( other
modules or tas,s. This 'ould limit the thoroughness o( the audit (ar more than *ust an accounting (or the
missing tas,s 'ould reveal.
#ome tas,s yield no output! meaning that modules 'ill e1ist (or 'hich there is no input. &odules 'hich
have no input can be ignored during testing but must be later documented 'ith an e1planation (or not
having been per(ormed. Also! tas,s 'ith no output do not necessarily indicate an in(erior testL rather! they
may indicate superior security. "n detail! tas,s that have no resulting output can mean any o( (ive things)
. The channel 'as obstructed in some 'ay during the per(ormance o( the tas,s.
2. The tas,s 'ere not properly per(ormed.
3. The tas,s 'ere not applicable.
8. The tas, result data has been improperly analy0ed.
N. The tas, reveals superior security.
"t is important that impartiality and open-mindedness e1ist in per(orming the tas,s o( each module. The
primary tenet (or auditing states! in similar regard to a con(ormational bias) R4hen one searches (or
something! one e1pects to (ind it! 'hich may lead you to (inding only 'hat you are searching (or.S "n the
%##T&&! each module begins as an input and ends as an output e1actly (or the reason o( ,eeping bias
minimal. There(ore! each tas, gives a direction o( 'hat should be revealed to move to another point
'ithin the methodology.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
@: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
A previous trust analysis may be incorporated to determine scope according to vector and channel. A
trust analysis can also be used to predetermine 'hich modules need to be per(ormed as independent
tests. 2o'ever! remember that modules are parts o( a 'hole test and the assumption that any particular
module can *ust be omitted is (alse and 'ill lead to an improper test. "( there is no input (or a particular
module though! it may be omitted 'ithout degrading the +uality o( the test. The di((erence is that! in the
(irst case! the module or tas, is ignored based on a trust decision 'hile in the second the test itsel(
dictated that the module or tas, cannot be per(ormed.
4ith the provision o( testing as a service! it is important to communicate to the target o'ner e1actly 'hat
o( the scope has not or 'ill not be tested. This manages e1pectations and potentially inappropriate ris,
assurances in the security o( a system.
Testing time 'ith the modules is relative to the plan. 6or e1ample! i( the Analyst tests the physical security
o( a door! then the test 'ould have at least t'o vectors) the doorKs (unctional security (rom the outside o(
the room to the inside! and then (rom the inside o( the room to the outside. Determining the proper scope
based on the vector is important because there may still be targets outside o( the vector and still 'ithin
the scope 'hich 'ill not ma,e up the current testing scope. %verall! larger scopes 'ith multiple channels
and multiple vectors re+uire more time spent on each module and its tas,s. The amount o( time allo'ed
be(ore returning 'ith output data is not determined by this methodology and depends on the Analyst!
the target! the test environment! and the test plan.
:.1 Methodology 3low
The %##T&& does not allo' (or a separation bet'een 'hat is considered active data collection and
veri(ication through agitationL because! in both cases! interaction is re+uired. Nor does it di((erentiate
bet'een active and passive testing 'here active testing is the agitation to create an interaction 'ith the
target and passive testing is the recording! aggregation! and analysis o( emanations (rom the target. This
methodology re+uires both active and passive tests. 6urthermore! the Analyst may not be able to
di((erentiate bet'een data collected passively (rom emanations o( the operations and that 'hich is the
delayed or misdirected response to agitation. The introduction o( any outside event! including the passive
,ind! has the potential to change the nature o( the targetKs operations and lo'er the +uality o( an
unin(luenced test on operational security. 2o'ever! this does not represent a (ailure o( the Analyst or the
audit process! but simply an unavoidable evil o( testing a system in a stochastic environment over a linear
time (rame. #imply put! the Analyst o(ten cannot Rta,e bac,S the agitation once it has been set in motion
and any corrections 'ill cause additional and varied results that do not match the aim o( the original tas,.
This is important because it 'ill ma,e it di((icult to later compare results. "t 'ill also mean that prior tests 'ill
in(luence later tests due to the RmemoryS o( the impact o( the test. This is very noticeable in testing over
the 329##$C channel.
"t is important to note that 'hen harmoni0ing the %##T&& 'ith other testing standards! it is important not
to constrict the (lo' o( this methodology by introducing standards so (ormal and unrelenting that the
+uality o( the test su((ers.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org @;
OSSTMM 3 The Open Source Security Testing Methodology Manual
The Memory of Operations
,his is an e5a"ple o& ho/ +<0(()C operational tests in a stochastic en.iron"ent
o.er a linear ti"e &ra"e are a&&ecte% ! their o/n "e"or!.
Scenario 1
The Analyst tests entry into a secured area 'ith (alse authentication. The guard e1amines the
badge brie(ly and allo's the Analyst to enter. The Analyst per(orms the audit to the point
'here the Analyst is identi(ied and the nature o( the audit is revealed! i( at all.
Scenario %
The Analyst tests entry into a secured area 'ith (alse authentication. The guard e1amines the
badge brie(ly and doubting its authenticity! does not allo' the Analyst to enter. The Analyst
tries additional tactics until entry is gained. The Analyst per(orms the audit to the point 'here
the Analyst is identi(ied and the nature o( the audit is revealed! i( at all.
"n both scenarios and 2! there may or may not be a record o( the entry attempt. "( there is a
record! that record can be re-used either by the Analyst the ne1t time i( the badge is denied
as proo( o( its authenticity or by the guard 'ho may be doubting its authenticity and 'ants to
see 'hat other guards have done.
6or the ne1t audit! the Analyst may try the same badge again! attempt other means to gain
entry through social engineering techni+ues! or try using a di((erent badge. That guard! other
guards that the guard may have spo,en 'ith! and any log records o( either the success(ul or
(ailed attempt are all memories o( the Analyst! the techni+ue! and should the guard ,no' o(
the audit! the audit itsel(.
2o'ever! should scenario 2 occur! it is possible that the interaction escalating through the
additional techni+ues used by the Analyst means that scenario 2 is a more thorough test as
more tests are made 'ithin the same interaction. "t also means that the audit and the Analyst
'ill more li,ely be remembered by the guard.
"( the Analyst does not gain entry at all! then the completeness o( the test is limited as to 'hen
the Analyst ran out o( techni+ues! 'ith each (ailed techni+ue ma,ing entry that much more
di((icult. "( the Analyst goes through all techni+ues outlined by tas,s in the methodology! then
the tests have been completed. "( not! then the tests not yet conducted need to be tried on a
di((erent guard 'ith di((erent results as di((erent people behave di((erently.
4hile this may seem to be a human problem! it is not. A door or 'indo' (orced open too o(ten
'ill remain damaged until it is replaced. 3hysical use al'ays results in physical deterioration.
$ven in 'ired communications! the act o( snooping tra((ic 'ill cause delays -sometimes
noticeable. or change po'er consumption! both 'ith either direct or indirect and o(ten varied
results.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
@? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
:.% The Test Modules
To choose the appropriate test type! it is best to (irst understand ho' the modules are designed to 'or,.
Depending on the thoroughness! business! time allotment! and re+uirements o( the audit! the Analyst may
'ant to schedule the details o( the audit by phase.
There are (our phases in the e1ecution o( this methodology)
A. "nduction 3hase
<. "nteraction 3hase
C. "n+uest 3hase
D. "ntervention 3hase
$ach phase lends a di((erent depth to the audit! but no single phase is less important than another in
terms o( Actual #ecurity.
A. "nduction Phase
$very trip begins 'ith a direction. "n the induction phase! the Analyst begins the audit 'ith an
understanding o( the audit re+uirements! the scope! and the constraints to the auditing o( this scope.
%(ten! the test type is best determined a(ter this phase.
Module .escription +Fplanation
A. 'osture )eview
The revie' o( the culture! rules! norms!
regulations! legislation! and policies
applicable to the target.
Bno' the scope and 'hat tests must
be done. /e+uired i( 3hase C is to be
properly conducted.
A.2 2ogistics
The measurement o( interaction
constraints such as distance! speed!
and (allibility to determine margins o(
accuracy 'ithin the results.
Bno' the limitations o( the audit itsel(.
This 'ill minimi0e error and improve
e((iciency.
A.3 &ctive .etection $erification
The veri(ication o( the practice and
breadth o( interaction detection!
response! and response predictability.
Bno' the restrictions imposed on
interactive tests. This is re+uired to
properly conduct 3hases < and D.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org @@
OSSTMM 3 The Open Source Security Testing Methodology Manual
*. "nteraction Phase
The core o( the basic security test re+uires ,no'ing the scope in relation to interactions 'ith the targets
conveyed to interactions 'ith assets. This phase 'ill de(ine the scope.
Module .escription +Fplanation
<.8 $isibility &udit
The determination o( the targets to be
tested 'ithin the scope. Eisibility is
regarded as RpresenceS and not
limited to human sight.
Bno' 'hat targets e1ist and ho' they
interact 'ith the scope! i( at all. A
dead or missing target is also an
unresponsive target. 2o'ever! an
unresponsive target is not necessarily a
missing target.
<.N &ccess $erification
The measurement o( the breadth and
depth o( interactive access points
'ithin the target and re+uired
authentication.
The access point is the main point o(
any asset interaction. Eeri(ying an
access point e1ists is one part o(
determining its purpose. 6ull
veri(ication re+uires ,no'ing all there is
to ,no' about the access point.
<.C Trust $erification
The determination o( trust relationships
(rom and bet'een the targets. A trust
relationship e1ists 'herever the target
accepts interaction bet'een targets in
the scope.
Trusts (or ne' processes are o(ten very
limited 'here older processes have a
seemingly chaotic evolution to the
outsider. Bno'ing trust relationships
bet'een targets 'ill sho' the age or
value o( the interaction.
<.O ,ontrol $erification
The measurement o( the use and
e((ectiveness o( the process-based
-Class <. loss controls) non-repudiation!
con(identiality! privacy! and integrity.
The control o( alarm is veri(ied at the
end o( the methodology.
&ost processes are de(ined in
response to a necessary interaction
and some remain long a(ter that
interaction stops or has changed.
Bno'ing 'hat process controls are in
place is a type o( security archeology.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1>> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
C. "n8uest Phase
&uch o( security auditing is about the in(ormation that the Analyst uncovers. "n this phase! the various
types o( value or the detriment (rom misplaced and mismanaged in(ormation as an asset are brought to
light.
Module .escription +Fplanation
C.7 'rocess $erification
The determination o( the e1istence
and e((ectiveness o( the record and
maintenance o( e1isting actual
security levels or diligence de(ined by
the posture revie' and
indemni(ication controls.
Bno' the controllers and their routines
(or the controls. &ost processes 'ill
have a de(ined set o( rules! ho'ever
actual operations re(lect any
e((iciency! la0iness! or paranoia 'hich
may rede(ine the rules. #o itKs not *ust
that the process is there but also ho' it
'or,s.
C.P
,onfiguration $erification C
Training $erification
The research o( the steady state
-normal operation. o( the targets as
they have been designed to operate
under normal conditions to determine
underlying problems outside o( the
application o( security stress tests.
This module e1plores the de(ault
conditions under 'hich the targets
operate regularly to understand the
intent! business *usti(ication! and
reasoning (or the targets. Additionally!
many regulations re+uire in(ormation
regarding ho' something is planned
to 'or, and this is not al'ays evident
in the e1ecution o( that 'or,.
C.0 'roperty $alidation
The measurement o( the breadth and
depth in the use o( illegal or unlicensed
intellectual property or applications
'ithin the target.
Bno' the status o( property o'nership
rights.
C. Segregation )eview
A determination o( the levels o(
personally identi(iable in(ormation
de(ined by the posture revie'.
Bno' 'hich privacy rights apply and
to 'hat e1tent the uncovered
personally identi(iable in(ormation can
be classi(ied based on these
re+uirements.
C.2 +Fposure $erification
The search (or (reely available
in(ormation 'hich describes indirect
visibility o( targets or assets 'ithin the
chosen channel o( the scope.
The 'ord on the street has value.
:ncover in(ormation on targets and
assets (rom public sources including
that (rom the targets themselves.
C.3
,ompetitive ntelligence
Scouting
The search (or (reely available
in(ormation! directly or indirectly! 'hich
could harm or adversely a((ect the
target o'ner through e1ternal!
competitive means.
There may be more value in the
in(ormation (rom processes and
targets than the assets 'hich they are
protecting. :ncover in(ormation that
by itsel( or in aggregate can in(luence
competitive business decisions.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1>1
OSSTMM 3 The Open Source Security Testing Methodology Manual
0. "nter#ention Phase
These tests are (ocused on the resources the targets re+uire in the scope. Those resources can be
s'itched! changed! overloaded! or starved to cause penetration or disruption. This is o(ten the (inal phase
o( a security test to assure disruptions do not a((ect responses o( less invasive tests and because the
in(ormation (or ma,ing these tests may not be ,no'n until other phases have been carried out. The (inal
module! D.O! o( Alert and ;og /evie'! is re+uired to veri(y prior tests 'hich provided no interactivity bac,
to the Analyst. &ost security tests that do not include this phase may still need to run an end revie' (rom
the perspective o( the targets and assets to clari(y any anomalies.
Module .escription +Fplanation
D.8 !uarantine $erification
The determination and measurement
o( e((ective use o( +uarantine (or all
access to and 'ithin the target.
Determine the e((ectiveness o(
authentication and sub*ugation
controls in terms o( blac, and 'hite list
+uarantines.
D.N 'rivileges &udit
The mapping and measurement o( the
impact o( misuse o( sub*ugation
controls! credentials! and privileges or
the unauthori0ed escalation o(
privilege.
Determine the e((ectiveness o(
authori0ation on authentication!
indemni(ication! and sub*ugation
controls in terms o( depth and roles.
D.C
Survivability $alidation C
Service ,ontinuity
The determination and measurement
o( the resilience o( the target to
e1cessive or adverse changes 'here
continuity and resilience controls
'ould be impacted.
Determine the e((ectiveness o(
continuity and resilience controls
through the veri(ication o( denial o(
service and denial o( interactivity.
D.O
&lert and 2og )eview C
+nd Survey
A revie' o( audit activities per(ormed
'ith the true depth o( those activities
as recorded by the target or (rom a
third-party as in the control o( alarm.
Bno' 'hat parts o( the audit le(t a
usable and reliable trail.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1>% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
:.3 One Methodology
3utting all the modules together provides one methodology to ,no' and 'or, 'ith. This is one
methodology 'hich is applicable to any and all types o( security tests. 4hether the target be a particular
system! a location! a person! a process! or thousands o( them! this one methodology 'ill assure the most
thorough and e((icient test possible.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1>3
OSSTMM 3 The Open Source Security Testing Methodology Manual
n roulette you need to bet on the person
spinning the wheel and throwing the ball.
2i"e any other human they get bored and
fall into a routine. +Fploit the person
whose predictability has inevitably better
odds than the machine.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1>- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter ; A 0uman Security Testing
2uman #ecurity -2:&#$C. is a subsection o( 329##$C and includes 3sychological %perations -3#9%3#..
Testing this channel re+uires interaction 'ith people in gate,eeper positions o( assets.
This channel covers the involvement o( people! primarily the operating personnel 'ithin the target scope
or (rame'or,. 4hile some services consider this simply as Rsocial engineeringS! the true compliance
ob*ective o( security testing in this channel is personnel security a'areness testing and gap measurement
to the re+uired security standard outlined in company policy! industry regulations! or regional legislation.
The Analyst 'ill be re+uired to have multiple tools and methods (or the completion o( some tas,s to assure
that suspicion is not raised among personnel and tests are not made invalid due to an early discovery or
heightened paranoia. "t may also be pertinent to limit test sub*ects to one per department or other
boundary.
Competent Analysts 'ill re+uire both diligent people s,ills and critical thin,ing s,ills to assure (actual data
collection creates (actual results through correlation and analysis.
Considerations
3lease note the (ollo'ing considerations to assure a sa(e! high +uality test)
. "n personam) #cope restrictions target those personnel 'ho are under direct legal contract 'ith
the scope o'ner and! there(ore! have legal responsibility (or their security a'areness and
obligations.
2. 3lausible deniability) No direct personnel security testing 'ill ta,e place (or personnel 'ho have not
been trained! in(ormed! or can be said to possess security a'areness e1perience or obligations
due to *ob responsibility re+uirements.
3. 2uman rights) 4here personnel to be tested are randomly chosen or are not said to have *ob
responsibilities directly related to gate ,eeping! security! or sa(ety! the Analyst 'ill re(rain (rom
personally identi(ying the person and report solely on a statistical basis.
8. "ncommunicado) 3ersonnel given time 'ill discuss the actions o( the test 'ith others and alter the
course o( the testing.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1>9
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.2 Posture !e#ie3
"nitial studies o( the posture includes the la's! ethics! policies! industry regulations! and political culture
'hich in(luence the security and privacy re+uirements (or the scope. This revie' (orms a matri1 to 'hich
testing should be mapped but not constrained.
O.. 3olicy
/evie' and document appropriate organi0ational policy regarding security! integrity! and privacy
responsibilities o( personnel in the scope.
O..2 ;egislation and /egulations
/evie' and document appropriate regional and national legislation and industry regulations
regarding the security and privacy re+uirements o( the organi0ation in the scope as 'ell as that
'hich includes the appropriate customers! partners! organi0ational branches! or resellers outside
the scope.
O..3 Culture
/evie' and document appropriate organi0ational culture in the scope to'ards security and
privacy a'areness! re+uired and available personnel training! organi0ational hierarchy! and
recogni0ed trust interaction bet'een employees.
O..8 /elationships
/evie' and document the appropriate in(luential relationships bet'een personnel (rom the
organi0ational hierarchy (rom 'ithin the scope.
O..N /egional Culture
/evie' and document the appropriate in(luence o( regional and (oreign cultures on social
hierarchy in the environment in 'hich the scope resides.
O..C $conomics
/evie' and document the appropriate in(luence o( economics and pay scale on social status o(
personnel (rom both the vector o( personnel 'ithin the scope and that o( the outside community
on 'hich the scope resides.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1>: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.5 Logistics
3reparation o( the channel test environment needed to prevent (alse positives and (alse negatives 'hich
lead to inaccurate test results.
O.2. Communications $+uipment
Test (or communications that provide identi(ication to the receiver such as caller "D! 6AW bac,! "3
address logging! locator badges! and e-mail gate'ay headers. Test 'hether the identi(ication be
bloc,ed! removed! or ob(uscated! and to 'hat degree o( anonymity.
O.2.2 Communications
Test 'hich languages are used 'ithin the scope and 'hich languages are communicated
bet'een the scope and the customers! partners! and resellers outside the scope.
O.2.3 Time
Test (or the time0one! holidays! and 'or, schedules (or various roles and *obs 'ithin the scope
including partners! resellers! and in(luential customers interacting 'ith the scope.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1>;
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.6 Acti#e 0etection (erification
Determination o( active and passive controls to detect intrusion to (ilter or deny test attempts must be
made prior to testing to mitigate the ris, o( creating (alse positives and negatives in the test result data as
'ell as changing the alarm status o( monitoring personnel or agents.
O.3. Channel &onitoring
Test 'hether help des, or support channels over telephone! instant messaging! chat! 'eb-based
(orums! or e-mail! are monitored by a third party (or +uality control.
O.3.2 Channel &oderating
Test 'hether help des, or support channels over telephone! instant messaging! chat! 'eb-based
(orums! or e-mail! are (iltered or +uarantined by personnel or automated system to veri(y (or
authenticity! strip e1traneous data! ignore repeated re+uests! or moderate interactions.
O.3.3 #upervision
Test 'hether support personnel may ans'er re+uests 'ithout con(irmation (rom a supervisor or
similar personnel.
O.3.8 %perator Assistance
Test 'hat access to 'hich personnel via the telecommunications channel must be made through
an operator! 'hether manned by personnel or automated.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1>? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.7 (isibility Audit
$numeration and veri(ication tests (or the visibility o( personnel 'ith 'hich interaction is possible via all
channels.
O.8. Access "denti(ication
Test (or channels 'hich provide interactions 'ith personnel (rom outside the scope and document
all methods used and the results o( those methods.
O.8.2 3ersonnel $numeration
$numerate the number o( personnel 'ithin the scope 'ith both authori0ed and unauthori0ed
access to processes 'ithin the scope! regardless o( time or access channel! and the method (or
obtaining that data.
;.< Access (erification
Tests (or the enumeration o( access points to personnel 'ithin the scope. 4hile access to personnel
outside o( the scope is a real scenario and one o(ten used (or in(ormation property the(t! this may be
limited to scope-only interaction to protect the independent privacy rights o( the personnel in their private
li(e.
O.N. Access 3rocess
&ap and e1plore the use o( channels into the scope to reach assets. Document all methods used
and the results o( those methods.
O.N.2 Authority
:se personnel in positions o( authority 'ith access-control or 'ho hold gate,eeper positions to assets
'ithin the scope. Document methods used in discovery o( ,ey personnel.
O.N.3 Authentication
$numerate and test (or inade+uacies (rom gate'ay personnel and 'hat privileges are re+uired to
interact 'ith them to assure that only identi(iable! authori0ed! intended parties are provided access.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1>@
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.= Trust (erification
Tests (or trusts bet'een personnel 'ithin the scope 'here trust re(ers to access to in(ormation or physical
assets (rom other targets 'ithin the scope.
O.C. &isrepresentation
Test and document the depth o( re+uirements (or access to assets 'ithin the scope 'ith the use o(
misrepresentation as a member o( the RinternalS support or delivery personnel (rom 'ithin the
scope 'ithout any credentials.
O.C.2 6raud
Test and document the depth o( re+uirements (or access to assets 'ithin the scope 'ith the use o(
(raudulent representation as a member o( the management or other ,ey personnel.
O.C.3 &isdirection
Test and document the depth o( re+uirements (or access to assets 'ithin the scope 'ith the use o(
misrepresentation as a member o( support or delivery personnel (rom outside the scope.
O.C.8 3hishing
Test and document the depth o( re+uirements (or access to personnel-controlled in(ormation or
physical assets through all discovered channels to personnel 'ithin the scope 'ith the use o( a
(raudulent gate'ay 'here personnel are as,ed to supply credentials. Document the methods and
all credentials collected in this manner.
O.C.N /esource Abuse
Test and document the depth o( re+uirements to ta,e assets outside o( the scope to a ,no'n and
trusted source or throughout the scope itsel( to other personnel 'ithout any established! re+uired
credentials.
O.C.C "n Terrorem
Test and document the depth o( re+uirements to incite (ear! revolt! violence! and chaos! through
the disruption o( personnel and the use o( rumor or other psychological abuse.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
11> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.; Controls (erification
Tests to enumerate types o( loss controls used to protect the value o( assets.
O.O. Non-repudiation
$numerate and test (or use or inade+uacies (rom gate'ay personnel to properly identi(y and log
access or interactions to assets (or speci(ic evidence to challenge repudiation. Document the
depth o( the interaction 'hich is recorded.
O.O.2 Con(identiality
$numerate and test (or use or inade+uacies (rom all segments o( communication 'ith personnel
'ithin the scope over a channel or properties transported over a channel using secured lines!
encryption! R+uietedS or RclosedS personal interactions to protect the con(identiality o( the
in(ormation assets ,no'n only to those 'ith the proper security clearance classi(ication o( that
asset.
O.O.3 3rivacy
$numerate and test (or use o( or inade+uacies (rom all segments o( communication 'ith personnel
'ithin the scope over a channel or properties transported using speci(ic! individual signatures!
personal identi(ication! R+uietedS or Rclosed roomS personal interactions to protect the privacy o(
the interaction and the process o( providing assets only to those 'ithin the proper security
clearance (or that process! in(ormation! or physical assets.
O.O.8 "ntegrity
$numerate and test (or inade+uacies in all segments o( communication 'ith personnel 'ithin the scope
'here assets are transported over a channel using a documented process! signatures! encryption!
hash! or mar,ings to protect and assure that the in(ormation or physical assets cannot be changed!
s'itched! redirected! or reversed 'ithout it being ,no'n to parties involved.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 111
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.> Process (erification
Tests to e1amine the maintenance o( (unctional security a'areness o( personnel in established processes
and due diligence as de(ined in the 3osture /evie'.
O.7. &aintenance
$1amine and document the timeliness! appropriateness! access to! and e1tent o( processes (or the
noti(ication and security a'areness o( all personnel in regards to operational security! actual
security! and loss controls.
O.7.2 &isin(ormation
Determine the e1tent to 'hich personnel security noti(ications and security ne's can be
e1panded or altered 'ith misin(ormation.
O.7.3 Due Diligence
&ap and veri(y any gaps bet'een practice and re+uirements as determined in the 3osture
/evie' through all channels.
O.7.8 "ndemni(ication
Document and enumerate the abuse or circumvention o( employee policy! insurance! non-
disclosure! non-compete! liability contracts! or use5user disclaimers 'ith all access personnel 'ithin
the scope over all channels.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
11% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.? Training (erification
Tests to e1amine the ability to circumvent or disrupt (unctional security a'areness education and training
in gate'ay personnel.
O.P. $ducation &apping
&ap types and (re+uency o( security a'areness assistance! education courses! and training
provided to personnel! partners! customers! and speci(ically to gate,eepers.
O.P.2 3olicy Disruption
Discover and e1amine the process and depth o( sel(-policing (rom personnel (or the disruption or
non-con(ormity o( security policy.
O.P.3 A'areness &apping
&ap the limitations discovered in security a'areness training (or personnel through gap analysis
'ith actual procedures! including but not limited to) the provision o( assets via any channel! the
ability to recogni0e improper and (orged identi(ication or re+uired methods! the method o( proper
identi(ication among personnel! the use o( personal security measures (or oneKs sel( and assets! the
handling o( con(idential and sensitive assets! and the con(ormity to organi0ational security policy.
O.P.8 A'areness 2i*ac,ing
Discover and e1amine the e1tent to 'hich a non-o((icial person provides misin(ormation regarding
security policy in an authoritative manner to purposely circumvent or brea, security policy.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 113
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.2@ Property (alidation
Tests to e1amine in(ormation and physical property available 'ithin the scope or provided by personnel
'hich may be illegal or unethical.
O.0. #haring
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is shared bet'een personnel either intentionally through shared processes and programs!
libraries! and personal caches or unintentionally through mismanagement o( licenses and
resources! or negligence.
O.0.2 <lac, &ar,et
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is promoted! mar,eted! or sold bet'een personnel or by the organi0ation.
O.0.3 #ales Channels
Eeri(y public! out o( scope businesses! auctions! or property sales 'hich provide contact
in(ormation through channels originating 'ithin the scope.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
11- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.22 Segregation !e#ie3
Tests (or appropriate separation o( private or personal in(ormation assets (rom business in(ormation. ;i,e a
privacy revie'! it is the (ocal point o( the legal and ethical storage! transmission! and control o( personnel!
partner! and customer private in(ormation.
O.. 3rivacy Containment &apping
&ap gate,eepers o( private in(ormation assets 'ithin the scope! 'hat in(ormation is stored! ho'
and 'here the in(ormation is stored! and over 'hich channels the in(ormation is communicated.
O..2 $vident "n(ormation
$numerate and map in(ormation regarding individual gate'ay personne. such as names! race!
se1! religion! vacation days! personal 'eb pages! published resumes! personal a((iliations! directory
in+uiries! ban, branch-es.! electoral register! and any particular personal in(ormation stated
implicitly as private in regulations and policy.
O..3 Disclosure
$1amine and document types o( disclosures o( private in(ormation assets on personnel (rom
gate,eepers responsible (or this segregation according to policy and regulations as determined in
the 3osture /evie' and the basic human right to privacy.
O..8 ;imitations
$1amine and document types o( gate'ays and channel alternatives 'ith gate'ays accessible to
people 'ith physical limitations 'ithin that channel.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 119
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.25 E,posure (erification
Tests (or uncovering in(ormation 'hich provides (or or leads to authenticated access or allo's (or unintended
access to multiple locations 'ith the same authentication.
O.2. $1posure &apping
$numerate and map personnel in(ormation regarding the organi0ation such as organi0ation charts!
,ey personnel titles! *ob descriptions! personal and 'or, telephone numbers! mobile phone
numbers! business cards! shared documents! resumes! organi0ational a((iliations! private and public
e-mail addresses! log-ins! log-in schemes! pass'ords! bac,-up methods! insurers! or any particular
organi0ational in(ormation stated implicitly as con(idential in regulations and policy.
O.2.2 3ro(iling
3ro(ile and veri(y the organi0ation! employee s,ill re+uirement types! pay scales! channel and
gate'ay in(ormation! technologies! and direction.
;.26 Competiti#e "ntelligence Scouting
Tests (or scavenging property that can be analy0ed as business intelligence. 4hile competitive
intelligence as a (ield is related to mar,eting! the process here includes any (orm o( competitive
intelligence gathering! including but not limited to economic and industrial espionage.
O.3. <usiness @rinding
&ap gate,eepers o( business assets 'ithin the scope! 'hat in(ormation is stored! ho' and 'here
the in(ormation is stored! and over 'hich channels the in(ormation is communicated bet'een
personnel.
O.3.2 <usiness $nvironment
$1plore and document (rom individual gate'ay personnel business details such as alliances!
partners! ma*or customers! vendors! distributors! investors! business relations! production!
development! product in(ormation! strategic planning! stoc,s and trading! and any particular
business in(ormation or property stated implicitly as con(idential in regulations and policy.
O.3.3 %rgani0ational $nvironment
$1amine and document types o( disclosures o( business assets (rom gate,eepers on operations!
processes! hierarchy! (inancial reporting! investment opportunities! mergers! ac+uisitions! channel
investments! channel maintenance! internal social politics! personnel dissatis(action and turn-over
rate! primary vacation times! hirings! (irings! and any particular organi0ational assets stated
implicitly as con(idential in regulations and policy.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
11: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.27 9uarantine (erification
Tests (or veri(ying the proper (ielding and containment o( aggressive or hostile contacts at the gate'ay points.
O.8. Containment 3rocess "denti(ication
"denti(y and e1amine +uarantine methods and process at the gate'ays in all channels (or
aggressive and hostile contacts such as sales people! head-hunters! gri(ters! *ournalists!
competitors! *ob see,ers! *ob candidates! and disruptive persons.
O.8.2 Containment ;evels
Eeri(y the state o( containment! length o( time! and all channels 'here interaction 'ith
gate,eepers has +uarantine methods. $nsure that methods are 'ithin legal conte1t and
boundaries.
;.2< Pri#ileges Audit
Tests 'here credentials are supplied to the user and permission is granted (or testing 'ith those
credentials.
O.N. "denti(ication
$1amine and document the process (or obtaining identi(ication through both legitimate and (raudulent
means on all channels.
O.N.2 Authori0ation
Eeri(y the use o( (raudulent authori0ation on all channels to gain privileges similar to that o( other
personnel.
O.N.3 $scalation
Eeri(y and map access to assets through the use o( privileges to gain higher or more e1tensive
privileges beyond that 'hich is authoritatively designated to the role.
O.N.8 Discrimination
Eeri(y in(ormation re+uested and privileges granted (rom gate,eepers in cases 'here age
-speci(ically those 'ho are legally minors (or the region.! se1! race! custom5culture! and religion are
(actors 'hich may be discriminated against in accordance to the 3osture /evie'.
O.N.N #ub*ugation
$numerate and test (or inade+uacies o( assets communicated over channels 'here those controls
are not re+uired! can be circumvented or ignored such as insecure e-mail or over a public
telephone line.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 11;
OSSTMM 3 The Open Source Security Testing Methodology Manual
;.2= Ser#ice Continuity
Determining and measuring the resilience o( the gate,eepers 'ithin the scope to e1cessive or hostile changes
designed to cause service (ailure.
O.C. /esilience
$numerate and test (or inade+uacies on all channels (rom personnel 'ithin the scope 'hereby
removing or +uieting gate'ay personnel 'ill allo' (or direct access to assets.
O.C.2 Continuity
$numerate and test (or inade+uacies (rom all personnel 'ith regard to access delays and service
response time through bac,-up personnel or automated means (or access to alternate gate'ay
personnel.
O.C.3 #a(ety
&ap and document the process o( gate,eepers disconnecting channels due to evacuation or
sa(ety concerns as a gap analysis 'ith regulation and security policy.
;.2; End Sur#ey
A gap analysis bet'een activities per(ormed 'ith the test and the true depth o( those activities as recorded or
(rom third-party perceptions both human and mechanical.
O.O. Alarm
Eeri(y and enumerate the use o( a locali0ed or scope-'ide 'arning system! log! or message (or
each access gate'ay over each channel 'here a suspect situation is noted by personnel upon
suspicion o( circumvention attempts! social engineering! or (raudulent activity.
O.O.2 #torage and /etrieval
Document and veri(y the privileged and e((icient access to alarm! log! and noti(ication storage
locations and property.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
11? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
The most useless types of physical security
controls are the "inds that donDt protect
against what you need them to and those
which protect against anything for no
reason.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 11@
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter ? A 'hysical Security Testing
329##$C -3hysical #ecurity. is a classi(ication (or the material security 'ithin the physical realm 'hich is
'ithin the limits o( human-interactive 3D space. Testing this channel re+uires non-communicative
interaction 'ith barriers and humans in gate,eeper positions o( assets.
This channel covers the interaction o( the Analyst 'ithin pro1imity o( the targets. 4hile some services
consider this simply as Rbrea,ing and enteringS! the true compliance ob*ective o( security testing in this
channel is physical and logical barrier testing and gap measurement to the re+uired security standard as
outlined in company policy! industry regulations! or regional legislation.
The Analyst 'ill be re+uired to have multiple tools and methods (or the completion o( some tas,s to assure
that suspicion is not raised among personnel and tests are not made invalid due to an early discovery or
heightened paranoia. "t may also be pertinent to limit test sub*ects to one per department or other
boundary. Analysts 'ill also need to be prepared (or the possibility o( accidental bodily harm (rom
conventional barriers and 'eapons! interactions 'ith animals! sub*ection to harm(ul bacteria! viruses! and
(ungi! e1posure to electromagnetic and micro'ave radiation! especially that 'hich can permanently
damage hearing or sight! and poisonous or corrosive chemical agents in any (orm.
Competent Analysts 'ill re+uire physical strength! endurance! agility! and critical thin,ing s,ills to assure
(actual data collection creates (actual results through correlation and analysis.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1%> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Considerations
3lease note the (ollo'ing considerations to assure a sa(e! high +uality test)
. Conatus) All attempts to traverse physical barriers re+uire an unbiased *udgment o( the amount o(
di((iculty re+uired to reach and interact 'ith the target and the danger involved. These
considerations are to be made 'ith regard to the R'ill to liveS o( humans as 'ell as any e((ect on
the targets should the attac, be made 'ithout regard (or li(e -suicidal..
2. $cce hora) All physical tests re+uire close attention be made to time. /ecords must be ,ept o( the
time the test is made! time on target! and time the test (inishes! 'hether success(ul or not! because
that 'ill also assist in determining 'hat can be accomplished 'ithin the time range to (ail. Bno'ing
such in(ormation can help understand 'hat may be a deceptive attac, so as to be sure resources
are not 'asted in one area 'hile leaving another open.
3. Abuse o( discretion) The Analyst must ta,e care not to ignore or misinterpret the results (rom testing
a physical barrier or obstacle because it is not 'ithin the range o( the AnalystKs physical
possibilities. The Analyst should remain unbiased and not over-estimate or over-value personal s,ills
and ability and instead apply the tests as a highly s,illed and highly able person could.
8. &agister pecuarius) The Analyst should not dismiss the reasonable potential o( an attac,er using
trained animals to circumvent barriers and obstacles 'here a human being cannot.
N. 3lausible deniability) No direct or physical personnel security testing 'ill ta,e place (or personnel
'ho have not been trained! in(ormed! or can be said to possess security a'areness e1perience or
obligations due to *ob responsibility re+uirements.
C. #ui generis) All interaction 'ith physical barriers 'ill leave record o( this interactivity and! in more
e1treme cases! may 'ea,en or destroy the barrier. The Analyst should ta,e care in testing one-o(-
a-,ind type targets 'hich may not be replaceable. The Analyst should also ta,e care not to leave
permanent mar,ings 'herever possible and to ,eep record o( all barriers tested to veri(y them (or
damage a(ter the audit.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1%1
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.2 Posture !e#ie3
"nitial studies o( the posture includes the la's! ethics! policies! industry regulations! and political culture
'hich in(luence the security and privacy re+uirements (or the scope. This revie' (orms a matri1 to 'hich
testing should be mapped but not constrained.
7.. 3olicy
/evie' and document appropriate organi0ational policy regarding security! sa(ety! integrity -i.e.
supply chain.! and privacy re+uirements (or barriers in the scope.
7..2 ;egislation and /egulations
/evie' and document appropriate regional and national legislation and industry regulations
regarding the security and privacy re+uirements o( the organi0ation in the scope as 'ell as that
'hich includes the appropriate customers! partners! organi0ational branches! or resellers outside
the scope.
7..3 Culture
/evie' and document appropriate organi0ational culture in the scope to'ards security and
privacy a'areness! re+uired and available personnel training! organi0ational hierarchy! and
recogni0ed trust interaction bet'een employees.
7..8 /elationships
/evie' and document the appropriate in(luential relationships bet'een personnel (rom the
organi0ational hierarchy (rom 'ithin the scope.
7..N /egional Culture
/evie' and document the appropriate in(luence o( regional and (oreign cultures on sa(ety! social
hierarchy! the supply chain! and services in the environment in 'hich the scope resides.
7..C $conomics
/evie' and document the appropriate in(luence o( economics and pay scale on social status
and criminal intent on personnel (rom both the vector o( personnel 'ithin the scope and that o(
the outside community in 'hich the scope resides.
7..O $nvironment
/evie' (or the target region the 'eather patterns! dangerous 'eather e1tremes -i.e. (looding!
tornadoes! hurricanes.! temperature e1tremes! humidity ma1imums! air +uality! tectonic stability!
typical (auna! (orms o( natural or man-made disaster and general insect in(estation.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1%% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.5 Logistics
3reparation o( the channel test environment needed to prevent (alse positives and (alse negatives 'hich
lead to inaccurate test results.
7.2. $nvironment
-a. $1amine the scope to determine i( any special e+uipment is re+uired (or the environment o(
the targets. $+uipment can range (rom rope to climb 'alls to #C:<A gear to travel under
'ater. $+uipment types are not limited to *ust the environment but also the barriers one must
circumvent.
-b. Eeri(y damaged sa(ety e+uipment 'hich may lead to Analyst in*ury.
-c. $1amine the targets (or ha0ardous! contaminated! or poorly maintained terrain! air! 'ater!
buildings! or structures.
-d. $1amine noise! electromagnetic radiation! and magnetic (ield levels at the scope.
7.2.2 Communications
-a. Test 'hich languages are used 'ithin the scope and 'hich languages are communicated
bet'een the scope and the customers! partners! and resellers outside the scope.
-b. $1amine the means o( communication bet'een personnel and 'hether it is enhanced
through the use o( tools such as (lags! (lares! radios! binoculars! night vision! etc.
7.2.3 Time
-a. Test (or the time0one! holidays! and 'or, schedules (or various roles and *obs 'ithin the scope
including partners! resellers! and in(luential customers interacting 'ith the scope.
-b. Determine i( decreased mobility or visibility during time o( day! 'ee,! month! or season -day or
night! (og! rain! or sno'. 'ill have an impact upon operations at the target.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1%3
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.6 Acti#e 0etection (erification
Determination o( active and passive controls to detect intrusion to (ilter or deny test attempts must be
made prior to testing to mitigate the ris, o( creating (alse positives and negatives in the test result data as
'ell as changing the alarm status o( monitoring personnel or agents.
7.3. &onitoring
-a. Eeri(y that the scope is monitored by a third party (or intrusion via loo,-outs! guards! cameras!
or sensors. The date and time o( entry as 'ell as departure o( the target should be recorded.
-b. Determine the range o( the monitoring and 'hether the travel o( a threat to the target can be
intercepted in a timely manner.
-c. Eeri(y i( travel to the target re+uires increased time on target and e1posure. This includes! but is
not limited to) +uarantine rooms! long empty hall'ays! par,ing lots! large empty e1panses!
di((icult or unnatural terrain! and guest or holding areas.
-d. Eeri(y that the lighting and visible contrast on approach to the target allo's (or interception o(
threats.
7.3.2 /eacting
-a. Eeri(y i( interactive controls (or the target 'ill react timely to e1treme environmental conditions
according to the $nvironment revie' tas, o( the 3osture /evie'.
-b. Eeri(y i( the target 'ill react timely to a disturbance in air! 'ater! and soil +uality.
-c. Eeri(y i( the target 'ill react timely to critical noise disturbances.
-d. Eeri(y i( the target 'ill react timely to magnetic (ield disturbances.
-e. Eeri(y i( the target 'ill react timely to (ires.
-(. Eeri(y i( the target 'ill react timely to denial o( target access via bloc,ade or +uarantine.
-g. Eeri(y i( the target 'ill react timely to threats o( (ear! revolt! or violence 'ithin the scope.
-h. Determine the (inality o( threat interception.
>.7 (isibility Audit
$numeration and veri(ication tests (or the visibility o( targets and assets. "n 329##$C! assets must also
include supplies such as (ood! 'ater! (uel! etc. and operational processes 'hich may a((ect those
supplies li,e the proper removal o( 'aste and other contaminants! loading and unloading supply
shipments! sleep and rest cycles! proper acclimati0ation! etc.
7.8. /econnaissance
-a. &ap and detail the scope perimeter determined by visible and assisted vie'ing techni+ues!
publicly accessible areas! public plans! and public sources.
-b. $numerate and detail targets and assets visible (rom outside the scope.
-c. $numerate and detail target tra((ic patterns! (oot tra((ic! occupied areas! and sensors visible
outside the scope.
-d. $numerate directories and internal telephone boo,s identi(ying locations o( sensitive
in(ormation processing (acilities that are not readily accessible by the public.
-e. &ap and enumerate the physical location and layout o( the targets! the si0e and navigability
o( obstacles! barriers! and ha0ards 'hich 'ill increase time on target.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1%- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.< Access (erification
Tests (or the enumeration o( access points to interact 'ith the targets and assets 'ithin the scope. 4hile
access to 'alls and (ences bordering property outside o( the scope is a real scenario and one o(ten used
in an attac,! this audit is limited to scope-only interaction to protect the property rights o( third parties.
7.N. $numeration
-a. &ap and e1plore the navigable o( terrain! barriers! and obstacles into the scope to reach the
targets and assets. Document all methods used and the results o( those methods.
-b. &ap and veri(y all access points that allo' stealthy or unmonitored! direct -3 seconds or less
time on target. interaction 'ith the target.
-c. Eeri(y the si0e and navigable o( public and private access points and all paths to target.
7.N.2 Authentication
-a. $numerate and test (or inade+uacies 'hich privileges are re+uired to access! the process o(
obtaining those privileges! and assure that only identi(iable! authori0ed! intended parties are
provided access.
-b. Eeri(y the process o( authenticating 'hich items may be ta,en into the scope by both
authori0ed and unauthori0ed personnel.
-c. Eeri(y the process o( authenticating 'hich items may be ta,en out o( the scope by both
authori0ed and unauthori0ed personnel.
-d. Eeri(y the process o( recording access and 'hich items 'ere entered and removed.
7.N.3 ;ocation
-a. &ap the distance (rom the scope perimeter to the visible targets and assets (rom outside the
scope.
-b. &ap and identi(y all paths to access points 'hich can be reached in a noisy! not stealthy!
direct -3 seconds or less time on target. interaction 'ith that access point. This may include
attac,s 'hich are sans conatus -'ithout regard (or the attac,erKs li(e..
7.N.8 3enetration
-a. Determine 'hich barriers and obstacles in the scope provide remote access to change!
disrupt! destroy! or obtain assets -visually! aurally! and magnetically..
-b. Determine the e((ectiveness o( barriers and obstacles to 'ithstand conditions de(ined in the
3osture /evie'.
-c. Determine and rate the e((ectiveness o( barriers and obstacles to 'ithstand (ire! e1plosions!
and general concussive (orces such as gunshots and vehicular ramming.
-d. Determine and rate the e((ectiveness o( barriers and obstacles to reduce incoming) critical
noise levels! heat! cold! smo,e! humidity! disruptive or caustic odors! intense magnetic (ields!
harm(ul light! and pollutants.
-e. Determine and rate the e((ectiveness o( barriers and obstacles to reduce outgoing) sounds!
smells! vibrations! conditions (or acclimati0ation! smo,e! magnetic (ields! 'aste! and pollutants.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1%9
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.= Trust (erification
Tests (or trusts bet'een processes 'ithin the scope 'here trust re(ers to access to assets 'ithout the need
(or identi(ication or authentication.
7.C. &isrepresentation
-a. Test and document the depth o( re+uirements (or access to assets 'ith the use o(
misrepresentation as a member o( the RinternalS support or delivery personnel 'ithout proper
credentials.
-b. Test and document the depth o( re+uirements (or access to assets 'ith the use o(
misrepresentation as a disabled person.
7.C.2 6raud
Test and document the depth o( re+uirements (or access to assets 'ith the use o( (raudulent
representation o( authority as a member o( the management or other ,ey personnel.
7.C.3 &isdirection
Test and document the depth o( re+uirements (or access to assets 'ith the use o(
misrepresentation as a member o( support or delivery personnel outside the scope.
7.C.8 #to'age
Test and document the depth o( re+uirements (or access to assets through stealthy sto'age 'ith a
transport o( support or delivery to ta,e the sto'age outside the scope.
7.C.N $mbe00lement
Test and document the depth o( re+uirements to hide assets 'ithin the scope -'hole or
destroyed.! ta,e assets outside o( the scope to a ,no'n and trusted source! and throughout the
scope itsel( to other personnel 'ithout any established! re+uired credentials.
7.C.C "n Terrorem
Test and document the depth o( re+uirements to incite (ear! revolt! violence! and chaos! through
the disruption o( processes and the contamination o( supplies.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1%: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.; Controls (erification
Tests to enumerate types o( loss controls used to protect the value o( assets.
7.O. Non-repudiation
$numerate and test (or use or inade+uacies (rom monitors and sensors to properly identi(y and log
access or interactions 'ith assets (or speci(ic evidence to challenge repudiation. Document the
depth o( the interaction 'hich is recorded.
7.O.2 Con(identiality
$numerate and test (or use or inade+uacies (rom all signals! physical communication! and
transported items bet'een both internal and e1ternal-reaching processes and personnel using
codes! undecipherable language! R+uietedS or RclosedS personal interactions to promote the
con(identiality o( the communication only to those 'ith the proper security clearance classi(ication
(or that communication.
7.O.3 3rivacy
$numerate and test (or use o( or inade+uacies (rom all interactions 'ithin the scope using
unmar,ed or non-obvious pac,aging or labeling! R+uietedS or Rclosed roomS interactions! and
'ithin randomly chosen +uarters to hide or protect the privacy o( the interaction and only to those
'ith the proper security clearance (or that process or asset.
7.O.8 "ntegrity
-a. $numerate and test (or inade+uacies in all signals and communication bet'een processes
and personnel using a documented process! seals! signatures! hashing! or encrypted mar,ings
to protect and assure that the assets cannot be changed! redirected! or reversed 'ithout it
being ,no'n to the parties involved.
-b. $numerate and test (or inade+uacies in all processes and interactions 'ith assets in transport
'hich use a documented process! signatures! seals! brea,-a'ay tape! brands! tags! sensors! or
encrypted mar,ings to protect and assure that the assets cannot be changed! redirected! or
reversed 'ithout it being ,no'n to the parties involved.
-c. Eeri(y all storage mediums (or in(ormation are not in danger (rom unnatural decay such as
heat or humidity damage! (ading (rom direct sunlight! or magnetic degradation -bit rot..
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1%;
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.> Process (erification
Tests to e1amine the maintenance o( (unctional security operations in established processes and due
diligence as de(ined in the 3osture /evie'.
7.7. &aintenance
-a. $1amine and document the timeliness! appropriateness! access to! and e1tent o( processes (or
e+uipment and barrier repair in regards to operational security! actual security! and loss
controls.
-b. Eeri(y the repair and determine the e1tent to 'hich notice and +uality o( repairs can be
misrepresented and (alsi(ied.
7.7.2 "ndemni(ication
-a. Document and enumerate the ability to abuse or circumvent employee policy! insurance!
non-disclosure! non-compete! liability contracts! or use5user disclaimers (or personnel 'ithin the
scope.
-b. $numerate the use o( signs 'arning o( danger! surveillance or alarms in e((ect! health issues!
and postings o( no entrance.
-c. Eeri(y the e1tent and (inality o( legal action used to uphold indemni(ication.
>.? Configuration (erification
Tests to e1amine the operation o( processes under various levels o( security conditions. :nderstanding
ho' processes 'or, under daily routine and e((iciencies provides insight to ho' they should behave
under more e1treme conditions.
7.P. $ducation &apping
&ap types and (re+uency o( physical security and sa(ety assistance! education courses! and
training provided to personnel! partners! customers! and speci(ically to gate,eepers.
7.P.2 3olicy Disruption
Discover and e1amine the process and depth o( sel(-policing (rom personnel (or the disruption or
non-con(ormity o( physical security and sa(ety policy.
7.P.3 Threat Conditions
-a. &ap the ready responses o( security processes in reaction to increased threat condition levels
-i.e. green! yello'! orange! and red alerts. as per re+uirements determined in the 3osture
/evie'.
-b. Determine 'hich triggers are re+uired to increase threat levels and veri(y that they are met.
-c. &ap the ready responses o( security processes in reaction to decreased threat condition levels
as per re+uirements determined in the 3osture /evie'.
-d. Discover and e1amine the e1tent to 'hich a non-o((icial person provides misin(ormation
regarding threat levels in an authoritative manner to purposely raise or lo'er ready status.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1%? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.2@ Property (alidation
Tests to e1amine physical property available 'ithin the scope or provided by personnel 'hich may be
illegal or unethical.
7.0. #haring
Eeri(y the e1tent to 'hich personal assets or those o( the organi0ation have been (a,ed!
reproduced! or shared illegally and intentionally according to the re+uirements o( the 3osture
/evie' through sharing! lending! renting! or leasing services! personal libraries! and personal
caches or unintentionally through ignorance or negligence.
7.0.2 <lac, &ar,et
Eeri(y the e1tent to 'hich personal assets or those o( the organi0ation have been (a,ed or
reproduced and are being promoted! mar,eted! or sold bet'een personnel or by the
organi0ation.
7.0.3 #ales Channels
Eeri(y assets in auctions! (lea mar,ets! 'ant-ads! yard sales! s'ap meets! or property sales 'hich
provide contact in(ormation through channels originating 'ithin the scope.
7.0.8 #torage
-a. Eeri(y storage locations and small caches o( organi0ational assets are in the appropriate
location 'ithin the scope.
-b. Eeri(y storage locations and small caches o( organi0ational assets (or use or (or sale publicly or
to other members o( the organi0ation are not being deliberately hidden! hoarded! controlled!
or saved.
7.0.N /esource Abuse
-a. $numerate personal items 'hich consume po'er! (uel! (ood! 'ater! or other assets 'ithin the
re+uirements de(ined in the 3osture /evie'.
-b. $numerate personal items using channels 'hich are the property o( the organi0ation -i.e.
"nternet servers! *u,ebo1es! (a1 machines! etc...
-c. $numerate openly vie'able personal items 'hich symboli0e belie(s not 'ithin the re+uirements
de(ined in the 3osture /evie'.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1%@
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.22 Segregation !e#ie3
Tests (or appropriate separation o( private or personal in(ormation property (rom business in(ormation. ;i,e
a privacy revie'! it is the (ocal point o( the legal and ethical storage! transport! and control o( personnel!
partner! and customer private in(ormation property.
7.. 3rivacy Containment &apping
&ap storage locations o( private in(ormation property 'ithin the scope! 'hat in(ormation is stored!
ho' and 'here the in(ormation is stored! and ho' and 'here the property is discarded.
7..2 $vident "n(ormation
$numerate and map (rom the target documents and physical property 'ith unsecured personal
in(ormation as de(ined implicitly as private in regulations and policy o( the 3osture /evie' -i.e. (ull
names! race! se1! religion! vacation days! personal 'eb pages! published resumes! personal
a((iliations! directory in+uiries! ban, branch! electoral register! etc...
7..3 Disclosure
Eeri(y access to stores o( private in(ormation property o( personnel as determined in the 3osture
/evie'.
7..8 ;imitations
$1amine and document mobility alternatives accessible to people 'ith physical limitations 'ithin
that channel.
7..8 %((ensive &aterials
Eeri(y openly vie'able personal property does not (launt or o((end as determined o((ensive or
private in the 3osture /evie'.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
13> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.25 E,posure (erification
Tests (or uncovering in(ormation 'hich provides (or or leads to authenticated access or allo's (or access to
multiple locations 'ith the same authentication.
7.2. $1posure &apping
Discover and enumerate unsecured documents and items 'ith building in(ormation regarding the
organi0ation such as blueprints! logistics! schedules! ,eys! access to,ens! badges! uni(orms! or any
particular organi0ational assets 'hich provide deeper or broader access.
7.2.2 3ro(iling
-a. 3ro(ile and veri(y the structural de(inition o( the targets including material type! height!
thic,ness! and security or sa(ety properties.
-b. Discover and enumerate access control sensors! cameras! monitors! man-traps! cages! gates!
(ences! etc. (or type! technology! ma,er! materials! and security or sa(ety properties.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 131
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.26 Competiti#e "ntelligence Scouting
Tests (or scavenging property that can be analy0ed as business intelligence. 4hile competitive
intelligence as a (ield is related to mar,eting! the process here includes any (orm o( competitive
intelligence gathering! including but not limited to economic and industrial espionage.
7.3. <usiness @rinding
Discover and map storage locations o( business property 'ithin the scope! 'hat in(ormation is
stored! ho' and 'here the in(ormation is stored! and ho' and 'here the property is discarded.
7.3.2 <usiness $nvironment
Discover and enumerate documents and items 'ith business details such as personnel! pay rates!
alliances! partners! ma*or customers! vendors! distributors! investors! business relations! production!
development! product in(ormation! planning! stoc,s and trading! and any particular business
in(ormation or property determined implicitly as con(idential or non-compete (rom the 3osture
/evie'.
7.3.3 %rgani0ational $nvironment
Discover and enumerate documents and items 'ith organi0ational details such as processes!
hierarchy! (inancial reporting! investment opportunities! mergers! ac+uisitions! channel investments!
channel maintenance! internal social politics! personnel dissatis(action and turn-over rate! primary
vacation times! hirings! (irings! and any particular organi0ational property stated implicitly as
con(idential or non-compete (rom the 3osture /evie'.
7.3.8 %perational $nvironment
Discover and enumerate processes 'hich e1pose operational details such as pac,aging! shipping!
distribution! arrival and departure times o( employees! management! customers! methods o(
interaction! advertising and mar,eting plans! product development! product capacity! and any
particular operational property stated implicitly as con(idential or non-compete (rom the 3osture
/evie'.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
13% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.27 9uarantine (erification
Tests (or veri(ying the proper (ielding and containment o( people and processes 'ith aggressive or hostile intent
'ithin the scope.
7.8. Containment 3rocess "denti(ication
-a. "denti(y and e1amine physical +uarantine methods and processes 'ithin the scope (or
aggressive and hostile contacts such as chaotic or violent people! unscheduled sales people!
head-hunters! gri(ters! *ournalists! competitors! *ob see,ers! *ob candidates! and disruptive
people.
-b. "denti(y and e1amine physical +uarantine methods and process 'ithin the scope (or
managing dangerous and harm(ul items or substances! illegal substances! and illegally
removed company property.
-c. "denti(y and e1amine physical +uarantine methods and processes 'ithin the scope (or merely
suspicious behavior or items and substances o( suspect utility.
7.8.2 Containment ;evels
-a. Eeri(y the state o( containment location! length o( time! and process o( the +uarantine
method. $nsure that methods are 'ithin legal conte1t and boundaries as per the 3osture
/evie'.
-b. Eeri(y proper procedures are (ollo'ed (or a (ull loc,-do'n as per the re+uirements in the
3osture /evie' (or environmental threats! biological! chemical! or other contamination threats
and in cases o( 'or,place violence.
-c. Eeri(y proper procedures (or +uarantine recovery and return to the proper secure state
(ollo'ing a state o( loc,-do'n as per the re+uirements in the 3osture /evie'.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 133
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.2< Pri#ileges Audit
Tests (or gaining access credentials and privileges as supplied to other personnel 'ith the appropriate
permissions.
7.N. "denti(ication
$1amine and document the process (or obtaining identi(ication through legitimate! illegal -i.e. gra(t!
the(t! threats! etc.. and (raudulent -(orgery! misrepresentation! etc.. means.
7.N.2 Authori0ation
Eeri(y the use o( (raudulent authori0ation to gain privileges similar to that o( other personnel.
7.N.3 $scalation
Eeri(y and enumerate accesses to assets through the use o( privileges to gain higher privileges to
that o( gate,eepers.
7.N.8 #pecial Circumstances
Eeri(y gaining access privileges as re+uested in cases 'here age -speci(ically those regarded
legally as minors (or the region.! relationship -i.e. son! daughter! (ather! mother! etc.. se1! race!
custom5culture and religion are (actors 'hich may be granted special circumstances or
discriminated against in accordance to the 3osture /evie'.
7.N.N #ub*ugation
$numerate and test (or inade+uacies in access to assets not controlled by the source providing
the access -i.e. 3"Ns! "D photos! etc. selected by the actor! sign-ins 'ith identi(ication numbers
'ritten in by the actor! etc...
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
13- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.2= Sur#i#ability (alidation
Determining and measuring the resilience o( the barriers and guards 'ithin the scope to e1cessive or hostile
changes designed to cause operations (ailure.
7.C. /esilience
-a. $numerate and veri(y that the distraction! removal or +uieting o( gate'ay personnel 'ill not
allo' (or direct access to assets or operations.
-b. $numerate and veri(y that the disabling or destruction o( operational security measures or
controls 'ill not allo' (or direct access to assets or operations.
-c. Eeri(y that the isolation o( the scope (rom resources such as (uel! po'er! (ood! 'ater!
communications! etc. does not allo' (or direct access to assets or operations.
-d. Eeri(y that high alert threat conditions do not shut do'n or minimi0e operational security
measures or controls allo'ing (or direct access to assets or operations.
7.C.2 Continuity
-a. $numerate and veri(y conditions 'here access delays are properly addressed through bac,-
up personnel or an automated means (or timely access to services! processes! and operations.
-b. $numerate and veri(y that the distraction! removal or +uieting o( gate'ay personnel 'ill not
halt or deny timely access to services! processes! and operations.
-c. $numerate and veri(y that the disabling or destruction o( operational security measures or
controls 'ill not deny timely access to services! processes! and operations.
-d. Eeri(y that the isolation o( the scope (rom resources such as (uel! electrical po'er! (ood! 'ater!
communications! etc. 'ill not halt or deny access to services! processes! and operations.
-e. Eeri(y that the inability to remove 'aste! pollutants! or other contaminants (rom the scope 'ill
not halt or deny access to services! processes! and operations.
-(. Eeri(y that high alert threat conditions do not halt or deny access to services! processes! and
operations.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 139
OSSTMM 3 The Open Source Security Testing Methodology Manual
>.2; Alert and Log !e#ie3
A gap analysis bet'een activities per(ormed 'ith the test and the true depth o( those activities as recorded or
(rom third-party perceptions! both human and mechanical.
7.O. Alarm
Eeri(y and enumerate the use o( a locali0ed or scope-'ide 'arning system! log or message (or
each access gate'ay 'here a suspect situation is noted by personnel upon suspicion o(
circumvention attempts! (raudulent activity! trespass! or breach. $nsure that the sensors5systems
are installed to national! regional or international standards and regularly tested to cover all
accessible points.
7.O.2 #torage and /etrieval
Document and veri(y the permissions and e((icient access to alarm! log! and noti(ication storage
locations and property. Access to areas 'here sensitive in(ormation is processed or stored should
be controlled and restricted to authori0ed personnel onlyL an audit trail o( all access should be
securely maintained.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
13: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
The information to be found within the
wireless spectrum is not limited to product
specifications.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 13;
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter @ A 6ireless Security Testing
#pectrum security -#3$C#$C. is the security classi(ication 'hich includes electronics security -$;#$C.!
signals security -#"@#$C.! and emanations security -$&#$C.. $;#$C are the measures to deny unauthori0ed
access to in(ormation derived (rom the interception and analysis o( non-communications
electromagnetic radiations. #"@#$C are the measures to protect 'ireless communications (rom
unauthori0ed access and *amming. $&#$C are the measures to prevent the machine emanations that! i(
intercepted and analy0ed! 'ould disclose the in(ormation transmitted! received! handled! or other'ise
processed by in(ormation systems e+uipment. Testing this channel re+uires interaction 'ith barriers to
assets over $lectromagnetic -$&. and &icro'ave -&4. (re+uencies.
This channel covers the interaction o( the Analyst 'ithin pro1imity range o( the targets. 4hile some
services consider this simply as RscanningS! the true compliance ob*ectives o( security testing in this
channel are physical and logical barrier testing and gap measurement to the re+uired security standard
outlined in company policy! industry regulations! or regional legislation.
The Analyst 'ill be re+uired to have ade+uate protection (rom electromagnetic po'er sources and other
(orms o( radiation. Analysts 'ill also need to be prepared (or the possibility o( accidental bodily harm (rom
e1posure to electromagnetic and micro'ave radiation! especially that 'hich can permanently damage
hearing or sight. 3roper e+uipment should 'arn 'hen 'ithin range o( $lectromagnetic and &icro'ave
radiation (rom -2d< and greater. #peci(ic (re+uencies may adversely a((ect implanted medical devices!
cause vertigo! headaches! stomach cramps! diarrhea! and other discom(orts on both an emotional and
physical level.
Competent Analysts 'ill re+uire su((icient ,no'ledge o( $& and &4 radiation and critical thin,ing s,ills to
assure (actual data collection creates (actual results through correlation and analysis.
Considerations
3lease note the (ollo'ing considerations to assure a sa(e! high +uality test)
. "gnorantia legis neminem e1cusat) Analysts 'ho do not do proper posture revie' (or the scope as
'ell as the regions targeted (or business or interactions may not escape punishment (or violating
la's merely because they 'ere una'are o( the la'L that is! Analysts have presumed ,no'ledge
o( the la'. Analysts are considered pro(essionals in this sub*ect matter and! there(ore! the
assumption e1ists that even regarding 'hat may not be common ,no'ledge (or the average
person about a (oreign regionKs la's regarding $& and &4 communication systems! 'ill be ,no'n
to the Analyst.
2. "n personam) Testing must speci(ically target only #3$C#$C (rom personnel 'ho are under direct
legal contract 'ith the scope o'ner! computer systems on the property o( the scope o'ner! and
$& or &4 signals or emanations o( po'er level great enough to disrupt or harm 'ireless
communications 'ithin the scope. Analysts must ma,e e((orts to not invade upon a personKs
private li(e such as listening to or recording personal communications originating 'ithin the scope!
'here that private li(e has made e((orts to separate itsel( (rom the scope.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
13? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.2 Posture !e#ie3
"nitial studies o( the posture include the la's! ethics! policies! industry regulations! and political culture
'hich in(luence the security and privacy re+uirements (or the scope. This revie' (orms a matri1 to 'hich
testing should be mapped but not constrained.
P.. 3olicy
/evie' and document appropriate organi0ational policy regarding security! integrity! and privacy
responsibilities o( the scope. /evie' and document contracts and #ervice ;evel Agreements -#;As.
'ith service providers and other involved third parties.
P..2 ;egislation
/evie' and document appropriate regional and national legislation and industry regulations
regarding the security and privacy re+uirements o( the organi0ation in the scope as 'ell as that
'hich includes the appropriate customers! partners! organi0ational branches! or resellers outside
the scope.
P..3 Culture
/evie' and document appropriate organi0ational culture in the scope to'ards security and
privacy a'areness! re+uired and available personnel training! organi0ational hierarchy! help des,
use! and re+uirements (or reporting security issues.
P..8 Age
/evie' and document the age o( systems! so(t'are! and service applications re+uired (or
operations.
P..N 6ragile Arti(acts
/evie' and document any systems! so(t'are! and service applications 'hich re+uire special care
due to high use! instabilities! or a high rate o( change.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 13@
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.5 Logistics
3reparation o( the channel test environment needed to prevent (alse positives and (alse negatives 'hich
lead to inaccurate test results.
P.2. Communications $+uipment
Test (or e+uipment 'hich may transmit $lectromagnetic /adiation! such as C/Ts! ;CDs! printers!
modems! and cell phones! and 'hich may be used to recreate the data that is displayed on the
screen! printed! or transmitted! etc. $1ploiting this vulnerability is ,no'n as Ean $c, phrea,ing.
P.2.2 Communications
Test 'hich protocols are used 'ithin the scope and methods o( transmission.
P.2.3 Time
Test (or the time (rame o( e+uipment operation. 6or e1ample! is a 'ireless access point -A3.
available 285O or *ust during normal business hoursU
?.6 Acti#e 0etection (erification
Determination o( active and passive controls to detect intrusion to (ilter or deny test attempts must be
made prior to testing to mitigate the ris, o( creating (alse positives and negatives in the test result data as
'ell as changing the alarm status o( monitoring personnel or agents.
P.3. Channel &onitoring
Test 'hether controls are in place (or monitoring intrusion or signal tampering.
P.3.2 Channel &oderating
Test 'hether controls are in place to bloc, signals -*amming. or alert (or unauthori0ed activities.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1-> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.7 (isibility Audit
$numeration and veri(ication tests (or the visibility o( personnel 'ith 'hich interaction is possible via all
channels.
P.8. "nterception
;ocate Access Control! 3erimeter #ecurity! and Ability to "ntercept or "nter(ere 'ith 'ireless
channels.
P.8.2 3assive #ignal Detection
-a. Determine 'hich (re+uencies and signals can lea, into or out o( the target area using a
directional! high gain antenna and passive detection means such as (re+uency analysis.
-b. Create a heat map o( the scope sho'ing all sources o( the radiation and their radii and
strength.
-c. Test (or sources that interact 'ithout authori0ation.
-d. Collect in(ormation broadcast by these sources.
-e. &ap all (ound data to the emission limit values currently re+uired in the region (or all detected
radiation.
P.8.2 Active #ignal Detection
$1amine 'hich (re+uencies or electromagnetic signal broadcasts trigger responses such as that
(rom /6"D or other interactive 'ireless sources. -/adio 6re+uency "denti(ier tags are composed o(
an integrated circuit! 'hich is sometimes hal( the si0e o( a grain o( sand! and an antenna usually
a coil o( 'ires. "n(ormation is stored on the integrated circuit and transmitted via the antenna 'hen
probed by the right signal. The e1act (re+uencies used in /6"D systems may there(ore vary by
country or region..
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1-1
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.< Access (erification
Tests (or the enumeration o( access points to personnel 'ithin the scope. 4hile access to personnel
outside o( the scope is a real scenario and one o(ten used (or in(ormation property the(t! the Analyst may
be limited to scope-only interaction to protect the independent privacy rights o( the personnel in their
private li(e.
P.N. $valuate Administrative Access to 4ireless Devices
Determine i( access points are turned o(( during portions o( the day 'hen they 'ill not be in use.
P.N.2 $valuate Device Con(iguration
Test and document using directional and high-gain antennas that 'ireless devices are set to the
lo'est possible po'er setting to maintain su((icient operation that 'ill ,eep transmissions 'ithin the
secure boundaries o( the organi0ation.
P.N.3 $valuate Con(iguration! Authentication! and $ncryption o( 4ireless Net'or,s
Eeri(y that the access pointKs de(ault #ervice #et "denti(ier -##"D. has been changed.
P.N8 Authentication
$numerate and test (or inade+uacies in authentication and authori0ation methods.
P.N.N Access Control
$valuate access controls! perimeter security! and ability to intercept or inter(ere 'ith
communication! determining the level o( physical access controls to access points and devices
controlling them -,eyed loc,s! card badge readers! cameras! etc...
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1-% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.= Trust (erification
Tests (or trusts bet'een personnel 'ithin the scope 'here trust re(ers to access to in(ormation or physical
property 'ithout the need (or identi(ication or authentication.
P.C. &isrepresentation
Test and document the authentication-method o( the clients.
P.C.2 6raud
Test and document the depth o( re+uirements (or access to 'ireless devices 'ithin the scope 'ith
the use o( (raudulent credentials.
P.C.3 /esource Abuse
Test and document the depth o( re+uirements to send the property outside o( the scope to a
,no'n and trusted source or throughout the scope itsel( to other personnel 'ithout any
established! re+uired credentials.
P.C.8 <lind Trust
Test and document the connections that are made to a (alse or compromised receiver.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1-3
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.; Controls (erification
Tests to enumerate types o( loss controls used to protect in(ormation.
P.O. Non-repudiation
$numerate and test (or use or inade+uacies (rom daemons and systems to properly identi(y and log
access or interactions to property (or speci(ic evidence to challenge repudiation! and document the
depth o( the recorded interaction and the process o( identi(ication.
P.O.2 Con(identiality
$numerate and test (or use o( e+uipment to dampen $lectromagnetic transmission signals outside
o( the company and the controls in place (or securing or encrypting 'ireless transmissions.
P.O.3 3rivacy
Determine the level o( physical access controls to access points and devices controlling them
-,eyed loc,s! card badge readers! cameras! etc...
P.O.8 "ntegrity
Determine that data can only be accessed and modi(ied by those that are authori0ed and ensure
that ade+uate encryption is in use (or guaranteeing signing and con(identiality o(
communications.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1-- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.> Process (erification
Tests to e1amine the maintenance o( (unctional security a'areness o( personnel in established processes
and due diligence as de(ined in the 3osture /evie'.
P.7. <aseline
$1amine and document the baseline con(iguration to ensure the security stance is in-line 'ith the
security policy.
P.7.2 3roper #hielding
$1amine and determine that proper shielding is in place. 6or e1ample! determine that printers are
in specially shielded cabinets to bloc, $&T! panels or metallic paint are used to bloc, 'ireless
signals! etc.
P.7.3 Due Diligence
&ap and veri(y any gaps bet'een practice and re+uirements as determined in the 3osture
/evie' through all channels.
P.7.8 "ndemni(ication
Document and enumerate that targets and services 'hich are protected (rom abuse or
circumvention o( employee policy! are insured (or the(t or damages! or use liability and permission
disclaimers. Eeri(y the legality and appropriateness o( the language in the disclaimers.
?.? Configuration (erification
Tests to e1amine the ability to circumvent or disrupt (unctional security in assets.
P.P. Common Con(iguration $rrors
3er(orm brute (orce attac,s against access points to discern the strength o( pass'ords. Eeri(y that
pass'ords contain both upper and lo'er case letters! numbers! and special characters. Access
points 'hich use case insensitive pass'ords! ma,e it easier (or attac,ers to conduct a brute (orce
guessing attac, due to the smaller space o( possible pass'ords.
P.P.2 Con(iguration Controls
$1amine controls! including baseline con(iguration! to validate con(igurations are according to the
security policy.
P.P.3 $valuate and Test 4iring and $missions
Eeri(y that all 'iring (eeds into and out o( shielded rooms are made o( (iber! 'here possible.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1-9
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.2@ Property (alidation
Tests to e1amine in(ormation and physical property available 'ithin the scope! or provided by personnel!
'hich may be illegal or unethical.
P.0. #haring
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is shared bet'een personnel either intentionally through sharing processes and programs!
libraries! and personal caches or unintentionally through mismanagement o( licenses and
resources! or negligence.
P.0.2 /ogue 4ireless Transceivers
3er(orm a complete inventory o( all 'ireless devices. Eeri(y that the organi0ation has an ade+uate
security policy that addresses the use o( 'ireless technology.

?.22 Segregation !e#ie3
Tests (or appropriate separation o( private or personal in(ormation property (rom business in(ormation. ;i,e
a privacy revie'! it is the (ocal point o( the legal and ethical storage! transmission! and control o(
personnel! partner! and customer private in(ormation property.
P.. 3rivacy Containment &apping
&ap gate,eepers o( private in(ormation 'ithin the scope! 'hat in(ormation is stored! ho' and
'here the in(ormation is stored! and over 'hich channels the in(ormation is communicated.
P..3 Disclosure
$1amine and document types o( disclosures o( private in(ormation in 'ireless spectrum.
P..8 ;imitations
$1amine and document types o( gate'ays and channel alternatives accessible to people 'ith
physical limitations 'ithin that channel.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1-: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.25 E,posure (erification
Tests (or uncovering in(ormation 'hich provides (or or leads to authenticated access or allo's (or access to
multiple locations 'ith the same authentication.
P.2. $1posure &apping
$numerate and map personnel in(ormation regarding the organi0ation such as organi0ation charts!
,ey personnel titles! *ob descriptions! personal and 'or, telephone numbers! mobile phone
numbers! business cards! shared documents! resumes! organi0ational a((iliations! private and public
e-mail addresses! log-ins! log-in schemes! pass'ords! bac,-up methods! insurers! or any particular
organi0ational in(ormation stated implicitly as con(idential in regulations and policy.
P.2.2 3ro(iling
$1amine and veri(y 'ith the use o( a directional and high-gain antenna i( 'ireless signals 'ith
in(ormation regarding the device are e1tending out past the targetKs 'alls or property.
?.26 Competiti#e "ntelligence Scouting
Tests (or scavenging property that can be analy0ed as business intelligence. 4hile competitive
intelligence as a (ield is related to mar,eting! the process here includes any (orm o( competitive
intelligence gathering! including but not limited to economic and industrial espionage.
P.3. <usiness @rinding
&ap targets 'ithin the scope (rom active and passive analysis o( emanations) 'hat in(ormation is
stored! ho' and 'here the in(ormation is stored! and ho' the in(ormation is communicated.
P.3.2 <usiness $nvironment
$1plore and document business details such as alliances! partners! ma*or customers! vendors!
distributors! investors! business relations! production! development! product in(ormation! planning!
stoc,s and trading! and any particular business in(ormation or property stated implicitly as
con(idential in regulations and policy.
P.3.3 %rgani0ational $nvironment
$1amine and document types o( disclosures o( business property (rom gate,eepers on operations!
processes! hierarchy! (inancial reporting! investment opportunities! mergers! ac+uisitions! channel
investments! channel maintenance! internal social politics! personnel dissatis(action and turn-over
rate! primary vacation times! hirings! (irings! and any particular organi0ational property stated
implicitly as con(idential in regulations and policy.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1-;
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.27 9uarantine (erification
The determination and measurement o( e((ective use o( +uarantine (or all access to and 'ithin the target.
P.8. Containment 3rocess "denti(ication
"denti(y and e1amine +uarantine methods and processes at the target in all channels (or
aggressive and hostile contacts.
P.8.2 Containment ;evels
Eeri(y the state o( containment! length o( time! and all channels 'here interactions have
+uarantine methods. $nsure that methods are 'ithin legal conte1t and boundaries.
?.2< Pri#ileges Audit
Tests 'here credentials are supplied to the user and permission is granted (or testing 'ith those
credentials.
P.N. "denti(ication
$1amine and document the process (or obtaining identi(ication through both legitimate and (raudulent
means on all channels.
P.N.2 Authori0ation
Eeri(y the use o( (raudulent authori0ation on all channels to gain privileges similar to that o( other
personnel.
P.N.3 $scalation
Eeri(y and map access to in(ormation through the use o( privileges to gain higher privileges.
P.N.8 #ub*ugation
$numerate and test (or inade+uacies (rom all channels to use or enable loss controls not enabled
by de(ault.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1-? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
?.2= Sur#i#ability (alidation
Determining and measuring the resilience o( the target 'ithin the scope to e1cessive or hostile changes
designed to cause service (ailure.
P.C. Continuity
$numerate and test (or inade+uacies (rom target 'ith regard to access delays and service
response time through bac,-up personnel or automated means (or alternate access.
P.C.2 /esilience
&ap and document the process o( gate,eepers disconnecting channels due to breach or sa(ety
concerns as a gap analysis 'ith regulation and security policy.
?.2; Alert and Log !e#ie3
A gap analysis bet'een activities per(ormed 'ith the test and the true depth o( those activities as recorded or
(rom third-party perceptions both human and mechanical.
P.O. Alarm
Eeri(y and enumerate the use o( a locali0ed or scope-'ide 'arning system! log! or message (or
each access gate'ay over each channel 'here a suspect situation is noted by personnel upon
suspicion o( circumvention attempts! social engineering! or (raudulent activity.
P.O.2 #torage and /etrieval
Document and veri(y unprivileged access to alarm! log! and noti(ication storage locations and
property.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1-@
OSSTMM 3 The Open Source Security Testing Methodology Manual
n telecommunications people are as
much a part of the process as are the
machines. They are rarely mutually
eFclusive.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
19> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 1> A Telecommunications Security Testing
C%&#$C is a classi(ication (or the material security 'ithin the $;#$C realm 'hich is 'ithin the limits o(
telecommunications over 'ires.
This channel covers the interaction o( the Analyst 'ith the targets. 4hile some services consider this simply
as Rphrea,ingS! the true compliance ob*ective o( security testing in this channel is logical barrier testing
and gap measurement against the re+uired security standard as outlined in company policy! industry
regulations! or regional legislation.
The Analyst 'ill be re+uired to have multiple tools and methods (or the completion o( some tas,s to assure
that suspicion is not raised among personnel by continual and se+uential ringing o( phones and that tests
are not made invalid due to an early discovery or heightened paranoia. Analysts 'ill also need to be
prepared (or 'or,ing 'ith both digital and analog telecommunications e+uipment! sound (re+uency
analy0ers! and 'ithin in(ormation net'or,s providing regional content through local phone providers.
Competent Analysts 'ill re+uire an electronics bac,ground in both analog and digital telephony and
critical thin,ing s,ills to assure (actual data collection creates (actual results through correlation and
analysis.
Considerations
3lease note the (ollo'ing considerations to assure a sa(e! high +uality test)
. "gnorantia legis neminem e1cusat) Analysts 'ho do not do proper posture revie' (or the scope as
'ell as the regions targeted (or business or interactions may not escape punishment (or violating
la's merely because they 'ere una'are o( the la'L that is! persons have presumed ,no'ledge o(
the la'. Analysts are considered pro(essionals in this sub*ect matter and! there(ore! the assumption
e1ists that even 'hat may not be common ,no'ledge (or a normal person about a (oreign
regionKs la's regarding computer systems! 'ill be ,no'n by pro(essionals as they are a'are o( the
la's necessary to engage in their underta,ings.
2. 3roperty rights) Testing must speci(ically target only systems 'hich are under direct legal o'nership
o( the scope o'ner or computer systems on the property o( the scope o'ner. #uch property or
personal e((ects should remain personal and private unless it speci(ically involves the scope o'ner
through disparagement! (alse light! competitiveness! or reasons stated in personnel contract
agreements. Analysts must ma,e e((orts to not invade upon a personKs private li(e 'here that
private li(e has made e((orts to separate itsel( (rom the scope. Analysts 'ith a special agreement to
test systems 'hich are under direct contract but not o'ned! or are o'ned but not housed on the
o'nerKs legal property! must ta,e great caution to assure tests have minimum impact on other
systems outside the scope or contract.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 191
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.2 Posture !e#ie3
"nitial studies o( the posture include the la's! ethics! policies! industry regulations! and political culture
'hich in(luence the security and privacy re+uirements (or the scope. "n most cases! a target may also
have contracts 'ith providers and other third parties 'hich may need to be revie'ed and documented.
This revie' (orms a matri1 against 'hich testing should be mapped but not constrained! due to the
ubi+uity o( the channel endpoints. There(ore it is important to consider! as some legislation re+uires! the
target mar,et or end users o( this channel 'hich must also be added to the scope (or this module.
0.. 3olicy
-a. /evie' and document appropriate organi0ational policy regarding security! integrity! and
privacy re+uirements o( the scope. Eeri(y the limitations on telecommunications imposed by
the security policy.
-b. /evie' and document contracts and #ervice ;evel Agreements -#;As. 'ith service providers
and other involved third parties.
0..2 ;egislation
/evie' and document appropriate regional and national legislation regarding the security and
privacy re+uirements o( the organi0ation in the scope as 'ell as that 'hich includes the
appropriate customers! partners! organi0ational branches! or resellers outside the scope. 4here
applicable! pay special attention to privacy and data retention o( Call Detail /ecords! la's and
rulings governing interception or monitoring o( telecommunications! and provision o( critical
services such as $-P.
0..3 Culture
/evie' and document appropriate organi0ational culture in the scope to'ards security and
privacy a'areness! re+uired and available personnel training! organi0ational hierarchy! help des,
use! and re+uirements (or reporting security issues.
0..8 Age
/evie' and document the age o( systems! so(t'are! and service applications re+uired (or
operations.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
19% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
0..N 6ragile Arti(acts
/evie' and document any systems! so(t'are! and service applications 'hich re+uire special care
due to high use! instabilities! or a high rate o( change.
0..C Attac, Eectors
-a. 3<W testing
-b. Eoice mailbo1 testing
-c. 6AW and &odem surveying! polling! and testing
-d. /emote Access #ervices -/A#. testing
-e. <ac,up "#DN lines testing
-(. Eoice over "3 testing
-g. W.2N pac,et s'itched net'or, testing
2@.5 Logistics
3reparation o( the channel test environment needed to prevent (alse positives and (alse negatives 'hich
lead to inaccurate test results.
0.2. 6rame'or,
-a. Eeri(y the scope and the o'ner-s. o( the targets outlined (or the audit! along 'ith the carrier-s.
and other third parties managing the telecommunication lines and in(rastructure (or the
targets.
-b. Determine the property location and the o'ner o( the property housing the targets.
-c. #earch (or other targets (rom the same o'ner.
-d. 6ind and veri(y the paths o( telecommunication services 'hich interact outside o( target (or
the paths they (ollo' into and out o( the scope.
-e. Determine the physical location o( the targets.
-(. Test 'hich protocols are used 'ithin the scope -e1ample) 3#TN! "#DN! @#&! :&T#! #"3! 2.323! /T3!
W%T! D$CN$T! "3W! etc...
-g. Eeri(y and document the special limitations imposed by the contract 'ith client.
0.2.2 Net'or, Muality
-a. &easure the ma1imum and minimum connection speeds supported by targets.
-b. Determine and veri(y the appropriate connection speed! parity! /"N@ time! and other speci(ic
con(iguration parameters to be used (or scanning and testing.
-c. Eeri(y and document particular limitations imposed by the scope -e1ample) W.2N net'or,
congestion! W%T strict routes! access (ilters based on C;"D..
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 193
OSSTMM 3 The Open Source Security Testing Methodology Manual
0.2.3 Time and Additional Costs
-a. Test the time (rame o( e+uipment operation -e1ample) call redirect to ans'ering machine out
o( normal business hours..
-b. Determine and document the time settings -time0one! D#T! etc.. (or the targets.
-c. Assure the AnalystKs time cloc, is in sync 'ith the time o( the targets. Certain e+uipment li,e
(ragile arti(acts may have time settings that do not represent a valid timeL i( the AnalystKs time
cloc, is put in sync 'ith these it may have an impact on the result o( the test.
-d. Determine the additional (inancial costs involved in per(orming thorough tests (rom a remote
location -e1ample) scanning (or modems56AW! testing /emote Access #ervices not on toll-(ree
numbers! placing W.2N calls 'ithout reverse charge..
2@.6 Acti#e 0etection (erification
Determination o( active controls to detect intrusion and to (ilter or deny test attempts must be made prior
to testing to mitigate the ris, o( corrupting the test result data as 'ell as changing the alarm status o(
monitoring personnel or agents. "t may be necessary to coordinate these tests 'ith the appropriate
personnel 'ithin the scope.
0.3. &onitoring
-a. Test 'hether telecommunications are monitored by an authoritative party (or relaying
improper net'or, data! code in*ections! malicious content and improper conduct! and record
responses and response time.
-b. Test 'hether controls are in place (or monitoring (raudulent activities or services tampering!
and record responses and response time such as in periodic billing reconciliation using Call
Detail /ecords -CD/..
0.3.2 6iltering
-a. Test 'hether net'or,-level controls are in place (or bloc,ing unauthori0ed activities and
record responses and response time such as access (ilters based on Call ;ine "denti(ication
-C;"D.! Net'or, :ser Address -N:A.! or Closed :ser @roup -C:@..
-b. Test 'hether application-level controls are in place (or bloc,ing unauthori0ed activities and
record responses and response time.
0.3.3 Active Detection
-a. Eeri(y active responses to probes (rom systems and services.
-b. Eeri(y i( protection (rom brute (orce attac,s such as account loc,ing are in place.
-c. &ap any applications! systems! or net'or, segments 'ithin the scope 'hich produce logs!
alarms! or noti(ications.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
19- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.7 (isibility Audit
$numeration and inde1ing o( the targets in the scope through direct and indirect interaction 'ith or
bet'een live systems.
0.8. Net'or, #urveying
-a. Compile a map o( communication protocols in use 'ithin the scope.
-b. %utline the topology o( the telecommunication net'or,s 'ithin the scope.
0.8.2 $numeration
-a. 3<W testing) enumerate telephony systems 'ithin the scope.
-b. Eoice mailbo1 testing) (ind voice mailbo1es 'ithin the scope.
-c. 6AW testing) enumerate 6AW systems 'ithin the scope.
-d. &odem survey) (ind all systems 'ith listening and interactive modems 'ithin the scope.
-e. /emote Access #ervices testing) enumerate /A# systems 'ithin the scope.
-(. <ac,up "#DN lines testing) enumerate net'or, devices 'ith bac,up "#DN lines 'ithin the scope.
-g. Eoice over "3 testing) enumerate Eo"3 systems 'ithin the scope.
-h. W.2N pac,et s'itched net'or, testing) (ind live and reachable systems 'ithin the scope!
recording their response codes.
0.8.3 "denti(ication
-a. "denti(y %# types and versions in use on systems 'ithin the scope.
-b. "denti(y service types and versions in use on systems 'ithin the scope.
-c. "denti(y modem and 6AW types and operating programs.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 199
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.< Access (erification
Tests (or the measurement o( the breadth and depth o( interactive access points leading 'ithin the scope
and re+uired authentication.
0.N. Access 3rocess
-a. 3<W testing) (ind 3<W systems that are allo'ing remote administration or 'orld access to the
maintenance terminal! either via telephone dial-in or "3 net'or,.
-b. Eoice mailbo1 testing) (ind voice mailbo1es that are 'orld accessible.
-c. 6AW testing) (ind 6AW systems that are allo'ing remote administration or 'orld access to the
maintenance terminal.
-d. &odem survey) test and document the authentication protocols in use -e1ample) terminal!
3A3! C2A3! others..
-e. /emote Access #ervices testing) test and document the authentication protocols in use
-e1ample) terminal! 3A3! C2A3! others..
-(. <ac,up "#DN lines testing) test and document the authentication protocols in use -e1ample)
terminal! 3A3! C2A3! others..
-g. Eoice over "3 testing) veri(y the possibility o( per(orming toll (raud! call eavesdropping or
tracing! call hi*ac,ing! C;"D spoo(ing! and Denial o( #ervice! using attac,s targeting
converging net'or,s! Eo"3 net'or, elements! signaling and media transport protocols.
-h. W.2N pac,et s'itched net'or, testing) (ind systems that are allo'ing remote administration!
access to other services via speci(ic C:Ds! or reverse charge! veri(y ho' many Eirtual
Channels -ECs. and 3ermanent Eirtual Channels -3ECs. are in use and ho' they are
managed -C:@! sub-addresses mapping! incoming W.2N calls screening! (iltering based on
N:A! etc...
0.N.2 #ervices
-a. /e+uest ,no'n! common remote services.
-b. "denti(y the components o( services and their versions.
-c. Eeri(y service uptime to latest vulnerabilities and patch releases.
-d. 6or each identi(ied service! remotely test! and document con(iguration errors.
-e. 6or each identi(ied application! remotely test! and document programming errors.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
19: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
0.N.3 Authentication
-a. $numerate telecommunication resources re+uiring authentication and veri(y all acceptable
(orms o( privileges to interact or receive access.
-b. Document the authentication schemes in use! veri(y the process (or receiving authentication!
and test (or logic errors.
-c. Eeri(y the methods o( authori0ation and the identi(ication re+uired.
-d. $nsure administrative accounts do not have de(ault or easily guessed credentials.
-e. $nsure user accounts do not have de(ault or easily guessed credentials.
-(. Eeri(y and test protections against brute (orce and dictionary type attac,s.
-g. Eeri(y and test pass'ord comple1ity chec,s and voice mailbo1 3"N si0e! pass'ord aging! and
(re+uency o( change controls.
-h. Try R,no'nS credentials on all enumerated access points! to veri(y pass'ord re-usage controls.
-i. Eeri(y the (ormat used (or storage o( authentication credentials and document clear-te1t or
ob(uscated pass'ords and 'ea, encryption algorithms.
-*. Eeri(y the (ormat used (or transmission o( authentication credentials through the net'or, and
document clear-te1t or ob(uscated pass'ords and 'ea, encryption algorithms.
-,. Eeri(y that authentication in(ormation 'hether attempted! success(ul! or (ailed. is
appropriately logged.
2@.= Trust (erification
Tests (or trusts bet'een systems 'ithin the scope! 'here trust re(ers to access to in(ormation or physical
property 'ithout the need (or authentication credentials.
0.C. #poo(ing
-a. Test and document the access methods in use that do not re+uire submission o(
authentication credentials.
-b. Test and document the depth o( re+uirements (or interaction 'ith and access to property
'ithin the scope by means o( spoo(ing a trusted source -e1ample) C;"D and W.2N N:A
spoo(ing..
0.C.2 /esource Abuse
-a. Test and document the depth o( re+uirements to ta,e property outside o( the scope to a
,no'n and trusted source or throughout the scope itsel( 'ithout any established! re+uired
credentials.
-b. Test and document the property available (rom outside o( the scope due to in(ormation lea,s.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 19;
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.; Controls (erification
Tests to enumerate and veri(y the operational (unctionality o( sa(ety measures (or assets and services! de(ined
by means o( process-based -Class <. loss controls. The control o( alarm is veri(ied at the end o( the
methodology.
0.O. Non-repudiation
-a. $numerate and test (or use or inade+uacies (rom applications and systems to properly identi(y
and log access or interactions to property (or speci(ic evidence to challenge repudiation.
-b. Document the depth o( the recorded interaction and the process o( identi(ication.
-c. Eeri(y that all methods o( interaction are properly recorded 'ith proper identi(ication.
-d. "denti(y methods o( identi(ication 'hich de(eat repudiation.
0.O.2 Con(identiality
-a. $numerate all interactions 'ith services 'ithin the scope (or communications or assets
transported over the channel using secured lines! encryption! R+uietedS or RclosedS
interactions to protect the con(identiality o( the in(ormation property bet'een the involved
parties.
-b. Eeri(y the acceptable methods used (or con(identiality.
-c. Test the strength and design o( the encryption or ob(uscation methods.
-d. Eeri(y the outer limits o( communication 'hich can be protected via the applied method o(
con(identiality.
0.O.3 3rivacy
$numerate all interactions 'ith services 'ithin the scope (or communications or assets transported
over the channel using secured lines! encryption! R+uietedS or RclosedS interactions to protect the
privacy o( the interaction and the process o( providing assets only to those 'ithin the proper
security clearance (or that process! communication! or asset.
0.O.8 "ntegrity
$numerate and test (or inade+uacies o( integrity 'here using a documented process! signatures!
encryption! hash! or mar,ings to assure that the asset cannot be changed! s'itched! redirected!
or reversed 'ithout it being ,no'n to parties involved.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
19? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.> Process (erification
Tests to e1amine the maintenance o( (unctional security and e((ectiveness in established processes and
due diligence as de(ined in the 3osture /evie'.
0.7. <aseline
$1amine and document the baseline services to ensure the processes are in line 'ith the security
policy.
0.7.2 &aintenance
$1amine and document the timeliness! appropriateness! access to! and e1tent o( processes (or the
noti(ication and security a'areness o( personnel in regards to operational security! actual security!
and loss controls.
0.7.3 &isin(ormation
Determine the e1tent to 'hich personnel security noti(ications and security ne's can be
e1panded or altered 'ith misin(ormation.
0.7.8 Due Diligence
&ap and veri(y any gaps bet'een practice and re+uirements as determined in the 3osture
/evie' through all channels.
0.7.N "ndemni(ication
-a. Document and enumerate targets and services 'hich are protected (rom abuse or
circumvention o( employee policy! are insured (or the(t or damages! or use liability and
permission disclaimers.
-b. Eeri(y the legality and appropriateness o( the language in the disclaimers.
-c. Eeri(y the e((ect o( the disclaimers upon security or sa(ety measures.
-d. $1amine the language o( the insurance policy (or limitations on types o( damages or assets.
-e. Compare cultural access policy 'ith indemni(ication policy (or evidence o( 'ea,nesses.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 19@
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.? Configuration (erification
Tests to gather all in(ormation! technical and non-technical! on ho' assets are intended to 'or,! and to
e1amine the ability to circumvent or disrupt (unctional security in assets! e1ploiting improper con(iguration
o( access controls! loss controls! and applications.
0.P. Con(iguration Controls
-a. $1amine controls! including baseline con(iguration! to validate proper con(igurations o(
e+uipment! systems! and applications 'ithin the scope.
-b. $1amine controls to ensure con(igurations o( e+uipment! systems! and applications match the
intent o( the organi0ation and re(lect a business *usti(ication.
-c. $1amine Access Control ;ists -AC;s. con(igured on net'or,s! systems! services! and
applications 'ithin the scope! to ensure they match the intent o( the organi0ation and re(lect
a business *usti(ication.
0.P.2 Common Con(iguration $rrors
-a. 3<W testing) chec, (or unnecessary! insecure or unused services5(eatures and de(ault
credentials! veri(y the patch level o( 3<W systems to identi(y ,no'n vulnerabilities.
-b. Eoice mailbo1 testing) chec, (or unnecessary! insecure or unused services5(eatures and
de(ault credentials! veri(y the patch level o( voice mailbo1 systems to identi(y ,no'n
vulnerabilities.
-c. 6AW testing) chec, (or unnecessary! insecure or unused services5(eatures and de(ault
credentials! veri(y the patch level o( 6AW systems to identi(y ,no'n vulnerabilities.
-d. &odem survey) chec, (or unnecessary or unused ans'ering modems 'ithin the scope.
-e. /emote Access #ervices testing) chec, (or unnecessary! insecure or unused services5(eatures
and de(ault credentials! veri(y the patch level o( /A# servers to identi(y ,no'n vulnerabilities.
-(. <ac,up "#DN lines testing) chec, (or unnecessary! insecure or unused services and de(ault
credentials! veri(y the patch level o( net'or, e+uipment to identi(y ,no'n vulnerabilities.
-g. Eoice over "3 testing) chec, (or unnecessary! insecure or unused services5protocols and
de(ault credentials on all systems 'ithin the Eo"3 in(rastructure! and veri(y their patch level to
identi(y ,no'n vulnerabilities.
-h. %n W.2N pac,et s'itched net'or, testing chec, (or unnecessary! insecure or unused services
and de(ault credentials on all W.2N systems! and veri(y their patch level to identi(y ,no'n
vulnerabilities.
0.P.3 #ource Code Audit
$1amine the available source code o( applications 'here available to validate controls balance
operations.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1:> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.2@ Property (alidation
Tests to e1amine in(ormation and physical property available 'ithin the scope or provided by personnel
'hich may be illegal or unethical.
0.0.#haring
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is shared bet'een personnel either intentionally through sharing processes and programs!
libraries! and personal caches or unintentionally through mismanagement o( licenses and
resources! or negligence.
0.0.2<lac, &ar,et
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is promoted! mar,eted! or sold bet'een personnel or by the organi0ation.
0.0.3#ales Channels
Eeri(y public! out o( scope businesses! auctions! or property sales 'hich provide contact
in(ormation through channels originating 'ithin the scope.
0.0.8/ogue &odems
3er(orm a complete inventory o( all modems 'ithin the scope. Eeri(y that the organi0ation has
adopted an ade+uate security policy that addresses the use and provision o( modems.
2@.22 Segregation !e#ie3
Tests (or appropriate separation o( private or personal in(ormation (rom business in(ormation. ;i,e a
privacy revie'! it is the (ocal point o( the legal and ethical storage! transmission! and control o( personnel!
partner! and customer private in(ormation .
0..3rivacy Containment &apping
&ap gate,eepers o( private in(ormation 'ithin the scope! 'hat in(ormation is stored! ho' and
'here the in(ormation is stored! and over 'hich channels the in(ormation is communicated.
0..2Disclosure
$1amine and document types o( disclosures o( private in(ormation in communication services (rom
gate,eepers responsible (or this segregation according to policy and regulations as determined in
the 3osture /evie' and the basic human right to.
0..3;imitations
$1amine and document types o( gate'ays and channel alternatives 'ith gate'ays accessible to
people 'ith physical limitations 'ithin that channel such as in the TT9 service.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1:1
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.25 E,posure (erification
Tests (or uncovering public in(ormation 'hich describes indirect visibility o( targets 'ithin the scope or provides
(or or leads to authenticated access.
0.2.$1posure &apping
-a. "denti(y personal and business in(ormation such as personal and 'or, phone numbers! mobile
phone numbers! toll-(ree phone numbers! 6AW numbers! o'ners o( the telecommunication
lines! carriers! and organi0ational a((iliations! using all available means such as company
'ebsites! phone boo,s! on-line directory in(ormation! and telecommunication subscriberKs
databases.
-b. "denti(y other telecommunication lines such as W.2N! using both company 'ebsites and search
engines.
-c. "denti(y personal and business in(ormation such as organi0ation charts! ,ey personnel titles! *ob
descriptions! private and public e-mail addresses! log-ins -e1ample) W.2N 3#" mail in(ormation
lea,.! log-in schemes! pass'ords! bac,-up methods! insurers! or any particular organi0ational
in(ormation stated implicitly as con(idential in regulations and policy.
0.2.23ro(iling
3ro(ile and veri(y the organi0ation! its public telecommunication net'or,s! employees!
technologies! and business direction.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1:% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.26 Competiti#e "ntelligence Scouting
Tests (or scavenging property that can be analy0ed as business intelligence. 4hile competitive
intelligence as a (ield is related to mar,eting! the process here includes any (orm o( competitive
intelligence gathering! including but not limited to economic and industrial espionage.
0.3.<usiness @rinding
-a. &ap gate,eepers o( business property 'ithin the scope! 'hat in(ormation is stored! ho' and
'here the in(ormation is stored! and over 'hich channels the in(ormation is communicated.
-b. &easure the cost o( telecommunication in(rastructure based on e+uipment -e1ample)
phones! 3<W! modems! 6AW! etc...
-c. &easure the cost o( the support in(rastructure! based on carrier and maintenance costs!
including technical personnel.
-d. Eeri(y 'hat ,ind o( business is managed through the telecommunication in(rastructure
-e1ample) call center! customer care! help des,! etc...
-e. Eeri(y the amount o( tra((ic in a de(ined time range.
0.3.2<usiness $nvironment
-a. $1plore and document business details such as alliances! partners! ma*or customers! vendors!
distributors! investors! business relations! production! development! product in(ormation!
planning! stoc,s and trading! and any particular business in(ormation or property stated
implicitly as con(idential in regulations and policy.
-b. "denti(y telecommunication lines 'hich are part o( the business o( partners.
0.3.3%rgani0ational $nvironment
$1amine and document types o( disclosures o( business property (rom gate,eepers on operations!
processes! hierarchy! (inancial reporting! investment opportunities! mergers! ac+uisitions! channel
investments! channel maintenance! internal social politics! personnel dissatis(action and turn-over
rate! primary vacation times! hirings! (irings! and any particular organi0ational property stated
implicitly as con(idential in regulations and policy.
2@.27 9uarantine (erification
Tests (or veri(ying the proper (ielding and containment o( aggressive or hostile contacts at the gate'ay
points.
0.8.Containment 3rocess "denti(ication
"denti(y and e1amine +uarantine methods and processes at the target in all channels (or
annoying! aggressive! or hostile contacts such as telemar,eters! head hunters! and stal,ers.
0.8.2Containment ;evels
Eeri(y the state o( containment! length o( time! and all channels 'here interactions have
+uarantine methods. $nsure that methods are 'ithin legal conte1t and boundaries.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1:3
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.2< Pri#ileges Audit
Tests 'here credentials are supplied to the user and permission is granted (or testing 'ith those
credentials.
0.N."denti(ication
$1amine and document the process (or obtaining identi(ication through both legitimate and
(raudulent means on all channels.
0.N.2Authori0ation
-a. Eeri(y the use o( (raudulent authori0ation on all channels to gain privileges similar to that o(
other personnel.
-b. Test and document possible paths (or bypassing Access Control ;ists -AC;s. con(igured (or
net'or,s! systems! services! and applications 'ithin the scope.
0.N.3$scalation
Eeri(y and map access to in(ormation through the use o( privileges to gain higher privileges.
0.N.8#ub*ugation
$numerate and test (or inade+uacies (rom all channels to use or enable loss controls not enabled
by de(ault.
2@.2= Sur#i#ability (alidation
Determining and measuring the resilience o( the target 'ithin the scope to e1cessive or hostile changes
designed to cause service (ailure.
0.C.Continuity
-a. $numerate and test (or inade+uacies (rom target 'ith regard to access delays and service
response time through bac,-up personnel or automated means (or alternate access.
-b. $numerate and test (or inade+uacies (rom target 'ith regard to Muality o( #ervice issues and
per(ormance re+uirements o( telecommunication technologies.
0.C.2/esilience
&ap and document the process o( gate,eepers disconnecting channels due to breach or sa(ety
concerns as a gap analysis 'ith regulation and security policy.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1:- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
2@.2; Alert and Log !e#ie3
A gap analysis bet'een activities per(ormed 'ith the test and the true depth o( those activities as recorded or
(rom third-party perceptions! both human and mechanical.
0.O.Alarm
-a. Eeri(y and enumerate the use o( a locali0ed or scope-'ide 'arning system! log! or message
(or each access gate'ay over each channel 'here a suspect situation is elevated upon
suspicion o( intrusion attempts or (raudulent activity and determine clipping levels.
-b. /evie' outgoing and incoming call detail logs (or signs o( abuse or (raud.
-c. Test and document log management systems.
0.O.2#torage and /etrieval
-a. Document and veri(y the unprivileged access to alarm! log! and noti(ication storage locations
and property.
-b. Test and document logging bac,up policy and logging to multiple locations! to ensure that
audit trails cannot be tampered 'ith.
-c. Test and document log management systems.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1:9
OSSTMM 3 The Open Source Security Testing Methodology Manual
The 3 rules of data security tools areB 1.
tools donDt "now when they lie, %. tools are
only as smart as their designers, and 3.
tools can only wor" properly within the
confines of the environment they were
made for.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1:: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 11 A .ata 5etwor"s Security Testing
The tests (or the Data Net'or,s #ecurity -C%&#$C. channel re+uire interactions 'ith the e1isting data
communication net'or, operational sa(eguards used to control access to property.
This channel covers the involvement o( computer systems! primarily the operating net'or,s 'ithin the
target scope or (rame'or,. 4hile some organi0ations consider this simply as Rpenetration testingS! the
true compliance ob*ective o( security testing in this channel is system interaction and operational +uality
testing 'ith gap measurements to the re+uired security standard outlined in company policy! industry
regulations! or regional legislation.
During testing! end operators and arti(icial intelligence can recogni0e on-going attac,s both by process
and signature. 6or this reason! the Analyst 'ill be re+uired to have a su((icient variety o( methods to avoid
disclosure o( the tests or 'or, 'ith the operators to assure that 'here security (ails and 'here it succeeds
is brought to light. Tests 'hich (ocus only on the discovery o( ne' problems only leave room (or (i1es and
not designs (or (uture improvements.
Competent Analysts 'ill re+uire ade+uate net'or,ing ,no'ledge! diligent security testing s,ills! and
critical thin,ing s,ills to assure (actual data collection creates (actual results through correlation and
analysis.
Considerations
3lease note the (ollo'ing considerations to assure a sa(e! high +uality test)
. "gnorantia legis neminem e1cusat) Analysts 'ho do not do proper posture revie' (or the scope as
'ell as the regions targeted (or business or interactions may not escape punishment (or violating
la's merely because they 'ere una'are o( the la'L that is! persons have presumed ,no'ledge o(
the la'. Analysts are considered pro(essionals in this sub*ect matter and! there(ore! the assumption
e1ists that 'hat may not be common ,no'ledge (or a normal person about a (oreign regionKs
la's regarding computer systems! pro(essionals ma,e themselves a'are o( the la's necessary to
engage in that underta,ing.
2. 3roperty rights) Testing must speci(ically target only systems 'hich are under direct legal o'nership
'ith the scope o'ner and computer systems on the property o( the scope o'ner. Any personal
e((ect should remain personal and private unless it speci(ically involves the scope o'ner through
disparagement! (alse light! competitiveness! or reasons stated in personnel contract agreements.
Analysts must ma,e e((orts to not invade upon a personKs private li(e 'here that private li(e has
made e((orts to separate itsel( (rom the scope. Analysts 'ith special agreements to test systems
'hich are under direct contract but not o'ned or are o'ned but not housed at the o'nerKs legal
property must ta,e great caution to assure tests have minimum impact on other systems and
tertiary parties outside the scope or contract.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1:;
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.2 Posture !e#ie3
"nitial studies o( the posture include the la's! ethics! policies! industry regulations! and political culture
'hich in(luence the security and privacy re+uirements (or the scope. This revie' (orms a matri1 against
'hich testing should be mapped but not constrained due to the ubi+uity o( the channel endpoints.
There(ore! it is important to consider! as some legislation re+uires! the target mar,et or end users o( this
channel 'hich must also be added to the scope (or this module.
.. 3olicy
/evie' and document appropriate organi0ational policy regarding security! integrity! and privacy
re+uirements o( the scope. /evie' and document contracts and #ervice ;evel Agreements -#;As.
'ith service providers and other involved third parties.
..2 ;egislation and /egulations
/evie' and document appropriate regional and national legislation! and industry regulations
regarding the security and privacy re+uirements o( the organi0ation in the scope as 'ell as that
'hich includes the appropriate customers! partners! organi0ational branches! or resellers outside
the scope.
..3 Culture
/evie' and document appropriate organi0ational culture in the scope to'ards security and
privacy a'areness! re+uired and available personnel training! organi0ational hierarchy! help des,
use! and re+uirements (or reporting security issues.
..8 Age
/evie' and document the age o( systems! so(t'are! and service applications re+uired (or
operations.
..N 6ragile Arti(acts
/evie' and document any systems! so(t'are! and service applications 'hich re+uire special care
due to high use! instabilities! or a high rate o( change.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1:? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.5 Logistics
This is the preparation o( the channel test environment needed to prevent (alse positives and (alse
negatives 'hich lead to inaccurate test results.
.2. 6rame'or,
-a. Eeri(y the scope and the o'ner o( the targets outlined (or the audit.
-b. Determine the property location and the o'ner o( the property housing the targets.
-c. Eeri(y the o'ner o( the targets (rom net'or, registration in(ormation.
-d. Eeri(y the o'ner o( the target domains (rom domain registration in(ormation.
-e. Eeri(y the "#3-s. providing net'or, access or redundancy.
-(. #earch (or other "3 bloc,s and targets related to the same o'ner-s..
-g. #earch (or similar domain names or mistyped domain names 'hich can be con(used 'ith the
target.
-h. Eeri(y 'hich target domain names resolve to systems outside o( the o'nerKs control such as
caching devices.
-i. Eeri(y 'hich target "3 addresses trace bac, to locations di((erent (rom the o'nerKs location.
-*. Eeri(y that reverse name loo,-ups o( target system addresses correspond 'ith the scope and
the scope o'ner.
-,. 6ind and veri(y the paths o( net'or, services 'hich interact outside o( target (or the paths they
(ollo' into and out o( the scope.
-l. 3repare local name resolution to map domain names only to the speci(ic systems to be tested
and not any devices outside the target or target o'nership.
-m.:se reverse name loo,-ups as an additional in(ormation source to'ards determining the
e1istence o( all the machines in a net'or,.
.2.2 Net'or, Muality
-a. &easure the rate o( speed and pac,et loss to the scope (or a re+uested service in TC3! :D3!
and "C&3 both as a 'hole service re+uest and as a re+uest5response pair. /epeat each
re+uest in succession at least 00 times and record the average (or both 'hole service
re+uests and pac,et responses (or each o( the three protocols.
-b. Determine sending and receiving pac,et rates (or a total o( C averages -per protocol. as
re+uests per second per net'or, segment in the scope.
-c. /ecord pac,et loss percentages (or the determined pac,et sending and receiving rates.
.2.3 Time
-a. Eeri(y time0one! holidays! and 'or, schedules (or the various systems 'ithin the scope
including partners! resellers! and in(luential customers interacting 'ith the scope.
-b. "denti(y the Time To ;ive -TT;. distance to the gate'ay and the targets.
-c. Assure the AnalystKs cloc, is in sync 'ith the time o( the targets.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1:@
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.6 Acti#e 0etection (erification
Determination o( active and passive controls to detect intrusion to (ilter or deny test attempts must be
made prior to testing to mitigate the ris, o( corrupting the test result data as 'ell as changing the alarm
status o( monitoring personnel or agents. "t may be necessary to coordinate these tests 'ith the
appropriate persons 'ithin the scope.
.3. 6iltering
-a. Test 'hether "NC%&"N@ net'or, data or communications over 'eb! instant messaging! chat!
'eb-based (orums! or e-mail! are monitored or (iltered by an authoritative party (or relay o(
improper materials! code in*ections! malicious content! and improper conduct and record
responses and response time.
-b. Test 'hether %:T@%"N@ net'or, data or communications over 'eb! instant messaging! chat!
'eb-based (orums! or e-mail! are monitored or (iltered by an authoritative party (or relay o(
improper materials! code in*ections! malicious content! and improper conduct and record
responses and response time.
.3.2 Active Detection
-a. Eeri(y active responses to probes (rom systems and services. This could be human or machine
readable noti(ications! pac,et responses! silent alarm trips! or the li,e.
-b. &ap any applications! systems! or net'or, segments 'ithin the scope 'hich produce logs!
alarms! or noti(ications. This could include Net'or, or 2ost based "ntrusion Detection or
3revention #ystems! syslog! #ecurity "n(ormation &anagement tools -#"&s.! application logs!
and the li,e.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1;> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.7 (isibility Audit
$numeration and inde1ing o( the targets in the scope through direct and indirect interaction 'ith or
bet'een live systems.
.8. Net'or, #urveying
-a. "denti(y the perimeter o( the target net'or, segment-s. and the vector (rom 'hich they 'ill be
tested.
-b. :se net'or, sni((ing to identi(y emanating protocols (rom net'or, service responses or re+uests
'here applicable. 6or e1ample! Netbios! A/3! #A3! N6#! <@3! %#36! &3;#! /"3v2! etc.
-c. Muery all name servers and the name servers o( the "#3 or hosting provider! i( available! (or
corresponding A! AAAA! and 3T/ records as 'ell as ability to per(orm 0one trans(ers to
determine the e1istence o( all targets in the net'or, and any related redundancies! load
balancing! caching! pro1ying! and virtual hosting.
-d. Eeri(y broadcast re+uests and responses (rom all targets.
-e. Eeri(y and e1amine the use o( tra((ic and routing protocols (or all targets.
-(. Eeri(y "C&3 responses (or "C&3 types 0-2NN and "C&3 codes 0-2 (rom all targets.
-g. Eeri(y de(ault and li,ely #N&3 community names in use are according to practical
deployments o( all #N&3 versions.
-h. Eeri(y responses (rom targets to select ports 'ith TT; e1piration set to less than and 2 hops
(rom the targets. 6or e1ample)
TC3 7! 22! 23! 2N! 70! 883! 88N! 833
:D3 0! N3! 3P! C
"C&3 T00)C00! T3)C00! TN)C00! TO)C00
-i. Trace the route o( "C&3 pac,ets to all targets.
-*. Trace the route o( TC3 pac,ets to all targets (or ports ##2! #&T3! 2TT3! and 2TT3# ports.
-,. Trace the route o( :D3 pac,ets to all targets (or DN# and #N&3 ports.
-l. "denti(y TC3 "#N se+uence number predictability (or all targets.
-m.Eeri(y "3"D increments (rom responses (or all targets.
-n. Eeri(y the use o( ;oose #ource /outing to the target gate'ay and outer perimeter systems to
route pac,ets to all targets.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1;1
OSSTMM 3 The Open Source Security Testing Methodology Manual
.8.2 $numeration
-a. #earch ne'sgroups! (orums! "/C! "&! 323! Eo"3! and 'eb-based communications (or
connecting in(ormation o( the target to determine outgoing gate'ay systems and internal
addressing.
-b. $1amine e-mail headers! bounced mails! read receipts! mail (ailures! and mal'are re*ections
to determine outgoing gate'ay systems and internal addressing.
-c. $1amine target 'eb-based application source code and scripts to determine the e1istence o(
additional targets in the net'or,.
-d. $1amine service and application emanations. &anipulate and replay captured tra((ic to
invo,e ne' re+uests or responses! gain depth! or e1pose additional in(ormation. 6or e1ample!
#M;! Citri1! 2TT3! #A3! DN#! A/3! etc.
-e. #earch 'eb logs and intrusion logs (or system trails (rom the target net'or,.
-(. Eeri(y all responses (rom :D3 pac,et re+uests to ports 0-CNN3N.
-g. Eeri(y responses to :D3 pac,et re+uests 6/%& #%:/C$ ports 0! N3! 3P! and C to 0! N3! CP!
3! and C.
-h. Eeri(y responses to :D3 pac,et re+uests 'ith <AD C2$CB#:&# to all discovered ports and (or
0! N3! CP! 3! and C.
-i. Eeri(y service re+uest responses to common and contemporary :D3 remote access mal'are
ports.
-*. Eeri(y responses (rom TC3 #9N pac,et re+uests to ports 0-CNN3N.
-,. Eeri(y responses (rom TC3 service re+uests to ports 0! 2! 22! 23! 2N! N3! 70! and 883.
-l. Eeri(y responses (rom a TC3 ACB 'ith a #%:/C$ port o( 70 to ports 300-3N0! 000-00N0!
33N00-33NN0! and N0 random ports above 3N000.
-m.Eeri(y responses (rom TC3 #9N (ragments to ports 0! 2! 22! 23! 2N! N3! 70! and 883.
-n. Eeri(y responses (rom all combinations o( TC3 (lags to ports 0! 2! 22! 23! 2N! N3! 70! and 883.
-o. Eeri(y the use o( all targets 'ith 2TT3 or 2TT3# based E3Ns! pro1ies! and :/; redirectors to
redirect re+uests (or targets 'ithin the scope.
-p. Eeri(y the use o( all targets 'ith se+uential "3"Ds to enumerate systems 'ithin the net'or,.
-+. &ap and veri(y (or consistency visible systems and responding ports by TT;s.
.8.3 "denti(ication
"denti(y targetsK TT; response! system uptime! services! applications! application (aults! and
correlate this 'ith the responses (rom system and service (ingerprinting tools.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1;% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.< Access (erification
Tests (or the enumeration o( access points leading 'ithin the scope.
.N. Net'or,
-a. /e+uest ,no'n! common services 'hich utili0e :D3 (or connections (rom all addresses.
-b. /e+uest ,no'n! common E3N services including those 'hich utili0e "3#$C and "B$ (or
connections (rom all addresses.
-c. &anipulate net'or, service and routing to access past restrictions 'ithin the scope.
-d. /e+uest ,no'n! common Tro*an services 'hich utili0e :D3 (or connections (rom all addresses.
-e. /e+uest ,no'n! common Tro*an services 'hich utili0e "C&3 (or connections (rom all addresses.
-(. /e+uest ,no'n! common Tro*an services 'hich utili0e TC3 (or connections (rom all addresses
and un(iltered ports 'hich have sent no response to a TC3 #9N.
.N.2 #ervices
-a. /e+uest all service banners -(lags. (or discovered TC3 ports.
-b. Eeri(y service banners -(lags. through interactions 'ith the service comprising o( both valid and
invalid re+uests.
-c. &atch each open port to a daemon -service.! application -speci(ic code or product 'hich
uses the service.! and protocol -the means (or interacting 'ith that service or application..
-d. Eeri(y system uptime compared to the latest vulnerabilities and patch releases.
-e. Eeri(y the application to the system and the version.
-(. "denti(y the components o( the listening service.
-g. Eeri(y service uptime compared to the latest vulnerabilities and patch releases.
-h. Eeri(y service and application against TT; and %# (ingerprint results (or all addresses.
-i. Eeri(y 2TT3 and 2TT3# (or virtual hosting.
-*. Eeri(y Eo"3 services.
-,. &anipulate application and service re+uests outside o( standard boundaries to include
special characters or special terminology o( that service or application to gain access.
.N.3 Authentication
-a. $numerate accesses re+uiring authentication and document all privileges discovered 'hich
can be used to provide access.
-b. Eeri(y the method o( obtaining the proper Authori0ation (or the authentication.
-c. Eeri(y the method o( being properly "denti(ied (or being provided the authentication.
-d. Eeri(y the logic method o( authentication.
-e. Eeri(y the strength o( the authentication through pass'ord crac,ing and re-applying
discovered pass'ords to all access points re+uiring authentication.
-(. Eeri(y the process (or receiving authentication.
-g. Test (or logic errors in the application o( the authentication.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1;3
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.= Trust (erification
Tests (or trusts bet'een systems 'ithin the scope 'here trust re(ers to access to in(ormation or physical
property 'ithout the need (or identi(ication or authentication.
.C. #poo(ing
-a. Test measures to access property 'ithin the scope by spoo(ing your net'or, address as one o(
the trusted hosts.
-b. Eeri(y i( available caching mechanisms can be poisoned.
.C.2 3hishing
-a. Eeri(y that :/;s (or submissions and +ueries on the target are concise! 'ithin the same domain!
use only the 3%#T method! and use consistent branding.
-b. Eeri(y that target content images5records5data do not e1ist on sites outside o( the target to
create a duplicate o( the target.
-c. $1amine top level domain records (or domains similar to those identi(ied 'ithin the scope.
-d. Eeri(y that the target uses personali0ation in 'ebsites and mail 'hen interacting 'ith
authenticated users.
-e. Eeri(y the control and response o( the target to mail bounces 'here the 6/%& is spoo(ed in
the header (ield to be that o( the target domain.
.C.3 /esource Abuse
-a. Test the depth o( access to business or con(idential in(ormation available on 'eb servers
'ithout any established! re+uired credentials.
-b. Test i( in(ormation is sent to the outside o( the scope as padding to net'or, pac,ets such as
that 'hich has occurred previously as R$therlea,S.
-c. Eeri(y that continuity measures! speci(ically load balancing! are seamless outside the scope to
prevent users (rom using! re(erring! lin,ing! boo,mar,ing! or abusing *ust one o( the resources.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1;- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.; Controls (erification
Tests to enumerate and veri(y the operational (unctionality o( sa(ety measures (or assets and services.
.O. Non-repudiation
-a. $numerate and test (or use or inade+uacies o( daemons and systems to properly identi(y and
log access or interactions to property (or speci(ic evidence to challenge repudiation.
-b. Document the depth o( the recorded interaction and the process o( identi(ication.
-c. Eeri(y that all methods o( interactions are properly recorded 'ith proper identi(ication.
-d. "denti(y methods o( identi(ication 'hich de(eat repudiation.
.O.2 Con(identiality
-a. $numerate all interactions 'ith services 'ithin the scope (or communications or assets
transported over the channel using secured lines! encryption! R+uietedS or RclosedS
interactions to protect the con(identiality o( the in(ormation property bet'een the involved
parties.
-b. Eeri(y the acceptable methods used (or con(identiality.
-c. Test the strength and design o( the encryption or ob(uscation method.
-d. Eeri(y the outer limits o( communication 'hich can be protected via the applied methods o(
con(identiality.
.O.3 3rivacy
-a. $numerate services 'ithin the scope (or communications or assets transported using speci(ic!
individual signatures! personal identi(ication! R+uietedS or Rclosed roomS personal interactions
to protect the privacy o( the interaction and the process o( providing assets only to those
'ithin the proper security clearance (or that process! communication! or asset.
-b. Correlate in(ormation 'ith non-responsive TC3 and :D3 ports to determine i( availability is
dependent upon a private type o( contact or protocol.
.O.8 "ntegrity
$numerate and test (or inade+uacies o( integrity 'here using a documented process! signatures!
encryption! hash! or mar,ings to assure that the asset cannot be changed! redirected! or reversed
'ithout it being ,no'n to the parties involved.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1;9
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.> Process (erification
Tests to e1amine the maintenance o( (unctional security in established processes and due diligence as
de(ined in the 3osture /evie'.
.7. &aintenance
-a. $1amine and document the timeliness! appropriateness! access to! and e1tent o( processes (or
noti(ication and security response in regards to net'or, and security monitoring.
-b. Eeri(y the appropriateness and (unctionality o( incident response and (orensics capabilities (or
all types o( systems.
-c. Eeri(y the level o( incident or compromise 'hich the support channels can detect and the
length o( response time.
.7.2 &isin(ormation
Determine the e1tent to 'hich security noti(ications and alarms can be e1panded or altered 'ith
misin(ormation.
.7.3 Due Diligence
&ap and veri(y any gaps bet'een practice and re+uirements as determined in the 3osture
/evie' through all channels.
.7.8 "ndemni(ication
-a. Document and enumerate targets and services 'hich are protected (rom abuse or
circumvention o( employee policy! are insured (or the(t or damages! or use liability and
permission disclaimers.
-b. Eeri(y the legality and appropriateness o( the language in the disclaimers.
-c. Eeri(y the a((ect o( the disclaimers upon security or sa(ety measures.
-d. $1amine the language o( the insurance policy (or limitations on types o( damages or assets.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1;: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.? Configuration (erification
Tests to gather all in(ormation! technical and non-technical! on ho' assets are intended to 'or,! and to
e1amine the ability to circumvent or disrupt (unctional security in assets! e1ploiting improper con(iguration
o( access controls! loss controls! and applications.
.P. Con(iguration Controls
-a. $1amine controls to veri(y the con(igurations and baselines o( systems! e+uipment and
applications meet the intent o( the organi0ation and re(lect a business *usti(ication.
-b. $1amine Access Control ;ists -AC;s. and business roles con(igured on net'or,s! systems!
services! and applications 'ithin the scope to ensure they meet the intent o( the organi0ation
and re(lect a business *usti(ication.
.P.2 Common Con(iguration $rrors
-a. Eeri(y services available are not unnecessarily redundant and that they match the systemsK
intended business role.
-b. Eeri(y de(ault settings have been changed. #ome devices or applications ship 'ith a de(ault
or hidden administrative account. These accounts should be changed! or i( possible! disabled
or deleted and replaced 'ith a ne' administrative account.
-c. Eeri(y that Administration is done locally or 'ith controls to limit 'ho or 'hat can access the
remote administration inter(aces o( the e+uipment.
.P.3 ;imitations &apping
-a. Chec, (or unnecessary or unused services5(eatures available.
-b. Chec, (or de(ault credentials.
-c. "denti(y i( any ,no'n vulnerabilities are residing on the systems.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1;;
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.2@ Property (alidation
Tests to e1amine in(ormation and data available 'ithin the scope or provided by personnel 'hich may
be illegal or unethical.
.0.#haring
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is shared either intentionally through sharing processes and programs! libraries! and
personal caches or unintentionally through mismanagement o( licenses and resources! or
negligence.
.0.2<lac, &ar,et
Eeri(y the e1tent to 'hich individually licensed! private! (a,ed! reproduced! non-(ree! or non-open
property is promoted! mar,eted! or sold bet'een personnel or by the organi0ation.
.0.3#ales Channels
Eeri(y 'hether any public! out o( scope businesses! auctions! or property sales provide contact
in(ormation (rom targets 'ithin the scope.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1;? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.22 Segregation !e#ie3
Tests (or appropriate separation o( private or personal in(ormation property (rom business in(ormation. ;i,e
a privacy revie'! it is the (ocal point o( the legal and ethical storage! transmission! and control o(
personnel! partner! and customer private in(ormation property.
..3rivacy Containment &apping
&ap ,ey locations o( private in(ormation property 'ithin the scope! 'hat in(ormation is stored!
ho' and 'here the in(ormation is stored! and over 'hich channels the in(ormation is
communicated.
..2Disclosure
-a. $1amine and document types o( disclosures o( private in(ormation property (or segregation
according to policy and regulations as determined in the 3osture /evie'.
-b. Eeri(y that private in(ormation and con(idential intellectual property! such as documents!
service contracts! %#5#o(t'are ,eys! etc. are not available to anyone 'ithout proper
privileges.
..3;imitations
-a. Eeri(y that design considerations or channel alternatives e1ist (or people 'ith physical
limitations to interact 'ith the target.
-b. "denti(y any parts o( the in(rastructure designed to interact 'ith children legally identi(ied as
minors and veri(y 'hat and ho' identi(ying in(ormation is provided (rom that child.
..8Discrimination
Eeri(y in(ormation re+uested and privileges granted (rom gate,eepers in cases 'here age
-speci(ically minors.! se1! race! custom5culture and religion are (actors 'hich may be discriminated
against in accordance to the 3osture /evie'.
22.25 E,posure (erification
Tests (or uncovering in(ormation 'hich provides (or or leads to access or allo's (or access to multiple locations
'ith the same authentication.
.2.$1posure $numeration
-a. $numerate in(ormation regarding the organi0ation such as organi0ation charts! ,ey personnel
titles! *ob descriptions! personal and 'or, telephone numbers! mobile phone numbers! business
cards! shared documents! resumes! organi0ational a((iliations! private and public e-mail
addresses! log-ins! log-in schemes! pass'ords! bac,-up methods! insurers! or any particular
organi0ational in(ormation stated implicitly as con(idential in regulations and policy.
-b. $numerate system! service and application e1posures detailing the design! type! version! or
state on the targets or (rom resources outside the scope such as (rom postings or lea,s.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1;@
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.26 Competiti#e "ntelligence Scouting
Tests (or scavenging in(ormation that can be analy0ed as business intelligence. 4hile competitive
intelligence as a (ield is related to mar,eting! the process here includes any (orm o( competitive
intelligence gathering! including but not limited to economic and industrial espionage. <usiness
in(ormation includes but is not limited to business relationships li,e employees! partners! or resellers!
contacts! (inances! strategy! and plans.
.3.<usiness @rinding
$numerate and evaluate access points -gate'ays. to business property 'ithin the scope) 'hat
business in(ormation is stored! ho' it is stored! and 'here the in(ormation is stored.
.3.23ro(iling
-a. 3ro(ile employee s,ill re+uirement types! pay scales! channel and gate'ay in(ormation!
technologies! and organi0ational direction (rom sources outside the scope.
-b. 3ro(ile data net'or, set-ups and con(igurations (rom *ob databases and ne'spapers hiring
ads (or data net'or,ing positions 'ithin the organi0ation relating to hard'are and so(t'are
engineering or administration 'ithin the targetKs de(ault business language-s..
.3.3<usiness $nvironment
-a. $1plore and document (rom individual gate'ay personnel business details such as alliances!
partners! ma*or customers! vendors! distributors! investors! business relations! production!
development! product in(ormation! planning! stoc,s and trading! and any particular business
in(ormation or property stated implicitly as con(idential in regulations and policy.
-b. /evie' third party 'eb notes! annotations! and social boo,mar, site content made (or the
'eb presence o( the scope.
.3.8%rgani0ational $nvironment
$1amine and document types o( disclosures o( business property (rom gate,eepers on operations!
processes! hierarchy! (inancial reporting! investment opportunities! mergers! ac+uisitions! channel
investments! channel maintenance! internal social politics! personnel dissatis(action and turn-over
rate! primary vacation times! hirings! (irings! and any particular organi0ational property stated
implicitly as con(idential in regulations and policy.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1?> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.27 9uarantine (erification
The containment measures dictate the handling o( traversal! malicious programs and egress. The identi(ication
o( the security mechanisms and the response policy need to be targeted. "t may be necessary to re+uest (irst a
ne' test mail account or des,top system that the administrator can monitor. Tests (or veri(ying the proper
(ielding and containment o( aggressive or hostile contacts at the gate'ay points.
.8.Containment 3rocess "denti(ication
"denti(y and e1amine +uarantine methods (or aggressive and hostile contacts such as mal'are!
rogue access points! unauthori0ed storage devices! etc.
.8.2Containment ;evels
-a. &easure the minimum resources that need to be available to this subsystem in order (or it to
per(orm its tas,.
-b. Eeri(y any resources available to this subsystem that it does not need to per(orm its tas,s and
'hat resources are shielded (rom use by this subsystem.
-c. Eeri(y the detection measures present (or the detection o( attempted access to the shielded
resources.
-d. Eeri(y the (eatures o( the containment system.
-e. Eeri(y detection measures are present (or detection o( KunusualK access to the needed
resources
-(. &easure the response and process against encoded! pac,aged! condensed! renamed! or
mas+ueraded inputs.
-g. Eeri(y the state o( containment and length o( time (or +uarantine methods both into and out
o( the scope. $nsure the completeness and thoroughness o( the methods and that they are
'ithin legal conte1t and boundaries.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1?1
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.2< Pri#ileges Audit
Tests 'here credentials are supplied to the user and permission is granted (or testing 'ith those
credentials.
.N."denti(ication
$1amine and document the authori0ation process (or obtaining identi(ication (rom users through
both legitimate and (raudulent means on all channels.
.N.2Authori0ation
-a. $1amine and veri(y any means (or gaining (raudulent authori0ation to gain privileges similar to
that o( other personnel.
-b. $numerate the use o( de(ault accounts on targets.
-c. Test access to authenticated access points through the most appropriate and available
crac,ing techni+ues. 3ass'ord crac,ing via dictionary or brute-(orce may be limited by the
time (rame o( the audit and there(ore not a valid test o( the protection (rom that
authentication schema ho'ever any success(ul discoveries do attest to its 'ea,ness.
.N.3 $scalation
-a. Collect in(ormation on persons 'ith high privileges. ;oo, (or trusted roles or positions! access
gate'ays (or trusted persons! and any re+uired physical access media such as to,ens or smart
cards.
-b. Eeri(y the boundaries o( privileges on the target or across multiple targets and i( the means
e1ists to escalate those privileges.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1?% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
22.2= Sur#i#ability (alidation
Determining and measuring the resilience o( the targets 'ithin the scope to e1cessive or hostile changes
designed to cause (ailure or degradation o( service.
Denial o( #ervice -Do#. is a situation 'here a circumstance! either intentionally or accidentally! prevents the
system (rom (unctioning as intended. "n certain cases! the system may be (unctioning e1actly as designed
ho'ever it 'as never intended to handle the load! scope! or parameters being imposed upon it. #urvivability
tests must be closely monitored as the intent is to cause (ailure and this may be unacceptable to the targetKs
o'ner.
.C./esilience
-a. Eeri(y single points o( (ailure -cho,e points. in the in(rastructure 'here change or (ailure can
cause a service outage.
-b. Eeri(y the impact to target access 'hich a system or service (ailure 'ill cause.
-c. Eeri(y the privileges available (rom the (ailure-induced access.
-d. Eeri(y the operational (unctionality o( controls to prevent access or permissions above lo'est
possible privileges upon (ailure.
.C.2Continuity
-a. $numerate and test (or inade+uacies (rom all targets 'ith regard to access delays and service
response times through bac,-up systems or the s'itch to alternate channels.
-b. Eeri(y intruder loc,-out schemes cannot be used against valid users.
.C.3#a(ety
&ap and document the process o( gate,eepers shutting do'n target systems due to evacuation
or sa(ety concerns as a gap analysis 'ith regulation and security policy.
22.2; Alert and Log !e#ie3
A gap analysis bet'een activities per(ormed 'ith the test and the true depth o( those activities as recorded or
(rom third-party perceptions both human and mechanical.
.O. Alarm
Eeri(y and enumerate the use o( a locali0ed or scope-'ide 'arning system! log! or message (or
each access gate'ay over each channel 'here a suspect situation is noted by personnel upon
suspicion o( circumvention attempts! social engineering! or (raudulent activity.
.O.2 #torage and /etrieval
-a. Document and veri(y unprivileged access to alarm! log! and noti(ication storage locations and
property.
-b. Eeri(y the +uality and the length o( time o( the document storage to assure the data 'ill
maintain integrity on that storage medium (or the re+uired duration.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1?3
OSSTMM 3 The Open Source Security Testing Methodology Manual
,ompliance re*uirements which enforce
protection measures as a surrogate for
responsibility are also a substitute for
accountability.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1?- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 1% A ,ompliance
Compliance is alignment 'ith a set o( general policies! 'here the type o( compliance re+uired depends
upon the region and currently ruling government! industry and business types! and supporting legislation.
Compliance is compulsoryL ho'ever! as 'ith any other threat! a ris, assessment must be made 'hether or
not to invest in any type o( compliance. %(ten! compliance is not as blac, and 'hite as it appears to be.
The %##T&& recogni0es three types o( compliance)
1. 2egislative. Compliance 'ith legislation is in accordance to the region 'here the legislation can be
en(orced. The strength and commitment to the legislation comes (rom previously success(ul legal
arguments and appropriately set and *ust en(orcement measures. 6ailure to comply 'ith legislation may
lead to criminal charges. $1amples are #arbanes-%1ley! 2"3AA! and the various Data 3rotection and
3rivacy legislation.
%. ,ontractual. Compliance to contractual re+uirements are in accordance to the industry or 'ithin the
group that re+uires the contract and may ta,e action to en(orce compliance. 6ailure to comply 'ith
contractual re+uirements o(ten leads to dismissal (rom the group! a loss o( privileges! loss o( reputation!
civil charges! and in some cases 'here legislation e1ists to support the regulatory body! criminal charges.
An e1ample is the payment card industry data security standard -3C" D##. promoted and re+uired by
E"#A and &asterCard.
3. Standards based. Compliance to standards is in accordance 'ith the business or organi0ation 'here
the compliance to standards is en(orced as policy. 6ailure to comply 'ith standards o(ten leads to
dismissal (rom the organi0ation! a loss o( privileges! a loss o( reputation or brand trust! civil charges! and in
some cases 'here legislation e1ists to support the policy ma,ers! criminal charges. $1amples are the
%##T&&! "#% 2O005N! and "T";.
The %##T&& is developed 'ith concern (or ma*or legislation! contractual re+uirements! and standards
con(ormance. As not all compliance ob*ectives are created e+ually! the main (ocus o( the %##T&& is
security. Compliance measures that re+uire speci(ic products or services! commercial or other'ise! o(ten
through specially lobbied e((orts! may have good intentionsL ho'ever! may actually be a 'aste o(
resources or a lesser version o( security than is desired. That a compliance ob*ective can re+uire a speci(ic
product at all should be illegal itsel(.
As legislation and regulation may be audited either under the letter o( the la' or the spirit o( the la'!
depending upon the auditing body! proving proper and valid operational protection and controls such
that as can be proved by an %##T&& test may or may not be satis(actory. There(ore! in addition a
certi(ied %##T&& test complete 'ith the #TA/ should also be presented to the appropriate auditing
bodies.
The (ollo'ing list is only (or compliance 'hich has been veri(ied 'ith the %##T&& and does not limit the
actual scope o( regulatory and legislative bodies (or 'hich this standard may apply. "( you are able to
veri(y compliance measures not listed here according to the %##T&& or need a speci(ic compliance
measure veri(ied please send it to "#$C%& (or inclusion in this list. The compliance measure must be in
$nglish or sent to an "#$C%& partner 'hich e1ists 'ithin a region 'ith that local language.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1?9
OSSTMM 3 The Open Source Security Testing Methodology Manual
)egulations
Australia
- 3rivacy Act Amendments o( Australia-- Act No. P o( P77 as amended! prepared on 2 August
200 incorporating amendments up to Act No. NN o( 200. The 3rivacy Act P77 -the 3rivacy Act.
see,s to balance individual privacy 'ith the public interest in la' en(orcement and regulatory
ob*ectives o( government.
- National 3rivacy 3rinciple -N33. C provides an individual 'ith a right o( access to in(ormation held
about them by an organi0ation.
- National 3rivacy 3rinciple -N33. 8. provides that an organi0ation must ta,e reasonable steps to
protect the personal in(ormation it holds (rom misuse and loss and (rom unauthori0ed access!
modi(ication or disclosure.
- Common'ealth 3rivacy Act.
- Australian Communications Authority - http)55'''.aca.gov.au5
- Australian /adiation 3rotection and Nuclear #a(ety Agency
http)55'''.arpansa.gov.au5mph2.htm
Austria
- Austrian Data 3rotection Act 2000 -<undesgeset0 Zber den #chut0 personenbe0ogener Daten
-Datenschut0geset0 2000 - D#@ 2000..! speci(ically the re+uirements o( [8.
*elgium
- <elgisch #taatsblad N. 7P! >une 200N
Canada
- 3rivacy Act! P73.
- &unicipal 6reedom o( "n(ormation and 3rotection o( 3rivacy Act -&6"33A.! PP.
- MuebecKs Act /especting the 3rotection o( 3ersonal "n(ormation in the 3rivate #ector! PP3.
- 3ersonal "n(ormation 3rotection and $lectronic Documents Act -3"3$DA.! 2000.
- %ntarioKs <ill P7! 2002.
- 3ersonal "n(ormation 3rotection Act -3"3A.! provinces o( Alberta and <ritish Columbia! 2008.
- 3ersonal 2ealth "n(ormation 3rotection Act -32"3A.! 2008.
- /oyal #ociety o( Canada - http)55'''.rsc.ca5
Estonia
- &inister o( $conomic A((airs and Communications "n(ormation #ecurity 3olicy
1rance
- #ociFtF 6ran\aise de /adioprotection - http)55'''.s(rp.asso.(r5
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1?: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
)ermany
- Deutsche <undesdatenschut0geset0 -<D#@.-- Arti,el des @eset0es 0ur 6ortent'ic,lung der
Datenverarbeitung und des Datenschut0es (rom 20. December PP0! <@<l. " #. 2PN8! 2PNN! 0ulet0t
ge]ndert durch das @eset0 0ur Neuordnung des 3ost'esens und der Tele,ommuni,ation vom 8.
#eptember PP8! <@<l. " #. 232N.
- "T <aseline 3rotection &anual -"T-@rundschut0 Catalogues. "ssued by <undesamt (Zr #icherheit in
der "n(ormationstechni, -6ederal %((ice (or "n(ormation #ecurity -<#".. available at
http)55'''.bsi.de5gshb5english5menue.htm.
- @erman "T #ystems. #C.C7 -Testing the e((ectiveness o( the management system (or the handling o(
security incidents. and tests #C.CO -:se o( detection measures (or security incidents..
- <undesamt (Zr #trahlenschut0 - http)55'''.b(s.de5
"ndia
- The "n(ormation Technology Act! 2000.
"taly
- D.;gs. n. PC52003 - Codice in materia di prote0ione dei dati personali. 4here in a
Contract5Agreement the Client! o'ner o( the treatment o( the data! must assume any la'
responsibility as a sensitive data as medical! personal! *udicial o( $mployees or Customers but even
Dealers and 3artners. A tester must be 'illing to accept all the conse+uent responsibility 'hen
accepting the Non Disclosure Agreement especially about the derived ris, (rom the possible
,no'ledge o( sensitive data and the clause o( reservation to the time limit o( this special care
'hich could be inde(inite.
Malaysia
- Computer 6raud and Abuse Act.
- The Computer Crimes Act.
Me,ico
- ;ey 6ederal de Transparencia y Acceso a la "n(ormaci=n 3Gblica @ubernamental.
- ;ey de 3ropiedad "ndustrial -;3"..
- ;ey 6ederal de Derechos de Autor -;6DA. and its rules boo, -/;6DA..
- C=digo 3enal 6ederal y C=digo 6ederal de 3rocedimientos 3enales.
Netherlands
- Dutch Computer Crime Act "" o( #eptember ! 200C changing the Dutch Computer Crime Act o(
PP3
- Council o( $uropeKs Cybercrime Convention -CCC.! 23 November 200
- The rati(ication o( Treaty ^Convention on Cybercrime! <udapest! 23.W".200^ e((ective >une ! 200C
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1?;
OSSTMM 3 The Open Source Security Testing Methodology Manual
Singapore
- Computer &isuse Act.
- $-Commerce Code (or 3rotection o( 3ersonal "n(ormation and Communications o( Consumers o(
"nternet Commerce.
Spain
- #panish ;%3D ;ey %rganica de 3rotecci=n de Datos de CarJcter 3ersonal.
- ;##"C$ 352002 -;ey de #ervicios de la #ociedad de la "n(ormaci=n y el Correo $lectronico.! >uly !
2002.
- /D 85PPP -/eal Decreto de /egulaci=n de la 6irma $lectr=nica.! #eptember O! PPP.
- /eal Decreto O205200O! de 2 de diciembre! por el +ue se aprueba el /eglamento de desarrollo
de la ;ey %rgJnica N5PPP! de 3 de diciembre! de protecci=n de datos de carJcter personal.
S3iterland
- <undesver(assung -<E. vom 7. De0ember PP7! Arti,el O und 3.
- %bligationenrecht -%/. 2002 -#tand am . %,tober 2002.! Arti,el O0O! OC! OCb! OO! O2O(( und
32a.
- Datenschut0geset0 -D#@. vom P. >uni PP2 -#tand am 3. %,tober 2000..
- <undesamt (Zr Bommuni,ation -<AB%&.
- <undesamt (Zr :m'elt
Thailand
- Computer Crime ;a'.
- 3rivacy Data 3rotection ;a'.
Anited Bingdom
- :B Data 3rotection Act PP7.
- 6reedom o( "n(ormation Act 2000
- 2uman /ights Act 2000
- /egulation o( "nvestigatory 3o'ers Act 2000
- Access to 2ealth /ecords Act PP0
- 3roceeds o( Crime Act 2002
- &oney ;aundering /egulations 2003
- $lectronics Communications Act 2000
- $lectronics #ignature /egulations 2002
- 3rivacy and $lectronic Communications -$C Directive. /egulations 2003
- $lectronic Commerce -$C Directive. /egulations 2003
- Companies -Audit! "nvestigations and Community $nterprise. bill
- "T "n(ormation ;ibrary available at http)55'''.ogc.gov.u,5inde1.aspUidX22C issued by the <ritish
%((ice (or @overnment Commerce -%@C..
- <#" "#% OOPP-2000 -<# OOPP. - this manual (ully complies 'ith all o( the remote auditing and testing
re+uirements o( <#OOPP -and its "nternational e+uivalent "#% OOPP. (or in(ormation security
auditing.
- :B C$#@ C2$CB - speci(ically the C$#@ "T 2ealth C2$CB service.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1?? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Anited States of America
- A"C3A #A# O0 - veri(ication o( process control activities are applicable to the #ervice AuditorKs
/eport in the #tatement on Auditing #tandards -#A#. No. O0 (rom the American "nstitute o( Certi(ied
3ublic Accountants guidance (or "nternal Auditors.
- Clinger-Cohen Act.
- @overnment 3er(ormance and /esults Act.
- 6TC Act! N :.#.C. 8N-a.! #ection N-a..
- ChildrenKs %nline 3rivacy 3rotection Act -C%33A..
- Anticybers+uatting 3rotection Act -AC3A..
- 6ederal "n(ormation #ecurity &anagement Act.
- :.#. #arbanes-%1ley Act -#%W..
- Cali(ornia "ndividual 3rivacy #enate <ill #<37C.
- :#A @overnment "n(ormation #ecurity /e(orm Act o( 2000 section 3N38-a.-.-A..
- &"T/$ Common Eulnerabilities and $1posures - the rav #ecurity ;imitations described 'ithin this
manual comply to the CE$ descriptions (or more e((icient categori0ations
-http)55cve.mitre.org5about5terminology.html..
- DoD 6& 3-2! @uerrilla 4ar(are and #pecial 6orces %perations.
- 2ealth "nsurance 3ortability and Accountability Act o( PPC -2"3AA..
- %C/ 2"3AA 3rivacy TA C8.N02$.00! <usiness Associates _8N C6/ [[ C0.03! C8.N02-e.! C8.N8-e.`.
- %C/ 2"3AA 3rivacy TA C8.N8$.00! 2ealth-/elated Communications and &ar,eting _8N C6/ [[
C8.N0! C8.N8-e.`.
- %C/ 2"3AA 3rivacy TA C8.N02<.00! &inimum Necessary _8N C6/ [[ C8.N02-b.! C8.N8-d.`.
- %C/ 2"3AA 3rivacy TA C8.N0.002! 3ayment _8N C6/ C8.N0`.
- 2"3AA #tandards (or 3rivacy o( "ndividually "denti(iable 2ealth "n(ormation -8N C6/ parts C0 and
C8..
- 6DA) Computeri0ed #ystems used in Clinical Trails. $lectronic /ecordsL $lectronic #ignaturesL _2 C6/
3art `.
- :.#. @ramm-;each-<liley Act -@;<A..
- Computer #ecurity Act o( P7O -3.;. 00-23N.
- %((ice o( 3ersonnel &anagement -%3&. - /egulations "mplementing Training /e+uirements o(
Computer #ecurity Act o( P7O - N C6/ 3art P30! #ubpart C
- C%#% section O "n(ormation D Communication
- C%<it section 3 $ducate D Train :sers
- North American $lectric /eliability Council -N$/C. - #tandard 300 section 303.a.! 303.a.2!
303.a.3
- :.#. @eological #urvey &anual! C00.N - Automated "n(ormation #ystems #ecurity - @eneral
/e+uirements! section C A
- Department o( Eeterans A((airs - EA D"/$CT"E$ C20 section 2-d.-3.#ecurity A'areness D Training
- 6ederal "n(ormation #ecurity &anagement Act -6"#&A. [ 3N88-a.-8.! -b.-8.
- $1ecutive Directive Appendi1 """ to %&< Circular No. A-30
- #tate o( Eirginia "T/& #tandard PN- section E"
- 6ood and Drug Administration - http)55'''.(da.gov
- 6ederal Communications Commission - http)55'''.(cc.gov5
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1?@
OSSTMM 3 The Open Source Security Testing Methodology Manual
5ST 'ublications
- An "ntroduction to Computer #ecurity) The N"#T 2andboo,! 700-2.
- @uidelines on 6ire'alls and 6ire'all 3olicy! 700-8.
- "n(ormation Technology #ecurity Training /e+uirements) A /ole- and 3er(ormance-<ased &odel!
700-C.
- @uideline on Net'or, #ecurity Testing! 700-82.
- #ecurity #el(-Assessment @uide (or "n(ormation Technology #ystems.
- 3<W Eulnerability Analysis) 6inding 2oles in 9our 3<W <e(ore #omeone $lse Does! 700-28.
- /is, &anagement @uide (or "n(ormation Technology #ystems! 700-30.
- "ntrusion Detection #ystems! 700-3.
- <uilding an "n(ormation Technology #ecurity A'areness and Training 3rogram! 700-N0.
- N"#T #pecial 3ublication 700-N3! /ecommended #ecurity Controls (or 6ederal "n(ormation #ystems.
- #ecurity &etrics @uide (or "n(ormation Technology #ystems! 700-NN.
- @uide (or the #ecurity Certi(ication and Accreditation o( 6ederal "n(ormation #ystems! 700-3O.
- D/A6T) An "ntroductory /esource @uide (or "mplementing the 2ealth "nsurance 3ortability and
Accountability Act -2"3AA. #ecurity /ule! 700-CC.
- 6ederal 6inancial "nstitutions $1amination Council -66"$C.) $lectronic %perations! 2 C6/ 3art NNN.
- "nteragency @uidelines $stablishing #tandards (or #a(eguarding Customer "n(ormation! 2 C6/ NO0
Appendi1 <.
- "nteragency @uidelines $stablishing #tandards (or #a(ety and #oundness! 2 C6/ NO0! Appendi1 A.
- 3rivacy o( Consumer 6inancial "n(ormation! 2 C6/ NO3.
- 3rocedures (or &onitoring <an, #ecrecy Act Compliance! 2 C6/ NC3.OO.
- #ecurity 3rocedures :nder the <an, 3rotection Act! 2 C6/ NC7.
- #uspicious Activity /eports and %ther /eports and #tatements! 2 C6/ NC3.70.
4eneral
- #AC - this manual is compliant in design to the The "nstitute o( "nternal Auditors -""A. #ystems
Assurance and Control -#AC. model.
- "T"; - this manual is applicable to the operational security controls revie' and processes inter-
relations according to the "T "n(rastructure ;ibrary -"T";..
- 3C"-D## .2 -3ayment Card "ndustry - Data #ecurity #tandard.
- "#%5"$C 2O00)200N -"n(ormation security management systems - /e+uirements .
- "#%5"$C 2O002)200N -Code o( 3ractice (or "n(ormation #ecurity &anagement.
- ";% and "&% Code o( 3ractice #ecurity in 3orts! #ection 0
- <asel "" -"nternational.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1@> %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
Security awareness should be the
continuing practice of a s"ill and not the
continuous reminder of a threat.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org 1@1
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 13 < )eporting with the ST&)
The #TA/ is the #ecurity Test Audit /eport. "ts purpose is to serve as an e1ecutive summary o( precise
calculation stating the Attac, #ur(ace o( the targets tested 'ithin a particular scope. This precision is
made through the re+uirement o( speci(ically noting 'hat 'as N%T tested in addition to 'hat has been
tested in accordance to the %##T&&.
The provided template is to be (illed out completely -a copy o( this template by itsel( can be (ound at the
"#$C%& 'ebsite. and signed by the Analyst. "t is then provided either to "#$C%& 'ith the scope o'nerKs
e1plicit permission or directly to the scope o'ner along 'ith the (ull security test report. "t is not a substitute
(or a (ull report.
4hen providing the #TA/ to "#$C%& (or veri(ication! it is printed! signed by the veri(ication auditor! and
stamped by "#$C%&. A certi(icate is provided (or all tests 'hich state the scope has been tested and
veri(ied. There is no passing or (ailing since there is no particular Attac, #ur(ace rav value that e1ists (or all
scopes as the cut-o(( bet'een one that passes and one that (ails. 2o'ever! rav values (or a scope above
P0V 'ill be mar,ed by a stamp o( e1cellence.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
1@% %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org

Security Test &udit )eport
OSSTMM 3.> Security $erification ,ertification
%##T&&.%/@ - "#$C%&.%/@
)eport . .ate
2ead &uditor Test .ate .uration
Scope and ndeF $ectors
,hannels Test Type
" am responsible (or the in(ormation 'ithin this report and have personally veri(ied that all in(ormation herein is (actual and true.
S45&T#)+ ,OM'&5= ST&M'CS+&2
S+,OM ,ertification H S+,OM ,ertification H
O'+)&TO5&2 S+,#)T= $&2#+S ,O5T)O2S $&2#+S
Eisibility Authentication
Access "ndemni(ication
Trust /esilience
#ub*ugation
2MT&TO5S $&2#+S Continuity
Eulnerability Non-/epudiation
4ea,ness Con(identiality
Concern 3rivacy
$1posure "ntegrity
Anomaly Alarm
OpSec True ,ontrols
2imitations Security I
True 'rotection &ctual Security
'age 1 of @
O$+)$+6
This %pen #ource #ecurity Testing &ethodology &anual provides a methodology (or a thorough security test. A
security test is an accurate measurement o( security at an operational level! void o( assumptions and
anecdotal evidence. A proper methodology ma,es (or a valid security measurement that is consistent and
repeatable.
&BO#T S+,OM
"#$C%&! the creator and maintainer o( the %##T&&! is an independent! non-pro(it security research
organi0ation and certi(ication authority de(ined by the principles o( open collaboration and transparency.
)+2&T+. T+)MS &5. .+35TO5S
This report may re(er to 'ords and terms that may be construed 'ith other intents or meanings. This is especially
true 'ithin international translations. This report attempts to use standard terms and de(initions as (ound in the
%##T&& 3 vocabulary! 'hich has been based on NC#C-T@-008 -Teal @reen <oo,. (rom the :# Department o(
De(ense 'here applicable.
'#)'OS+
The primary purpose o( this Audit /eport is to provide a standard reporting scheme based on a scienti(ic
methodology (or the accurate characteri0ation o( security through e1amination and correlation in a consistent
and reliable 'ay. The secondary purpose is to provide guidelines 'hich 'hen (ollo'ed 'ill allo' the auditor to
provide a certi(ied %##T&& audit.
')O,+SS
This Audit /eport must accompany the (ull security test report document that provides evidence o( the test and
the results as de(ined in the statement o( 'or, bet'een the testing organi0ation and the client.
$&2.T=
6or this %##T&& Audit /eport to be valid! it must be (illed out clearly! properly! and completely. The %##T&&
Audit /eport must be signed by the lead or responsible tester or analyst and accompany include the stamp o(
the company 'hich holds the contract or sub-contract o( the test. This audit report must sho' under
C%&3;$T"%N #TAT:# 'hich Channel and the associated &odules and Tas,s have been tested to completion!
not tested to completion! and 'hich tests 'ere not applicable and 'hy. A report 'hich documents that only
speci(ic parts o( the Channel test have been completed due to time constraints! pro*ect problems! or customer
re(usal may still be recogni0ed as an o((icial %##T&& audit i( accompanied by this report clearly sho'ing the
de(iciencies and the reasons (or those de(iciencies.
,+)T3,&TO5
%##T&& certi(ication is the assurance o( an organi0ationKs security according to the thorough tests 'ithin the
%##T&& standard and is available per vector and channel (or organi0ations or parts o( organi0ations that
maintain vigilance over their rav levels and have them validated yearly (rom an independent third-party
auditor. Ealidation o( security tests or +uarterly metrics is sub*ect to the "#$C%& validation re+uirements to
assure consistency and integrity.
'age % of @
1. 'OST#)+ )+$+6
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
. "denti(ied business ob*ectives and mar,ets.
.2 "denti(ied legislation and regulations
applicable to the targets in the scope.
.3 "denti(ied business policies.
.8 "denti(ied business and industry ethics
policies.
.N "denti(ied operation cultures and norms.
.C "denti(ied operation times and (lo's
applicable to the targets in the scope.
.O "denti(ied all necessary Channels (or this
scope.
.7 "denti(ied all Eectors (or this scope.
%. 2O4ST,S
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
2. Applied testing sa(ety measures.
2.2 Determined and accounted (or test
instabilities.
2.3 Determined and accounted (or do'ntime
in scope.
2.8 Determined and accounted (or test pace
according to the test environment and the
security presence.
3. &,T$+ .+T+,TO5 $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
3. Determined and accounted (or
inter(erences.
3.2 Tested 'ith both inter(erences active and
inactive.
3.3 Determined restrictions imposed on tests.
3.8 Eeri(ied detection rules and predictability.
-. $SB2T= &#.T
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
8. Determined targets through all
enumeration tas,s.
8.2 Determined ne' targets by researching
,no'n targets.
'age 3 of @
9. &,,+SS $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
N. Eeri(ied interactions 'ith access points to
all targets in the scope.
N.2 Determined type o( interaction (or all
access points.
N.3 Determined source o( interaction de(ined
as a service or process.
N.8 Eeri(ied depth o( access.
N.N Eeri(ied ,no'n security limitations o(
discovered access points.
N.C #earched (or novel circumvention
techni+ues and security limitations o(
discovered access points.
:. T)#ST $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
C. Determined interactions that rely on other
interactions to complete the test
interaction according to the tas,s.
C.2 Determined targets 'ith trust relationships
to other targets in the scope to complete
interactions.
C.3 Determined targets 'ith trust relationships
to other targets outside the scope to
complete interactions.
C.8 Eeri(ied ,no'n security limitations o(
discovered trusts bet'een the trusts.
C.N Eeri(ied ,no'n security limitations o(
discovered trusts bet'een targets in the
scope and the trusted interactions.
C.C #earched (or novel circumvention
techni+ues and security limitations o(
discovered trusts.
'age - of @
;. ,O5T)O2S $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
O. Eeri(ied controls (or Non-/epudiation
(unctioning according to all tas,s.
O.2 Eeri(ied controls (or Con(identiality
(unctioning according to all tas,s.
O.3 Eeri(ied controls (or 3rivacy (unctioning
according to all tas,s.
O.8 Eeri(ied controls (or "ntegrity (unctioning
according to all tas,s.
O.N Eeri(ied controls (or Alarm (unctioning
according to all tas,s.
O.C Eeri(ied ,no'n security limitations o( all
controls Class < categories.
O.O #earched (or novel circumvention
techni+ues and security limitations o( all
controls Class < categories.
?. ')O,+SS $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
7. Determined all processes controlling the
action o( interactivity 'ith each access.
7.2 Eeri(ied the interaction operates 'ithin the
con(ines o( the determined process.
7.3 Eeri(ied the interaction operates 'ithin the
con(ines o( the security policy (or such
interactions.
7.8 Determined the gap bet'een the
operations o( interactions and the
re+uirements o( posture (rom the 3osture
/evie'.
7.N Eeri(ied ,no'n security limitations o(
discovered processes.
7.C #earched (or novel circumvention
techni+ues and security limitations o(
discovered processes.
'age 9 of @
@. ,O534#)&TO5 &5. T)&554 $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
P. Eeri(ied con(iguration5training re+uirements
according to the posture in the 3osture
/evie'.
P.2 Eeri(ied the application o( appropriate
security mechanisms as de(ined in the
3osture /evie'.
P.3 Eeri(ied the (unctionality and security
limitations 'ithin the con(igurations5training
(or the targets in the scope.
P.8 #earched (or novel circumvention
techni+ues and security limitations 'ithin
con(igurations5training.
1>. ')O'+)T= $&2.&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
0. Determined the amount and type o(
unlicensed intellectual property distributed
'ithin the scope.
0.2 Eeri(ied the amount and type o( unlicensed
intellectual property available (or
sale5trade 'ith the seller originating 'ithin
the scope.
'age : of @
11. S+4)+4&TO5 )+$+6
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
. Determined the amount and location o(
private in(ormation as de(ined in the
3osture /evie' available through the
targets.
.2 Determined the type o( private in(ormation
as de(ined in the 3osture /evie' available
'ithin the scope.
.3 Eeri(ied the relationship bet'een publicly
accessible in(ormation outside the target
detailing private or con(idential in(ormation
de(ined in the 3osture /evie' and the
scope.
.8 Eeri(ied the accessibility o( public accesses
'ithin the target to people 'ith disabilities.
1%. +J'OS#)+ $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
2. #earched (or available targets through
publicly available sources outside o( the
scope.
2.2 #earched (or available organi0ational
assets as de(ined in the 3osture /evie'
through publicly available sources outside
o( the scope.
2.3 Determined access! visibility! trust! and
controls in(ormation available publicly
'ithin the targets.
2.8 Determined a pro(ile o( the organi0ationKs
channel in(rastructure (or all channels
tested through publicly available
in(ormation 'ithin the targets.
2.N Determined a pro(ile o( the organi0ationKs
channel in(rastructure (or all channels
tested through publicly available
in(ormation outside the scope.
'age ; of @
13. ,OM'+TT$+ 5T+224+5,+ S,O#T54
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
3. Determined the business environment o(
partners! suppliers! 'or,ers! and mar,et
through publicly available in(ormation on
targets 'ithin the scope.
3.2 Determined the business environment o(
partners! vendors! distributors! suppliers!
'or,ers! and mar,et through publicly
available in(ormation outside the scope.
3.3 Determined the organi0ational
environment through publicly available
in(ormation on targets 'ithin the scope.
3.8 Determined the organi0ational
environment through publicly available
in(ormation outside the scope.
1-. !#&)&5T5+ $+)3,&TO5
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
8. Eeri(ied +uarantine methods (or
interactions to the targets in the scope.
8.2 Eeri(ied +uarantine methods (or
interactions (rom the targets to other
targets outside the scope.
8.3 Eeri(ied length o( time o( +uarantine.
8.8 Eeri(ied +uarantine process (rom receive
to release.
8.N Eeri(ied ,no'n security limitations o(
discovered +uarantines.
8.C #earched (or novel circumvention
techni+ues and security limitations o(
discovered +uarantines.
'age ? of @
19. ')$2+4+S &#.T
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
N. Eeri(ied the means o( legitimately
obtaining privileges (or all authenticated
interactions.
N.2 Eeri(ied the use o( (raudulent
identi(ication to obtain privileges.
N.3 Eeri(ied the means o( circumventing
authentication re+uirements.
N.8 Eeri(ied the means o( ta,ing non-public
authentication privileges.
N.N Eeri(ied the means hi*ac,ing other
authentication privileges.
N.C Eeri(ied ,no'n security limitations o(
discovered authentication mechanisms
to escalate privileges.
N.O #earched (or novel circumvention
techni+ues and security limitations o(
discovered authentication mechanisms
to escalate privileges.
N.7 Determined depth o( all discovered
authentication privileges.
N.P Determined re-usability o( all discovered
authentication privileges on the
authentication mechanisms on all targets.
N.0 Eeri(ied re+uirements to'ards obtaining
authentication privileges (or
discriminatory practices according to the
3osture /evie'.
N. Eeri(ied means to'ards obtaining
authentication privileges (or
discriminatory practices (or people 'ith
disabilities.
'age @ of @
1:. S#)$$&B2T= $&2.&TO5 &5. S+)$,+ ,O5T5#T=
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
C. Determined measures applicable to
disrupt or stop service continuity to and
(rom the targets.
C.2 Eeri(ied continuity processes and sa(ety
mechanisms active (or the targets.
C.3 Eeri(ied ,no'n security limitations o(
discovered sa(ety and service continuity
processes and mechanisms.
C.8 #earched (or novel circumvention
techni+ues and security limitations o(
discovered sa(ety and service continuity
processes and mechanisms.
1;. +5. S#)$+=, &2+)T &5. 2O4 )+$+6
T&S7 ,OMM+5TS ,OM'2+TO5 ST&T#S
O. Eeri(ied methods (or recording and
alerting interactions to the targets in the
scope.
O.2 Eeri(ied methods (or recording and
alerting interactions (rom the targets to
other targets outside the scope.
O.3 Eeri(ied speed o( recording and alerting.
O.8 Eeri(ied persistence o( recording and
alerting.
O.N Eeri(ied integrity o( recording and alerting.
O.C Eeri(ied distribution process o( recording
and alerting.
O.O Eeri(ied ,no'n security limitations o(
discovered recording and alerting
methods.
O.7 #earched (or novel circumvention
techni+ues and security limitations o(
discovered recording and alerting
methods.
OSSTMM 3 The Open Source Security Testing Methodology Manual
The more you move away from the prison
concept of security, the more you re*uire
the cooperation and good intentions from
the people you are securing.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %>3
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 1- < 6hat =ou 4et
4hat 'e 'ill get (rom utili0ing %##T&& is really *ust about having a deep understanding o( the
interconnectedness o( things. The people! processes! systems! and so(t'are all have some type o(
relationship. This interconnectedness re+uires interactions. #ome interactions are passive and some are
not. #ome interactions are symbiotic 'hile others are parasitic. #ome interactions are controlled by one
side o( the relationship 'hile others are controlled by both. Then some controls are (la'ed or super(luous!
'hich is harm(ul to at least one side o( the relationship! i( not both. %ther controls balance per(ectly 'ith
the interactions. 4hatever becomes o( the interconnectedness! ho'ever the interactions occur! ho'ever
they are controlled! they are the operations that ma,e survival possible. 4hen 'e test operations 'e get
the big picture o( our relationships. 4e get to see the interconnectedness o( the operations in (ine detail.
4e get to map out ho' 'e! our businesses! and our operations 'ill survive and even thrive.
:n(ortunately! ho' 'e interact is *ust based on a collection o( biases 'e accumulate during li(e! 'hich
are sub*ected to the emotional or bio-chemical state 'e are under 'hen 'e have them. These are our
shortcuts. Due to the incredible number o( decisions 'e must ma,e through-out all o( our interactions 'e
use a mental cheat-sheet to compare similar interactions rather than calculate each situation
independently. 4e are! a(ter all! only human. &ost o(ten though our opinions are limited and restricted to
a small scope 'e ,no' as Rour little 'orldS. 4e apply them every'here because they ma,e li(e easier.
<ut 'hen 'e ta,e them 'ith us and try to adhere them to larger! di((erent! more complicated series and
types o( interactions! 'e 'ill li,ely ma,e mista,es. 4hat may ma,e per(ect sense to us based on our
e1periences may not ma,e any sense at all outside o( Rour little 'orldS. #o 'hat 'e need is a better! less
biased 'ay o( loo,ing at the bigger! more dynamic! less personal! 'orld beyond ourselves.
6urthermore! our little 'orld is something 'e ta,e around 'ith us. 4hen 'e are outside! our little 'orld is
outside 'ith us. 4e interact in the space on the assumptions and pre*udices 'e ,no' and carry. 4hen
'e go inside! 'e ta,e our little 'orld inside 'ith us. This means 'e bring our 'ays o( doing things and ne'
interactions into a ne' environment. And it has al'ays been this 'ay. There is no perimeter. There is no us
and them. "t is each individual interacting and interconnecting 'ith everyone and everythingL each
individual 'ith their o'n little 'orld o( issues and preconceptions impacting on the rest! 'hile at the same
time being impacted by others. This means 'e need a 'ay to see more than *ust the bigger 'orldL 'e
also need a 'ay to see into each individualKs o'n little 'orlds too.
%(ten the di((iculty in creating security is blamed on the sophistication and the persistence o( the attac,s.
2o'ever that only serves to shi(t the blame! but not solve the problem. The real challenge is in protecting
particular interactions in an interconnected 'orld (illed 'ith uncontrollable elements. Ta,en at (ace
value! the sheer number o( interactions may be daunting. 3rotection solutions o(ten address this
challenge by broadly addressing particular types o( interactions or by monitoring all interactions as they
occur (or malicious intent. :n(ortunately! broad security programs and processes cannot address enough
o( the elements as to provide signi(icant protection. This leads security in practice to be more o( an art
depending on the practitioner to apply their o'n little 'orld to the challenge o( security. This can only
add more comple1ity and ne' problems. The means to (inding global! persistent protection in per(ect
balance 'ith operations is through the &Qbius De(ense.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%>- %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
The MKbius .efense
Due to the multitude o( means in 'hich interactions occur to and (rom any organi0ation! such as the
various Channels and vectors! the perimeters to be de(ended appear to ta,e the shape o( a &Qbius strip.
A &Qbius #trip is a shape 'ith no inside or outside 'hich means there is no RsideS to de(end (rom.
There(ore! 'hat is needed is a de(ense designed to protect an environment 'here in each individual can
be interacting and interconnecting 'ith everyone and everything. The &Qbius De(ense does this in three
stepsB
. "mproving veri(ication and analysis) veri(y and analy0e operations (or interactions and controls
and not *ust (la's.
2. $stablishing de(ense in 'idth) apply de(ensive tactics to balance the controls o( all interactions
'ith operations.
3. "mplementing a trust strategy) compartmentali0e ho' interactions are authori0ed or controlled.
2. "mpro#ing (erification and Analysis
The practice o( veri(ying operational security must include more than *ust (inding (la's. There needs to be
a better accounting (or and understanding o( errors that 'ill ma,e tests inaccurate. There needs to be an
improvement in test accuracy through a better understanding o( 'hat to test and 'hen to test it.
"ncreasing the accuracy o( test results 'ill serve to both provide results that can be repeated and results
'hich can be used to ma,e consistent measurements. The security test must catalog and classi(y all
points o( interaction! determine 'hich controls e1ist (or those interactions! and veri(y the (unctionality o(
those controls. 6la's 'ithin the scope or the controls must be classi(ied by ho' they a((ect operations and
not the possible or potential ris, they pose to operations. The security test must also trac, that 'hich 'as
not tested and 'hich tests 'ere not per(ormed to assure repeatability and (air comparisons 'ith past and
(uture tests. 6inally! the testing Analyst must be capable o( properly understanding the results o( the test
and 'hat they mean (or operations. The means to do all o( this are provided 'ithin this manual.
5. Establishing 0efense in Width
The main concept behind a &Qbius De(ense is to provide De(ense in 4idth and a balanced variety o(
controls to each interactive point. A per(ect balance is achieved 'ith the (la'less application o( all ten
types o( operational controls (or each interactive point. This di((ers (rom De(ense in Depth by assuring
di((erent types o( controls applied to all interactive points rather than *ust any controls at various points
'ithin a process. 4ith ne' in(ormation (rom the security test! a de(ensive posture can be created by
veri(ying that a balance o( controls e1ists at all points o( interaction. This changes the environment in
'hich inter-connectivity occurs, and curtails the possible operational changes caused by chaotic
elements either inside or outside.
The balance o( controls is important because each control can add to the attac, sur(ace o( an
operation. Assuring a balance also assures that di((erent types o( controls are used 'hich provide
protection in di((erent 'ays. This increases the range o( attac, types and problems that the interactive
point can be de(ended against. The ravs are to be used to measure the amount o( balance attained
and to assure balance is maintained as ne' operations are introduced to the scope. This manual covers
all the in(ormation re+uired to build De(ense in 4idth.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %>9
OSSTMM 3 The Open Source Security Testing Methodology Manual
6. "mplementing a Trust Strategy
To ,no' 'hich interactions re+uire less balance than others (rom De(ense in 4idth is a matter o( ,no'ing
'hich interactions 'e should trust. 6or the operations 'e have less reason to trust! 'e should apply more
o( the ten controls to achieve per(ect balance. "ndividuals 'e have less reason to trust 'e place in
environments 'here all interactions are protected by more o( the ten controls. Conversely! trust'orthy
individuals can be authori0ed to have more individual control over the interactions in their environment.
6inally 'e should separate elements (rom the environment 'hen no signi(icant reason to trust or bene(it to
the operation can be (ound in those elements. Doing so 'ill also ,eep De(ense in 4idth 'ithin a
reasonable scale o( operations so that e((iciency and e1pense do not out'eigh the bene(its o(
protection.
The trust metrics provided 'ithin this manual assure that the reasons to trust are based on (acts. As the
reasons to trust approach 00V 'e are not only certain that the individual or the operation are incapable
o( malicious or accidental damage but that it has been proven. This is no ris, assessment or guess based
on 'hat 'e ,no' (rom our Ro'n little 'orld.S The di((iculty in this process ho'ever may be in assigning
trust metrics to people. :nli,e the in(ormal and almost capricious 'ay trust is o(ten assigned! this ne'
manner may seem cold and heartless. <ut it isnKt because 'hile you are investigating 'hat reasons you
have to trust someone you are also able to (ully in(orm them o( 'hat they can do to give you more
reason to trust them. The typical means o( trusting or not trusting is not so speci(ic! nor is it so ,ind. "t is more
o( a social game o( being li,eable or not to the person providing the authori0ation. The trust metrics are
more transparent and more neutral aside (rom ho' someone (eels based on their Ro'n little 'orld.S The
trust metrics can even be veri(ied by others! such as a board or a department! 'ho can maintain the trust
calculations neutrally and re-assess regularly or 'henever itKs necessary.
4et 6hat 6e 5eed
The application o( the &Qbius De(ense has many rami(ications. 6irst! it assures that the results o( security
tests are the (acts. "t assures that the tests have been thorough and based on the processes o( operations
and not the s,ills o( the Analyst. This provides an organi0ation 'ith an incredible amount o( intelligence
over their o'n operations (or comparisons 'ith other organi0ations, or even *ust trending sel( assessments.
"t is the ,ind o( in(ormation that decisions re+uire, and that 'hich (oster signi(icant operational
improvements.
#econd! it changes the (re+uency o( security tests re+uired because, instead o( de(enses being based on
reacting to attac,s and vulnerabilities! they are part o( change control instead. There(ore 'hen ne'
operations are initiated! the environment 'ill be re-assessed (or ne' or di((erent points o( interaction. The
need to test (or ne' (la's is no longer necessary nor is the need to test (or compatibility o( security
updates a(ter (i1ing those (la's. #ecurity updates! i( desired! 'ill instead become part o( the change
control process and can be tested on schedule. This 'ill drastically reduce the time spent putting out (ires
so that ne' (ocus can be put on improving operations and building better in(rastructure.
Third! it changes the o(ten secretive and socially demanding 'ay 'e use trust 'ithin organi0ations. "t
allo's the per(ormance and history o( each individual to spea, (or itsel(. This adds accountability to each
role and removes pre*udices that can strangle an organi0ation, either operationally or legally. Not to
mention it is the most (air means o( assuring each person has the responsibility over their o'n successes
and (ailures.
The changes re+uired by the typical organi0ation to achieve these bene(its are actually small. The
changes re+uired by the security industry to meet the ne' needs o( the implementers o( the &Qbius
De(ense 'ill be huge. And change 'ill bring ne' opportunities.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%>: %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
This methodology is free precisely
because we prefer to be free as well.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %>;
OSSTMM 3 The Open Source Security Testing Methodology Manual
,hapter 19 < Open Methodology 2icense
The OM2 3
This license is provided under the Creative Commons 3.0 Attribution! 200 by "#$C%&.
')+&MB2+

This license is intended to protect a methodology as a comple1 set o( methods! processes! or procedures
to be applied 'ithin a discipline. The ,ey re+uirements o( this license are that) . the methodology has
value as intellectual property 'hich through application thereo( can produce value 'hich is +uanti(iable!
and 2. that the methodology is available publicly and an appropriate e((ort is made (or the methodology
to be transparent to anyone.
4ith respect the @N: @eneral 3ublic ;icense -@3;.! this license is similar 'ith the e1ception that it gives
the right to developers to include this %pen &ethodology ;icense -%&;. to anything 'hich is not
modi(iable and distributed commercially.
The main concern covered by this license is that open methodology developers receive proper credit (or
contribution and development.
#pecial considerations to the 6ree #o(t'are 6oundation and the @N: @eneral 3ublic ;icense (or legal
concepts and 'ording.
T+)MS &5. ,O5.TO5S
. The license applies to any methodology or other intellectual tool -i.e. matri1! chec,list! etc.. 'hich
contains a notice placed by the creator saying it is protected under the terms o( this %pen &ethodology
;icense 3.0 or %&; 3.0.
2. The &ethodology re(ers to any such methodology! intellectual tool or any such 'or, based on the
&ethodology. A R'or, based on the &ethodologyS means either the &ethodology or any derivative
'or, by Trade #ecret la' 'hich applies to a 'or, containing the &ethodology or a portion o( it! either
verbatim or 'ith modi(ications or translated into another language.
3. All persons may use! distribute! teach! and promote the &ethodology e1actly as it has been received!
in any medium! provided that they conspicuously and appropriately publish on each copy the
appropriate %pen &ethodology ;icense notice and the attribution (or the creator or creators o( the
&ethodologyL ,eep intact all the notices that re(er to this ;icense and to the absence o( any 'arrantyL
give any other recipients o( the &ethodology a copy o( this ;icense along 'ith the &ethodology! and the
location as to 'here they can receive an original copy o( the &ethodology (rom the &ethodology
creator.
8. Any persons 'ho sell training or services o( the &ethodology must clearly display the name o( the
creators o( this &ethodology in addition to the terms o( this license.
N. All persons may include this &ethodology in part or in 'hole in commercial service o((erings! private!
internal! or non-commercial use including so(t'are! chec,lists! or tools! or 'ithin a class or training (or
educational purposes 'ithout e1plicit consent (rom the creator providing points 3 and 8 are complied
'ith.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%>? %((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org
OSSTMM 3 The Open Source Security Testing Methodology Manual
C. No persons may distribute an adaption! modi(ication! or change o( this &ethodology nor commercially
sell a product! tool! chec,list! or so(t'are 'hich applies this &ethodology 'ithout e1plicit consent (rom
the creator.
O. All persons may utili0e the &ethodology or any portion o( it to create or enhance (ree so(t'are and
copy and distribute such so(t'are under any terms! provided that they also meet all o( these conditions)
a. 3oints 3! 8! N! and C o( this ;icense are strictly adhered to.
b. Any reduction to or incomplete usage o( the &ethodology in so(t'are must strictly and e1plicitly
state 'hich parts o( the &ethodology 'ere utili0ed in the so(t'are and 'hich parts 'ere not.
c. 4hen the so(t'are is run! all so(t'are using the &ethodology must either cause the so(t'are! 'hen
started running! to print or display an announcement o( use o( the &ethodology including a notice
o( 'arranty ho' to vie' a copy o( this ;icense or ma,e clear provisions in another (orm such as in
documentation or delivered open source code.
7. "(! as a conse+uence o( a court *udgment or allegation o( 3atent in(ringement! Trade #ecret la'
in(ringement! or (or any other legal reason! 'here conditions are imposed on any person -'hether by
court order! agreement or other'ise. that contradict the conditions o( this ;icense! they do not e1cuse
said person (rom the conditions o( this ;icense. "( said person cannot satis(y simultaneously the obligations
under this ;icense and any other pertinent obligations! then as a conse+uence said person may not use!
copy! apply! use! distribute! or promote! the &ethodology at all. "( any portion o( this section is held invalid
or unen(orceable under any particular circumstance! the balance o( the section is intended to apply and
the section as a 'hole is intended to apply in other circumstances.
P. "( the distribution or use o( the &ethodology is restricted in certain countries either by patents or by
Trade #ecret inter(aces! the original creator 'ho places the &ethodology under this ;icense may add an
e1plicit geographical distribution limitation e1cluding those countries! so that application! use! or
distribution is permitted only in or among countries not thus e1cluded. "n such case! this ;icense
incorporates the limitation as i( 'ritten in the body o( this ;icense.
0. "#$C%& may publish revised or ne' versions o( the %pen &ethodology ;icense. #uch ne' versions 'ill
be similar in spirit to the present version! but may di((er in detail to address ne' problems or concerns.
5O 6&))&5T=
. <ecause the methodology is licensed (ree o( charge! there is no 'arranty (or the methodology! to the
e1tent permitted by applicable la' e1cept 'hen other'ise stated in 'riting the creator or other parties
provide the methodology Ras isS 'ithout a 'arranty o( any ,ind! either e1pressed or implied! including!
but not limited to! the implied 'arranties o( merchantability and (itness (or a particular purpose. The entire
ris, as to the +uality and per(ormance in use o( the methodology is 'ith the persons accepting this
license. #hould the methodology prove incomplete or incompatible said person assumes the cost o( all
necessary servicing! repair or correction.
2. "n no event unless re+uired by applicable la' or agreed to in 'riting 'ill the creator! or any other
party 'ho may use! apply! or teach the methodology unmodi(ied as permitted herein! be liable to any
persons (or damages! including any general! special! incidental or conse+uential damages arising out o(
the use o( or inability to use the methodology -including but not limited to loss! inaccuracies! or (ailure o(
the methodology to operate 'ith any other methodologies.! even i( such holder or other party has been
advised o( the possibility o( such damages.
Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 200! "#$C%&! '''.isecom.org! '''.osstmm.org
%((icial %##T&& Certi(ications) '''.opsa.org! '''.opst.org! '''.opse.org! '''.o'se.org! '''.trustanalyst.org %>@
Why test operations? Unfortunately, not everything works as configured. Not everyone behaves as trained.
Therefore the truth of configuration and training is in the resulting operations. Thats why we need to test
operations.
The Open Source Security Testing Methodology Manual strives to be the ultimate security
guide. Better known to security experts and hackers alike as the OSSTMM, spoken like
awesome but with a t, is a formal methodology for breaking any security and attacking
anything the most thorough way possible.
Released for free for the first time in 2001 as the underdog to the security industrys product-
focused security advice, the manual achieved an instant following. Being open to anyone for
peer review and further research led to it growing from its initial 12 page release to its current
size of over 200 pages. For testing security operations and devising tactics it has no equal.
The OSSTMM is in its third version and is a complete re-write of the original methodology. It now
includes the ever-elusive security and trust metrics at its foundation. It required 7 years of
research and development to produce the perfect operational security metric, an algorithm
which computes the Attack Surface of anything. In essence, it is a numerical scale to show
how unprotected and exposed something currently is. Security professionals, military
tacticians, and security researchers know that without knowing how exposed a target is, its
just not possible to say how likely a threat will cause damage and how much. But to know this
requires a thorough security test which happens to be exactly what the OSSTMM provides.
To say the OSSTMM 3 is a very thorough methodology is an understatement. It covers proper
attack procedures, error handling, rules of engagement, proper analysis, critical security
thinking, and trust metrics. It provides 17 modules like Visibility Audit, Trust Verification, Property
Validation, and Competitive Intelligence Scouting, each which describes multiple attacks
(called Tasks), for 5 different interaction types with a target (called Channels) organized by
technical knowledge and equipment requirements as Human, Physical, Telecommunications,
Data Networks, and Wireless. The OSSTMM has indeed become a complex organism but with a
new focus on readability and usability, it is far from complicated to use.
Security doesnt have to last forever; just longer than
everything else that might notice its gone.
Official OSSTMM Certifications: www.opsa.org, www.opst.org,
www.opse.org, www.owse.org, www.trustanalyst.org
Copyright 2010, ISECOM, www.isecom.org, www.osstmm.org

You might also like