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.
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 http://www.isecom.org/projects/jack.shtml
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."
In the 1980s and 1990s, business applications and data were largely confined within and protected by a Local Area Network (LAN). The 2000s introduced a significant change. Download this white paper now to learn why the shift to the cloud is changing how companies think about and manage their IT infrastructure. more
Microsoft moved to the cloud in 2014, and, as a result, Office 365 is taking off. Now, Okta customers are connecting to Office 365 in increasing numbers. This eGuide explains why IT departments should plan and deploy solutions around identity and mobility management in concert with their Office 365 roll out to get maximum user adoption. more
For most companies, Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) play a central role in coordinating identity and access management policies. When on-premise applications are integrated to Active Directory or LDAP, users get the best possible experience. That's why Okta's cloud-based identity and access management service provides a highly useful single integration point. more
With more and more businesses adopting Software-as-a-Service (SaaS) applications, enterprise IT is fundamentally changing. This whitepaper presents the eight biggest Identity and Access Management (IAM) challenges associated with adopting and deploying cloud and SaaS applications, and discusses best practices for addressing each of them. more