An Introduction to OSSTMM Version 3

Thursday, July 15, 2010

Infosec Island Admin



As a security consultant, I've always looked for ways to increase consistency, efficiency and value when conducting security analysis on a client's network or business. Even more-so, over the years as I hired employees, I wanted a consistent approach across the board, where the same results could be realistically achieved regardless of the consultant performing the engagement. This would, of course, require both a data collection methodology as well as a reporting methodology in order to work properly.

About 5 years ago (while searching for any existing methodologies), I stumbled across ISECOM and the Open Source Security Testing Methodology Manual (or OSSTMM, commonly pronounced "Awe-Stem"). It changed the way my company and I engaged with clients at every angle.

At the time (late 2005), version 2 of timagehe OSSTMM was available, having had its first successful revision since 2001 when it began. Although there were some really good approaches to various tasks performed during the assessment process: there was an actual methodology, an approach, a way of thinking differently that shone through the bits and pieces of those tasks, which jumped out and immediately appealed to me. Also,  it was much more scientific and much less "experience-based" and subjective, as I had been used to. (Yes, after a decade of buzz-words, catch phrases and vendor technology pitches, its hard not to become tainted and personally biased in one's approach to assessing security.)

At the time, I didn't quite grasp the whole concept though; nor was it clearly defined within version 2 (although a few more bits and pieces came to light with the release of version 2.2 in early 2006).

Now, on the dawn of the much anticipated release of OSSTMM version 3 - and after having been given a chance at a "sneak peak" at some of the new Chapters and sections - the puzzle is complete for me, and there is something to be really excited about here.

Of course, not everyone will agree, and there will be much debate, but I believe that if you take the time to really understand the intent of the OSSTMM, rather than the letter of specific testing modules, you will be better off for it -- regardless of your preference for the science vs. the art debate of security assessments and risk analysis.


In this article, I will attempt to explain the key concepts behind the OSSTMM, as explained in version 3, and as understood by me. Should my interpretation be wrong, I'm sure to stand corrected here :)

What is the OSSTMM?

In short, the OSSTMM is a mechanism used to determine the Operational Security ("OpSec") of a target scope. OpSec is defined as the combination of "separation and controls without limitations". It is essentially a measurement of protection between assets, using a formula with a method and approach to identifying and categorizing controls (security measures) and limitations (weaknesses or  vulnerabilities). What is actually measured is the "Attack Surface" of a given target, with the goal of identifying deficiencies in the protection measures in place.

What the OSSTMM is not, is a Risk Assessment methodology - rather it is a means for collecting and analyzing data to produce results sufficient to assist with risk-decisions. As "Risk" is a subjective concept (one person's opinion of it, differing from another's), the OSSTMM is a means to define and consistently measure the state of operational security so that decisions about risk can be made based on scientific data, rather than past experiences, product preference or other biased human inputs.

Nor is the OSSTMM a "Threat Analysis" methodology; rather it assumes nothing about specific threats, only the Attack Surface, and attempts to identify and measure deficiencies (limitations) in the protection of assets. It is also very repeatable and can be used to measure progress (or the lack thereof) in the security operations of any organization.
I've described this in very high-level concepts, I know - but keep all this in mind as we discuss the OSSTMM in more detail. And don't fear--if this is your first exposure to OSSTMM and you are accustomed to "Vulnerability Assessments", think of this as a beefed up version with a better action plan to boot. We'll be discussing the specifics with examples in later articles.

Key Concepts

I mentioned earlier that back in 2005 I noticed a glimmer of the overall intent of what the OSSTMM was and has now become. A few of the original concepts are still the foundation for the OSSTMM when used in the assessment process, but some more clearly defined concepts in the upcoming version allow the OSSTMM methodology to be used in assessing the security of all sorts of things. (One specific example that I hope to get translated into English one day soon, is an analysis of the bank in relation to the Ocean's Eleven movie. The OSSTMM was used to very clearly show the bank's lack of operational security in protecting their assets.).

At any rate, here's a brief run-down of what I consider to the heart and soul of the OSSTMM

1. Rules of Engagement
My favorite thing about my initial exposure to the OSSTMM was the Rules of Engagement section. This made the most immediate impact in the way myself, my consultants and my sales guys interacted with clients before, during and after the assessment process.

The Rules of Engagement encompass about 50 individual points starting with the Sales and Marketing approach, all the way through final delivery of the report. I wont go into them all here, but these rules of engagement set the table (so to speak) for the overall approach and methodology, with a focus on Critical Security Thinking (another Key Concept) and an unbiased approach to the measurement of OpSec.

For "vendor-agnostic" firms with no agenda to sell product or service after the fact, many of these concepts are no-brainers, some are not. My favorite is the forbidding of Fear Uncertainty and Doubt ("FUD") in the Sales and Marketing process...imagine that.

Many of the rules are very specific to notification, permission, contracts and performing the actual assessment, but they show that there is something behind the curtains of this manual that differs from other methodologies.

2. Critical Security Thinking
A new concept introduced in OSSTMM version 3 (although always there in the wings) is Critical Security Thinking. Critical Security Thinking is the practice of using logic and facts, vs opinion, experience or bias to form ideas about security (easier said than done you say? -- perhaps).

My favorite example of Critical Security Thinking, as outlined in the OSSTMM is in analyzing the popular statements "If an attacker wants to get in bad enough, he will" and "there is no such thing as perfect security". I'm sure I've said (and know I've heard a thousand times) each of these statements, but neither of them are based on fact or logic, but on bias and opinion. 

According to the OSSTMM "The process of critical security thinking is dependent on the Analyst being able to discern true statements or at least recognize the degree of possible falsity or dynamic properties in a statement. One way to do this is to recognize the amount of trust you can have in a fact through the use of trust metrics".

Oh, and this isn't just a high-level concept in version 3...there's a 6-step technique that assists with the process and ensures a consistent approach to Critical Security Thinking. One of my favorite ISECOM projects is Jack of All Trades, which is a series of exercises to get your brain thinking critically. The first (and easiest) example in the "Jack" exercises is defining 10 ways to turn the light off in a room containing a light bulb and a switch, then 10 ways to keep it on, then 10 ways to determine if it's on to begin with. Jack can be downloaded from

3. Trust Analysis
Another new concept in version 3 is that of Trust Analysis. This concept is what provides for the versatility of the OSSTMM's use in other areas of analysis outside of information security, and as it turns out, what was behind the OSSTMM all this time to begin with...this is what I was struggling to grasp.

According to the OSSTMM, "As part of OpSec, trust is one part of a target’s porosity. Where security is like a wall that separates threats from assets, trust is a hole in that wall. It is wherever the target accepts interaction from other targets  within the scope. However, people tend to use improper or incomplete operational controls with their  trusts like authentication that has been made with improper identification such as a voice over a telephone, a business card, or even just the assumption that because a person is in the room that they  are authorized to be there. This opens people up to fraud and deceit. The use of additional controls are required to secure a trust, to assure its integrity and resilience."

Although the OSSTMM goes into great detail describing the interactions between assets and their relation to trust with or without implementing certain controls (like Authentication), I will only say here that understanding this aspect of the OSSTMM is a game-changer, and -like other aspects of the OSSTMM- Trust Analysis comes down to a scientific formula using a set of 10 Trust Properties, which can be applied to almost every situation to create "Trust Rules" (which is better left explained in the new OSSTMM when it's released)

As to how Trust Analysis applies directly to the Security Testing process, the OSSTMM goes on to say "Security tests will verify which operational trusts exist however the use of trust rules are required to know if  they should exist. This is determined with the use of the Trust Rules during security testing."

4. Defense in Width
The final Key Concept that I'll discuss in this article is "Defense in Width"...whether specifically defined in the OSSTMM v3 or not (I've only seen a couple of Chapters :) it's certainly implied from what I gather from associated presentation materials I've seen.  This is another differentiator between the OSSTMM approach and others, and it's closely related to Critical Security Thinking.

"Defense in Depth" is another buzz-word used so often over the past decade, that we've forgotten what it means. Nowadays, its heavily used by vendors and resellers to sell another piece of gear to sit somewhere in your network to protect against even another buzz-word.

If you ask most people to define Defense in Depth, the answer would undoubtedly be "Multiple Layers of Defense, like an onion". The problem is that today's infrastructures in no way resemble an onion, so the approach is flawed in it's basic concept.

The concept of Defense in Width involves applying multiple controls (10 to be exact) over each vector or interaction, rather than viewing an enterprise as being protected by single layers which can be "peeled back". The goal is to assess each asset (port, IP address, application, whatever the scope definition is) against the 10 controls defined in the OSSTMM, and measure the deficiency (OpSec). 

As Pete Herzog explains: "The biggest difference is that DiD (Defense in Depth) requires the cooperation of the users to assure security is maintained and DiW (Defense in Width) does not. DiD is like the Witness Protection Program for networks where there are some Authentication controls and a lot of Privacy or Confidentiality controls but really it depends on the Witness to follow the rules of the program to stay safe. DiW is like the prison system for networks. All interactions to and from the inside are heavily piled with multiple controls of different types as well as the interactions between the prisoners and the guards. You see really the entire 10 controls applied across nearly all interactions. And when you don't, well, that's how problems happen in prisons."


As you read this, keep in mind that each of the Key Concepts I discussed spans multiple pages and chapters within the OSSTMM v 3 and the above commentary is only meant to introduce the concepts that are very clearly defined in the manual itself.

I myself am very exited about this new version and (as opposed to picking and choosing portions I like and use) this new version is a really comprehensive approach that we are already applying in our client engagements. 

In coming articles, I will discuss the OpSec metrics, controls, and other specific formulas and methods in more detail, and hope to do a decent job of summarizing the "gist" of the OSSTMM.

For more information about ISECOM, visit

For more information about the OSSTMM, visit

Possibly Related Articles:
Enterprise Security Security Awareness Security Training Vulnerabilities
Risk Assessments Security Audits OSSTMM ISECOM
Post Rating I Like this!
David C. Brown Nice review. Thank you.

You should also point out that this approach might be useful; but until it is reviewed by a wider audience it is still speculation. Additionally, how many years has it been coming? Again, Thanks for the article.
Amine Mehablia Thank you for the article.
I nevr used this approach even though i have known OSSTMM since the early version. Do you have any case study to share it with us, if possible.

Fred Williams I think I need a "Cliff Notes" version of OSSTMM! The one thing that immediately sticks out at me is the sheer size of the thing. The v.3 TOC lists nearly 200 pages (the TOC is 4 pages itself). As a newbie, it is a daunting task to try and go through and understand it without spending a few days.
Fred Williams Thanks Mike! I'll be looking forward to your future posts and Pete's preso @ OWASP next month.
The Dude I always liked the idea behind the OSSTMM methodology, because it was always a good balance between theory & actual doing (that's where most IT-compliance stucks). If you really would like to get more (market) attention, I think you have to closely attach it to our ISO27xxx friends & NIST references. Also to get a broader audience, you need to have a simpler abstraction(like you have done earlier with the 'light' release), would think about like the 'Prioritized Approach for PCI DSS' - simple to understand the initial message to proceed further. Unfortunatley the subscription is to expensive (yes, I can imagine how much intellectual property is in there!!) and therefore as the usual Sec-Pro I use the good old NIST/CIS/OCTAVE/ISACA/SIG/guidelines.
The Dude Thanks MM, look forward for v3! One last comment: it would be great if OSSTMM would be integrated in a simple documentation framework like verinice has done for the German IT-Grundschutz ( I personally would add your OSSTMM3 TOC to the dradis framework ( - very, very useful for any Security Tester to have a consistent template & framework tool (we all know how lazy testers are concerning documentation ;-). I use dradis & verinice on a regular base and can highly recommend!
Pete Herzog Hi Dude, Hi Mike,

First, great article, Mike! I wanted to point out that OSSTMM 3 doesn't really follow the same line as the ISO or NIST documents. A lot of it is new research that does take quite a turn from what's being done now in security. So the parallel isn't really there. However both ISO and NIST have access to the OSSTMM 3 draft and I've learned they are looking into integrating it into some of their newer documentation.

OSSTMM 3 will be made freely and publicly available this year. And if you can't pay the subscription cost now, you can just contribute to any of the ISECOM projects and get access to it.
Yendri Fernando nice article, Michael
can i ask some question,
1. Should we choose one of the five channels? In my case i choose the Data Network Channel and ignore others channel.
2. Should we finish all modules and all tasks? how about if we don't finish some task? I determine "Defining a Security Test" on early of my test type is Double Blind (Black Box). I hope Pete can answer it too as a founder..

Pete Herzog Hi Yendri, we are making that ll more clear in OSSTMM 4. 1. yes, choose a channel. However be aware that the type of test may differ in your region from others so your pen test may require some parts of Human Security testing and some from Wireless too. Your vuln scanning may only require part of Data Networks testing.
2. No, you can finish them all for thoroughness but it's not required. You just need to make sure that if you do fill out a STAR that those areas are left as "not tested" or "out of scope".

Hope that helps!
Yendri Fernando Thanks for the answer Pete. So,
I choose double blind (black box) test type, can i ignore some task because the task required white box pen test?
Pete Herzog Yendri, yes, but you need to keep track of what you ignore. In an OSSTMM test being clear on what and how you did not test is as important to report as what was tested. This allows for future report comparisons and protects you in cases of compliance failure.
Yendri Fernando Ok, for STAR, wheter i must change the STAR module according channel i choosen or i let it as the default?
Second, what about if i ignore integrity, non-repudiation module? we know it all use to calculate actual security on Rav? Must i fill it 0?
Pete Herzog Yendri, write me offline at pete -at-
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.