Deleted:Open Source Security Testing Methodology Manual

This page was listed for deletion discussion per Wikipedia's deletion policy, but it may not meet deletion criteria on WikiAlpha and as such has been preserved here; it may have the potential to be moved to article space. Check to see if the article meets the criteria for publishing on WikiAlpha.

Template:Advert The OSSTMM, commonly pronounced "Awe-Stem", is a manual on security testing and analysis created by Pete Herzog and provided by ISECOM, the non-profit Institute for Security and Open Methodologies. The methodology itself that covers what, when, and where to test is free to use and distribute under the Open Methodology License (OML). The manual, the OSSTMM as a whole, is also free, released under the Creative Commons 3.0 Attribution-NonCommercial-NoDerivs license. The manual states, "All things being interconnected, this methodology is free precisely because we prefer to be as well."

The latest version, which supersedes its previous versions, OSSTMM 3, states it is "a collection of verified facts which are beneficial and progressive towards the improvement of operational security. Unlike 'best practices' the information within has been verified to be the correct action for better security."

The OSSTMM is also as much a philosophy on operational security as it is a methodology, stating, "In art, the end result is a thing of beauty, whereas in science, the means of reaching the end result is a thing of beauty. When 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 know the test has been properly conducted. For that you use a formal methodology. This is it."

History

The story is that the OSSTMM began as a sketch Pete Herzog made during a train ride to find a means of security testing in accordance to the scientific method. As he got off the train, he met his wife and said to her, "I think I figured out something big."

The first version was published in January 2001 and was twelve pages long. Comparatively, the newest one, OSSTMM 3 is over one hundred and twenty pages.

The creator of the OSSTMM, Pete Herzog, started ISECOM along with famed photographer and computer scientist, Marta Barceló, to support the OSSTMM and keep it free of commercial influence as it gained popularity. Originally, the first OSSTMM was released under the website ideahamster.org, a gift from Pete's brother until they could afford a domain of their own. They called the community group Ideahamsters, a term for people who never stop coming up with new ideas. Later, as Herzog recounts, in a March 2003 interview with SecurityFocus journalist Federico Biancuzzi:

“ ISECOM began in January 2001 with the OSSTMM. Actually, the OSSTMM created ISECOM. The truth is really that I wanted to create a plan on how to test security because I didn't think it was being done right and I wanted to improve it. So I searched the net only to find everyone referring to this proprietary methodology they have that's so great. But I couldn't know because I couldn't see it. I was suspicious that it was true because I had seen the reports of some of the companies that said that they had some great proprietary methodology and there was nothing special about what was essentially vulnerability scanner outputs re-dressed as reports. So once I finished something, I posted it to the web and asked the public to give feedback. I had no idea that I was not the only one in need of such a thing. So here we are, five years later and the OSSTMM is at around four million downloads since its inception - with legislation requiring its use in some countries and some government employees and contractors around the world being required to be certified in it just to prove they can really do their jobs. And it's still growing at a fast and shiny pace. We're trying to staff-up to handle this all but that's a problem in itself. ”

The OSSTMM itself explains the history as such:

“ Since its start at the end of 2000, the OSSTMM quickly grew to encompass all security channels with the applied experience of thousands of reviewers. By 2005, the OSSTMM was no longer considered just a best practices framework. It had become a methodology to assure security was being done right at the operational level. As security audits became mainstream, the need for a solid methodology became critical. In 2006, the OSSTMM changed from defining tests based on solutions such as firewall tests and router tests to a standard for those who needed a reliable security test rather than just a compliance report for a specific regulation or legislation.

With Version 3, the OSSTMM encompasses tests from all channels—Human, Physical, Wireless, Telecommunications, and Data Networks. A set of security metrics, called Attack Surface Metrics (measured in "ravs") showing the balance between operations, controls, and all known limitations, provide a powerful tool that can provide a graphical representation of state, and show changes in state over time. This integrates well with a 'dashboard' for management and is beneficial for both internal and external testing, allowing a comparison/combination of the two. Quantitative Risk Management can be done from the OSSTMM Audit report findings, providing a much improved result due to more accurate, error free results. The OSSTMM includes information for project planning, quantifying results, and the rules of engagement for performing security audits. The methodology can be easily integrated with existing laws and policies to assure a thorough security audit through all channels.

”

Purpose

The primary objective behind this manual is to establish a scientific methodology by establishing metrics for the evaluation of operational security (OpSec), based on examination of test results. The manual suits most types of security audits including penetration tests, ethical hacking, security assessments, vulnerability assessments, red-teaming, blue-teaming ect.

A secondary purpose is to provide guidelines which, will allow an analyst to perform a certified OSSTMM audit. The guidelines assure the following:

1. The thoroughness of the test
2. Inclusion of all necessary channels
3. Legal compliance of test
4. Quantifying results
5. Consistent and repeatable results
6. Factual information is derived from tests only.

An indirect benefit is that, it acts as a central reference in all security tests regardless of the size of the organization, technology, or protection.

Chapter 1 What You Need To Know

This chapter establishes the grounds for the Operational Security (OpSec) methodology, with emphasis that the objective is to determine if a security solution provides desired operational coverage, in contrast to looking into parameters defined in compliance guide lines.

Opsec measures security as 100% when the asset and target are completely separated. Anything else requires a safety considerations by the way of controls to lessen the impact of threat. There are different types of controls. It is important to categorize controls by what they do in operations to be certain of the level of protection provided by them.

OpSec comprises of individual elements which are used to quantify the Attack Surface (the lack of separations and controls) that exist of the Vector (direction of the interaction). The adoption of a reductionist approach gives security and safety a new perspective, whereby they can be understood independently from risk. Adopting the exact balance of security and controls makes it possible to create Perfect Security.

As this is a revolutionary concept, new terminology is required. The OSSTMM Defines:

• Attack Surface
• Attack Vector
• Controls
• Limitations
• Operations
• Perfect Security
• Porosity
• Safety
• Security
• Rav
• Target
• Vector
• Vulnerability

which need to be understood in the context of the document.

Security

The state of security requires to be analyzed to determine if there is a possibility for interaction with the asset. Ability to interact is defined as porosity. This is further categorized in the elements of visibility, access and trust. Based on the element identified, controls can be introduced.

Controls

Controls are used to provide safety in operations from threats that arise through interaction.

OSSTMM identifies 12 main categories of controls.

Two of these controls, Identification and Authorization, cannot function independently and hence identified as the Authentication control. This leaves OpSec with 10 possible controls. These are further divided into 2 classes, Class A: Interactive Controls and Class B: Process Controls.

The Class A Interactive Controls make up exactly half of all the operation controls. These controls directly influence Visibility, Access, or Trust interactions.

The Class A categories are:

• Authentication
• Indemnification
• Resilience
• Subjugation
• Continuity

Class B controls also known as Process Controls which are used to create defensive processes,they protect the assets once the threat is present, include:

• Non-repudiation
• Confidentiality
• Privacy,
• Integrity
• Alarm

A caution about the use of controls is if their limitations go unnoticed they will add the attack surface. It be becomes important therefore to thoroughly test protection mechanisms under all conditions.

Information Assurance Objectives

Controls can be mapped against the information Security industry acknowledged, Information Assurance Objectives of Confidentiality, Availability, and Integrity as follows

Information Assurance Objectives	Operational Controls
Confidentiality	Confidentiality Privacy Authentication Resilience
Integrity	Integrity Non-repudiation Subjugation
Availability	Continuity Indemnification Alarm

Limitations

Limitations are explained as the inability for controls to work properly due to flaws and restrictions. These are classified in 5 categories and defined by operation. The OSSTMM definition of limitation is unique compared to other security management frameworks and best practices, because the others refer to vulnerabilities or deficiencies which are categorized by the type of attack or the threat.

Since an enumeration of all threats will never be possible it is more sensible to focus on what it takes for security and safety mechanisms to fail, hence allowing the analyst to test for conditions in which it will be unable to sustain the necessary level of protection.

The OSSTMM the five Limitation classifications are:

1. Vulnerability
2. Weakness
3. Concern
4. Exposure
5. Anomaly

Limitation mapping :

Category	OpSec	Limitations
Operations	Visibility Access,Trust	Exposure Vulnerability
Controls
Class A Interactive	Authentication, Indemnification, Resilience, Subjugation, Continuity	Weakness
Class B	Non-Repudiation, Confidentiality, Privacy, Integrity, Alarm	Concern
		Anomalies

Additionally, more than one category can apply to a limitation when the flaw breaks OpSec in more than one place.

Justification for Limitations Irrespective of any conclusion about the threat potential of a limitation , all limitations discovered must be counted within the attack surface.

Actual Security

OSSTMM Audit results show the Security, Controls and limitations, as a logarithmic representation of the attack surface at a particular instance in time. The mathematical representation is useful to prove when money is being spent on ten wrong types of controls.

Compliance

Compliance is not security and exists separate from it. Compliance projects are not the right point in time to redefine operational security requirements as a result of an OSSTMM test.

Chapter 2 What you need to do

This chapter highlights the need to properly define the security test, by approaching the problem in small pieces.

Defining a Security Test

It requires 7 steps which will lead to a measurement of the attack surface.

1. Defining what need to be protected: testing will be conducted for limitations on their controls
2. Identification of the engagement zone: the area around the asset including the protection mechanisms and process/services performed by the asset.
3. Definition of elements outside the engagement zone that keep the asset operational: this is the test Scope
4. Compartmentalize the assets within the scope through the direction of interaction. These are vectors. Each vector should be a separate test.
5. Identify test requirements:. 5 channels have been classified. Each Channels need to be tested for each vector.
6. Determine the type of information the test should yield. The test type for each test must also be defined.
7. Compliance to the Rules of engagement as defined in OSSTMM

Scope

Scope is the total OpSec environment for interaction with any asset. There are 3 classes with a total of 5 channels. Classes define the area of study, investigation or operation, while channels are the means of interacting with assets.

A security audit requires testing all 5 channels.

Class	Channel	Description
Physical Security PHYSSEC	Human Physical	Comprises the human element of communication where interaction can be physical and psychological Physical security testing where the channel is both physical and non-electronic in nature. Comprises the tangible element of security where interaction requires physical effort or an energy transmitter to manipulate
Spectrum Security SPECSEC	Wireless	Comprises all electronic communications, signal and emanations which take place over the known EM spectrum
Communications Security COMSEC	Telecommunications Data Networks	Comprises all telecommunication networks, digital or analog, where interactions takes place over established telephone or telephone like network lines. Comprise all electronic systems and data networks where interaction takes place over established cable and wired network line.

Channels have been organized in the manual as the recognizable means of communication and interaction to facilitate testing by minimizing inefficiency that come about for strict methodologies.

Common Test Types

There are 6 types of tests. These are based on the amount of information the analyst has about the target and how much the target is aware of the test plans.

The types are

1. Blind: The tester has no prior information about the target, while the target is prepared.
2. Double Blind: The tester has no prior information about the target and the target is not prepared.
3. Grey Box: The tester has limited knowledge of the target, while the target is prepared.
4. Double Grey: The tester has limited knowledge of the target and the target is partially prepared.
5. Tandem: The tester has full disclosure of the target and the target is fully aware of the testers plans.
6. Reversal: The tester has full disclosure of the target while the target knows nothing of the testers plans.

Rules Of Engagement

These rules which define operational guidelines for acceptable practices in marketing, performing testing, and handling the test results state:

A. Sales and Marketing

1. The use of fear, uncertainty and doubt cannot be used as a sales or marketing pitch.
2. No free services will be offered incases when target penetration is not successful.
3. Publicized contests to promote assurance of testing or products is prohibited
4. Open disclosure of clients to prospects is prohibited, without prior written consent.
5. Clients should be advised truthfully and factually about security evaluations.

B. Assessment / Estimate Delivery

1. Tests on any scope must have prior written permission from target owner.
2. Testing of known soft targets is forbidden until proper security infrastructure is put in place.

C. Contract and Negotiations

1. The security analyst must maintain confidentially of client information and test results.
2. Liability should be limited to cost of the job.
3. The limits and dangers should be listed in the contract
4. Analysts site information should be identified for remote testing.
5. The client must provide signed exemptions for trespass, liabilities up to the cost, excluding cases where malicious activity has been proven.
6. Emergency contact details must be provided.
7. The contract must grant clear permission for specific test techniques.
8. Provision must be provided for changes in statement of work.
9. Conflicts of Interest must be verified and included in the contract.

D. Scope Definition

1. The scope must be defined in the contract
2. The limits of test must be explained in the audit.

E. Test Plan

1. All activities listed in the plan must be within the area of expertise of the analyst.

F. Test Process

1. Respect for public must be maintained in every manner.
2. All action must be legal.
3. Key personnel must be notified about the ongoing test activities.
4. While conducting privileges tests, the client must provide bonafide access tokens.
5. Privileges testing should be proceeded by a black box type test.
6. Test tools should be verified by the analysts prior to commencing test.
7. Denial of services testing requires explicit permission and should focus only within the scope.
8. Testing on people must be conducted on members within the scope.
9. High priority vulnerabilities should be reported to clients upon discovery.
10. Flood testing is prohibited over non-privately owned channels.
11. The Scope must be left in a security position not less that when the test started.

G. Reporting

1. Privacy of individuals must be respected.
2. Results about personnel with non-security relevance should be without individual reference
3. Only test reports where there was personal direct analyst involvement should be signed off.
4. Reports should not contain any personal resentment.
5. In case of changes to the original testing guidelines, client notifications are required.
6. Solutions and recommendations should be valid and practical.
7. All anomalies and unknowns must be clearly identified
8. Discovered successful and failed security measures must be stated.
9. The metrics must be quantitative, and non-subjective.
10. Client must be intimated when the report is dispatched.
11. Communication of the report should be confidential.
12. Results of the report must not be use for further commercial gain beyond the client.

The Operating Security Process

Testing is required because configuration and training do not yield definite results. OpSec testing is an event test of dynamic and probabilistic systems. The common assumption is that OpSec is defensive based on the fact that security is considered to be defensive. Hence aggressive testing tends to become constrained to exploitations or design and configurational specifications. The contention to this approach is that there is no consideration of operations.

This security testing methodology is designed on the principle of verifying the security of operations. By testing operations the gap between operations and process can be analyzed. Understanding of testing process, choice of the right type of test, recognition of channel and vectors, definition of scope and proper application of methodology are essential.

The de-facto security echo process whereby, the tester makes a cause and analyzes the effect, may render swift results but is prone to error.

The Scientific industry uses a 4 point process, it includes echo, called interaction the others are inquest, intervention, induction. This process is designed for efficiency, accuracy and thoroughness. It is optimized for real world scenarios. It further differs from the echo process by allowing for more than one cause per effect and more that one effect per cause.

Four Point Process

4PP break a test down from start to conclusion.

1. Induction (Z): Determination of facts about the target from the environment
2. Inquest (C) : Investigation of emanations from the target.
3. Interaction (A/B) : Interacting with the target to trigger responses.
4. Intervention (X/Y/Z): Changing resource interactions to understand the extremities the target can continue operating under.

The Trifecta

This security testing methodology, where the start and the end are clearly defined, is designed as a flow chart which flows in both directions, it has great flexibility. The analyst creates a unique path using this methodology.

By comparison of test results it is possible to measure OpSec.

Applying this methodology the analyst can answer the following three questions (the Trifectia) , to OpSec needs

1. How do current operations work? The metrics map problem areas in different ways to identify if they are general or more specific.

2. How do they work differently from how management thinks they work? Metrics provided comparisons of states according to policies and assessed threats.

3. How do they need to work? The discrepancy between implemented controls and the loss of protection, found during security testing clearly indicate the problem,

Combining the Trifectia and the 4 point process

The Steps are.

1. Passive data collection of normal operations.
2. Active testing of operations through agitation
3. Data analysis of tested operations
4. Data Analysis from resources and operators
5. Correlate results to determine OpSec security processes.
6. Correct errors
7. Derive metrics
8. Determine the optimal level of protection best implemented.
9. Map optimal state of operations
10. Determine enhancements required through gap analysis

Error Handling

It is important to account for, and understand how and where errors can occur during the security testing. They are not necessarily the fault of the tester, and testing cannot be expected without error.

Error Type	Description
False Positive	Something determined as true is actually revealed as false.
False Negative	Something determined as false is actually revealed as true.
Gray Positive	Something answers true to everything even if false.
Gray Negative	Something answers false to everything even if true.
Specter	Something answers either true or false but the real state is revelealed as unknown.
Indiscretion	Something answers either true or false depending when it's asked.
Entropy Error	The answer is lost or confused in signal noise.
Falsification	The answer changes depending on how and where the question is asked.
Sampling Error	The answer cannot represent the whole because the scope has been altered.
Constraint	The answer changes depending on the limitations of the tools used.
Propagation	The answer is presumed to be of one state or the other although no test was made.
Human Error	The answer changes based on the skill of the analyst.

Working with test errors

Due consideration should be given to test errors. Through self asseement the analyst can create a margin of operational errors to frame the thoroughness of audits. Care must be taken to eliminate bias. Error should be considered as attempts of the analysis to interact with the system. Hence serving as a record of the difficulty and complexity of the audit and the competency of the analyst to deduce errors.

The record of errors will sum up the environment of the scope, and complements the Executive summary. Many errors show an environment that may lack controls for managing change or loss.

Test results

The OSSTMM audit does not require recommendations of solutions. The analyst must report the factual current state of security, limitations within the current state and any process which cause the limitations,

The methodology should conclude with the Security Test Audit report (STAR). This is available with the manual, or from the ISECOM website.

STAR requires the following

1. Test Date and time
2. Test duration
3. Responsible Analysts names
4. Type of Test
5. Scope of test
6. Method of target enumeration
7. Tested channels
8. Test Vector
9. Attack surface Metric
10. Test completion indication
11. Issues regarding tests
12. List process which limit security
13. Unknowns or anomalies

The successful use of OSSTMM results in an actual measurement of security and controls.

Disclosure

It is possible that previously unknown or not disclosed security limitations will be discovered. How these are handled is a foremost legal consedarion.

Disclosure rights.

Ensure access/use of products or solutions do not require permissions that would other wise deny claim to disclose discovered vulnerabilities.

Responsibilities

If the above is not a contentions then it can be made public and a stake on its ownership claimed. It is a responsible action to promote the controls to be applied to fix the problem. In situations where the manufacture is contacted ample time should be give for them to address the issue.

Chapter 3 Security Analysis

Security analysis is the skill of turning information into security intelligence. It requires understanding how the information originated and the constraints in collection. The purpose of the analysis process is to make decisions based on facts.

There is a clear distinction between Security analysis and risk analysis.

Security analysis is based on facts, even if the fact states something can't be known from the information provided.

Risk analysis requires speculation and derives opinions based on information.

Risk analysis can use security analysis to improve accuracy but not vice versa. This is the reason why Trust Analysis should be considered.

Analyzing the security of everything.

Security analysis differs from risk analysis in the fact that the former never analyzes the threat. That is the domain of risk analysis.

Security analysis studies and measures the attack surface of and around the target. This enables understanding where any threats can attack if they do. It will also assure the right controls are in place and function properly covering the interactive points of the target.

Critical Security Thinking

This is a term for the practice of using logic and facts to from an idea about security enabling verification tests to be well defined. It could be an answer or conclusion providing that which makes the most sense or a characterization showing what needs to be verified. It is helpful when it comes to understanding different opinions, and will help to address and explore alternatives.

At the very least Critical Security Thinking it should identify what facts are missing.

Critical Security Thinking is dependent on the analyst being able to establish the truth of statements, the degree of falsity or dynamic properties. This can be achieved by establishing a trust in a fact using trust metrics. It can be required to separate fallacious argument from statements in tandem with trust metrics.

The Six Step Analysis Technique.

Critical Security Thinking can be reduced to 6 steps to ascertain factual results with a high trust level. The ability to validate sources and measure trust is paramount to create actionable intelligence out of test.

1. Knowledge of the target should be built from a variety of factual resources.
2. Estimate the global experience level of the type of target.
3. Assume what bias of ulterior motives the information source may have.
4. Translate jargon into more common terminology
5. Ensure equipment is properly calibrated and test environment is verified.
6. Disengage translation state from tools to the extent possible.

Remember it’s not about the analysts experience, its about discovering facts that can be built upon.

Fallacies as Qualifiers.

Testing security requires due deliberation worthy of a scientific process. Understanding how human nature influences security can be perceived and hence defined. Proper security cannot be provided until a basis for ever fact has been resolved.

Common axioms regarding security need to be understood through critical security thinking. Axioms fail to separate security from risk. Security is about protection and controls, risk is about speculation.

Some of these common qualifiers based on fallacies are:

1. There is no such thing as 100% secure: There are far too many exceptions to be a security statement
2. Even if you are secure , if an attacker wants in badly enough they'll get in: Fails to provided the time a condition and includes a equivocation fallacy
3. There is no perfect security: Fails to provide a time condition and consists of the Nirvana fallacy and the Perfect Solution fallacy.
4. Security is a process not a product: Uses the Fallacies of False Dilemma and Presumption.

Recognize the OpSec Model

The two problems of security analysis are

1. Technology is ahead of the Analyst’s understanding, which can be dependent on, if the knowledge of how things work is even openly available.
2. In many cases to deconstruct something to see how it works may be illegal

In cases where these are possible the product can be analyzed within the environment within which it interacts.

The OpSec model is applied to each Vector and Channel of the target. Application of the model requires counting the controls for each interactive point of Access or Trust and identifying Visibility exposure.

The process can be highlighted as:

1. What is visible in the scope? What is of possible value that is known? What targets can be determined?
2. What are the interactive Access points to those targets and from what vector or channel?
3. What are the Trusts within the scope and over what vector or channel?
4. Which are the controls for those Accesses and Trusts?
5. Are the controls complete or do they have limitations?

The application of the model results in evaluating if an Access or a Trust is balanced with controls. This will enabling measuring the size of the attack surface and point which access points are open without any controls.

Looking for Pattern Matching as a sign of Error

The tendency to create and adopt short cuts can affect the quality of the verification test. For intelligence that you can act upon, the result is only as good as the method used to acquire them. If the Analyst uses pattern match, the method of deduction is obscured hence the action to correct them becomes limited. Analysts must recognize unverifiable data.

Depict pattern matching by examining the test methods and result data for the following:

1. Test using specific threats instead of a thorough interaction with the attack surface.
2. The lack of details on resulting processes behind the interactions with the target.
3. Little or no information about controls for various targets.
4. Only some of the targets are reported for certain tests and those have completely negative results
5. Targets not tested for reasons which are anecdotal
6. Test of targets which have obviously not been secured.

Characterize the Results

Scientific method requires a hypothesis is made, and then data is collected through testing and observation to evaluate it. In Security testing a hypothesis is made whenever there is verification of direct or indirect interaction with a point on the scope. To consider if the test verified the hypothesis, the analyst needs establish if:

1. The right tests were made?
2. Where they Sufficient?
3. Were the right Channels tested
4. Where new interactions created that were tested?

This requires the results be characterized by discovering the properties of the scope to assure the correct tests were made for it. The tester hypothesizes the interactivity of a point in the attack surface. Test results confirm that:

1. The point is interactive and adds to the attack surface.
2. Not interactive and still adds to the surface
3. If controls are in place
4. Limitations in the controls
5. Limitations in the defined security
6. Any Anomalies

The Analyst examines the scope for where interactions might occur as well as where operations show interactions do occur. This characterization must then be matched with the tests made to determine if all the correct tests were made.

Look for Signs of Intuition

Intuition is a human condition that works subconsciously, this can lead to mistakes when it comes to detection and preparation with regard to problems. Test can require precise concentration. Although this can be aided through the use of tools certain tests are too dynamic to use them. Hence cases arise where a tester may consider that at test is not required and override it. This is where the analyst must pay special attention and look for signs of the use of intuition by the tester.

Trouble signs of intuition are:

1. Inconsistencies of the types of tests performed across multiple, similar targets.
2. The number of tests decrease between targets.
3. The length of time for tests decrease between targets.
4. The same targets tested more than once with the same tests.

In cases where intuition is detected re-testing may be necessary.

Transparent Reporting

Security testing cannot deliver all the answers, but that does not mean that blind assumptions should be made. It is important for the analyst to report everything that is found rationally.

The analyst’s report should comprise of information about the test and the following 7 test results.

1. Unknowns: The resulting actionable intelligence due to conflicting or inconclusive test results is unknown.
2. Untested targets: For what ever reason targets not tested should be reported.
3. Identified and Verified Limitations: Identified limitations are determined through knowledge and correlation. Verified limitations are reported when the vulnerability has been tested to determine if it exists.
4. False positives and the means to generate them: False positives that arise in the case of identified limitations should be reported
5. Failed Security Processes and Procedures: Limitations are often the result of failed processes or procedures.
6. Good practices: Instead of blindly accepting industrial best practices, tests should be conducted to find which actually work as expected.
7. Compliance: In cases where there are compliance requirements the Analyst needs to correlate test results to ensure the objective are met.

The rest of the manual follows that chapter with the details on doing a test. Following chapters cover:

• Analysis
• Security Metrics
• Trust Metrics
• How the Methodology Works
• Testing Human, Physical, Full-spectrum Wireless, Telecommunications, and Digital Network security.
• Compliance
• Certification
• Test Templates

Chapter 4 Operational Security Metrics

An operational metric is a constant measurement that informs us of a factual count in relation to the physical world we live in. They are operational because they are numbers we can work with consistently from day to day and person to person. It is difficult to work with relative or inconsistent measurements, because the factors have many variables which are biased or frequently changing between people, regions, customs and locations. Professional therefore attempt to standardize, through reductionism and quantifying those elements. This way, colors become frequencies, work hours become hours and minutes and attack surface becomes porosity, controls and limitations. The challenge with operational metrics is the requirement for knowing how to properly apply the metric .A thorough security test has the advantage of providing accurate metrics on the state of security. A security metric requires a test which can be described as measuring the appropriate vectors while accounting for inaccuracies and misrepresentations in the collected test data as well as the skills or experience of the security professionals performing the test. Faults in these requirements result in lower quality measurements and false security determinations. A proper security metric must avoid the biases inherent in risk assessments. The qualities have been combined to create the ravs, an unbiased factual description of an attack surface.

Getting to know the rav

The rav is a scale measurement of the attack surface. The amount of uncontrolled interactions with a target. It is calculated by the quantitative balance between operation, limitation and controls.

The rav represents how much the attack surface is exposed. In this scale 100 rav is perfect balance and anything less is too few controls and therefore a greater attack surface. Move than 100 rav shows more controls than are necessary which itself may be a problem as controls often add interaction within a scope.

The rav does not measure risk for an attack surface. It can say where on a target it will be attacked, what types of attacks the target can successfully defend against, how deep an attacker can get, and how much damage can be done.

The rav will show the size of the attack surface in two practical ways.

The first way is in a straight calculation of the Delta, a number that describes the specific exposure of the target. This is useful for determining how a new person, thing or process will change the operational security of a new scope or as a comparison between multiple, single targets. This is also the easiest way to see Perfect Security, the perfect balance between Porosity, Controls and Limitation. This is a powerful tool for knowing exactly where and how resources are being spent to protect a particular target.

The second way to display the attack surface shows the big picture. This is represented as Actual Security. The calculation uses the Delta but also includes additional and redundant controls to provide a metric more people friendly and familiar. The rav representation is similar to using percentages. It is calculated with a base 10 logarithm. This will enable a quick and easy overview of the targets in the scope or of just a single target in relation to other targets.

What is a rav like?

The count is unique from the scope. For a rav, both the count and the operation are required. This is why the rav can only be derived from operation security testing. Analysts count and verify the operations of targets in a scope. They can record its interactions and the controls surrounding that integration. They classify them by operation, resources, processes and limitations. Those numbers the analysts generate are combined so that controls add to operational security and limitations take way from it.

Eight Fundamental Security Answers.

The real power of the rav is in how it can provided answers to the following eight fundamental security questions with great accuracy.

1. How much money should be spent on security? The rav will show the current amount of protection to make security projections and define milestones even before buying a particular solution or implementing some new process.

2. What should be protected first? The rav will show which particular part of the scope has the greatest porosity and the weakest controls. Comparison of needs and asset worth, a ratio of protection strength to value can be generated to decide exactly where to start.

3. What protection solutions do we need and how should we set them up for maximum effectiveness? A fully complete rav will show the 10 possible operational controls applied for each target and the limitations of those controls. Solutions can now be chosen based on the types of controls to be put in place.

4. How much improvement is gained by specific security procurement and processes?

A key feature of the rav is that you can make a Delta by mapping out the benefits and limitations of a particular solution for comparison prior to procurement.

5. How do we measure the periodic security efforts and improvements? With regular audits, the rav can be recalculated and compared to the older value.

6. How do we know if we are reducing our exposure to our threats? With specific knowledge of your controls you can easily tell what part or vector of the scope is weak to specific and unknown threats. Regular metric review will show any change in this map and can be done regularly. Then it is possible to gauge the cost each of those threats has on security by the expenditure on controls.

7. Can the rav tell us how well something resists attack? Technically, Yes. The more you can balance controls with interaction, the smaller the attack surface will be and the more capable the target will have to control known and unknown types of interactions.

8. Can the rav help me with regulatory compliance? Anything that helps you classify all Controls and Access points in a scope will help with compliance audits. Showing the OSSTMM STAR with its rav score will help you meet various compliance requirements of a third party audit and documentation.

How to make a rav

The rav requires a security test to count and analyze operations. The rav was originally designed for security tests, like the OSSTMM, where the auditor focuses on the behavior of the target rather than the configuration.

The minimum rav is made by the calculation of porosity which are the holes in the scope. The problem with security metrics in the determination of the assessors to count that can't possibly be known, does not exist in the rav, you make no assumptions surrounding what is not there.

Counting all that which is visible and interactive outside of the scope, allows for unauthenticated interaction between other targets in the scope. That becomes the porosity.

The next part is to account for the controls in place per target. This means going target by target and determining where any of the 10 controls are in place such as Authentication, Subjugation, Non-repudiation, etc. Each control provided 1/10th of the total controls needed to prevent all attack types. This is because having all 10 controls for each pore is functionally the same as closing the pore provided the controls have no limitations.

The third part of the rav is accounting for the limitations found in the protection and the controls. These are also known as vulnerabilities. The value of these limitations comes from the porosity and established controls themselves.

With all counts completes, the rav is basically subtracting porosity and limitations from the controls. This is most easily done with the rav spreadsheet calculator. The rav is designed to be minimally influenced by bad auditing or cheating by eliminating the direct scope size from the metric calculation.

To assure the most accurate rav is to have multiple tests over time and to make the counts and to be sure the auditor will take responsibility over the accuracy of the test. It is possible to take short-cut in testing and make a representative rav.

The end result is a calculation for Actual Security. It applies multiple controls of the same type to satisfy double-enforcement requirements like 2-factor Authentication. It also uses Log 10 to reduce large numbers into human manageable form. If you want to see the true balance where multiple controls of the same type are not measured, that calculation can be found under the heading of True Protection.

Combining Channels and Vectors

One important requirement in applying the rav is that Actual Security can only be calculated per scope. A change in channel, vector, or index is a new scope and a new calculation for Actual Security. Once calculated multiple scopes can be combined together in aggregate to create one Actual Security that represents a fuller vision of the operational security of all scopes.

Rav calculator A straight forward and skimpier way to make ravs is to use the specifically created spreadsheets to calculate the Attack Surface and various; popular required metrics form the test data. This spreadsheet is available at the ISECOM website. The Analyst need only enter the values into the empty, white boxes and the rest of the calculations will be handled automatically.

Turning test results into an Attack Surface measurement

Operational Security

The measurement of the Attack Surface requires the measurement of Visibility, Trust, and Access relative to the scope. The number of targets in the scope that can be determined to exist by direct interaction, indirect interaction, or passive emanations is its visibility. Trust is any non-authenticated interaction to any of the targets. Access is the number of interaction points with each target.

Category	Description
Visibility	The number of targets in the scope. Count all targets by index only once and maintain the index for all targets.
Access	The auditor counts each Access per unique interaction point per unique probe.
Trust	The auditor counts each Trust per unique interaction point per probe.

Controls

The next step in calculating the rav is to define the Controls; the security mechanisms put in place to provide assurance and protection during interactions.

Category	Description
Authentication	Count each instance of authentication required to gain access. This requires that authorization and identification make up the process for the proper use of the authentication mechanism.
Indemnification	Count each instance of methods used to exact liability and insure compensation of all assists within the scope.
Subjugation	Count for each instance of Access or Trust in the scope which strictly does not allow for controls to follow user discretion or originate outside of itself.
Continuity	Count each instance of Access or Trust in the scope which assures that no interruption in interaction over the channel and vector can be caused, even under situation of total failure.
Resilience	Count each instance of Access or Trust in the scope that does not fail open or provide new accesses upon security failure.
Non-repudiation	Count each instance for the Access or Trust that provides a non-repudiation mechanism for each interaction to provide assurance that particular interaction did occur at a particular time between the identified parties.
Confidentiality	Count each instance for Access or Trust in the scope that provides the means to maintain the contents of undisclosed interaction between the interacting parties.
Privacy	Count each instance for Access or Trust in the scope that provides the means to maintain the method of undisclosed interactions between the interacting parties.
Integrity	Count each instance for Access or Trust in the scope which can assure that the interaction process and Access to assets has finality and cannot be corrupted, stopped, continued, redirected or reversed without it being known to the parties involved.
Alarm	Count each instance for Access to Trust which has a record or makes a notification when unauthorized and unintended porosity increases for the vector or restrictions and controls are compromised or corrupted.

Limitations

Finally the limitations are verified where possible. The value of each limitation is dependent on Porosity and Controls. This is different from the more common risk perspective where a vulnerability may be assigned a risk level based on what damage it can do, how easy it is to do, and the distance in range for the attack.

Category	Description
Vulnerability	Count each flaw or error that defies protections whereby a person or process can access, deny access to others, or hide itself or assets within the scope.
Weakness	Count each flaw or error in the controls for interactivity; authentication, indemnification, resilience, subjugation and continuity.
Concern	Count each flaw or error in process controls: non-repudiation, confidentiality, privacy integrity and alarm.
Exposure	Count each unjustifiable action, flaw, or error that provides direct or indirect visibility of targets or assets within the chosen scope channel.
Anomaly	Count each unidentifiable or unknown element which cannot be accounted for in normal operations, generally when the source or destination of the element cannot be understood.

The Operational Security Formula

The rav is defined from 3 categories defined within the scope: Operational Security, Controls and Limitations. The first step is to aggregate and associate all input information into appropriate categories for each input variable.

The rav equation requires that each of the categories be assigned a logarithmic base value to scale the 3 factors of Actual Security in accordance with the scope.

Porosity Operational Security, also known as the scope's porosity, is the first of the three factors of actual security that should be determined. It is initially measures as the sum of the scope's Visibility, Access and Trust.

When calculating the rav is it however necessary to determine the Operational Security Base value.

The Controls Formula

The next step in calculating the rav is to define the Loss controls; the security mechanisms put in place to protect the operations. First the sum of the Loss Controls must be determined by adding together the 10 Loss Control Categories.

Class A

• Authentication
• Indemnification
• Resilience
• Subjugation
• Continuity

Class B

• Non-Repudiation
• Confidentiality
• Privacy
• Integrity
• Alarm

Missing Controls

Given that the combination of each of the 10 Loss Controls balances the value of 1 Opsec loss (Visibility, Access, Trust) it is necessary to determine the amount of Missing Controls, in order to assess the value of the Security Limitations. This must be done individually for each of the 10 Loss control categories. The missing Controls can never be less than zero.

The resulting missing controls must then be added to arrive at the total missing control value.

True Controls

True Controls is the inverse of Missing controls which means the True Controls for each individual control also need to be calculated before the results can be tallied. The resulting True Controls form each of the 10 loss controls must be added to arrive at the total True Control value. True Controls are used to measure the ideal placement of controls. The base value also helps to eliminate the influence of a disproportionate placement of controls on security.

True Coverage can also be used to measure the percentage of controls in place regarding the optimal amount and placement of controls.

Full controls

Full Controls; take into account all controls in place regardless of a balanced distribution. This value is important in measuring the worth of two factor authentication.

The Limitations Formula

The limitations are individually weighted. The weight of the Vulnerabilities, Weaknesses and Concerns are based on a relationship between the Porosity, the loss controls and in the case of Exposures and Anomaly the existence of other Limitations also plays a role. An Exposure or Anomaly poses no problems alone unless a Vulnerability, Weakness or Concern is also present.

A table is provided to calculate the Security Limitation Sum, as an intermediate step between the Security Limitations input and the Security Limitations base variable, which is the input of the rav equation

Security Limitations Base. The Security Limitations sum is calculated as the aggregate total of each input multiplied by its corresponding weighted values from the table mentioned

The Security Limitations Base is then calculated.

The Actual Security Formula

This is the final part for using all the previous calculations in three different ways.

Actual Security Delta.

The Actual Security Delta is useful for comparing products and solutions by previously estimating the change (delta) the product or solution would make in the scope. The Actual Security Delta is expressed as a formula.

True Protection

This can be used as a simplified expression for the optimal coverage of a given scope where 100 signifies an optimal relationship between the Porosity, True Controls and Security Limitations.

Actual Security

To measure the current state of operations with applied controls and discovered limitations, a final calculation is required to define Actual Security. As implied by its name this is the whole security value which combines the three values of Operational Security, Controls and Limitations to show the actual state of security.

Actual Security (total) is the true state of the security provided as a hash of all three sections. A rav of 100 signifies a perfect balance of security however the Actual Security is not a true percentage value. Score above 100 are possible which signifies that the tested scope has more controls implemented that necessary which could also be proof of overspending.

Chapter 5 Trust Analysis

Trust can be both a problem and a solution. It is a problem where it puts security in a compromising position. Trust creates a concentration of authorization which can explode into a big problem should the trust fail or the trusted target be deceived into harming the trust giver. However it can also reduce the need for continuous, possibly redundant re-authentication, increasing the efficiency of operations. For that reason trust is often seen as an "authenticate once and walk away “protocol. This is most often seen in Human Security where Human Resources departments research a candidate before the hire and afterwards that person has continuous access to resources until they are no longer an employee. Re-authentication is done sporadically and rarely at the same depth as when hired.

In operational security, Trust is merely a contributor to porosity, just another interaction to control. It differs from Access (the other form of Interaction), in how it relates to other targets within the scope. So where Access is interaction between two sides of a vector onto and out of the scope, Trust is measures as the interaction between targets within the scope. However, most people don't use trust concretely. Trust is usually applied to a specific person or item and a specific action. People lack the skills need to quantify the level of Trust, which would let them make a more rational and logical decision. To quantify Trust, we first need to understand it.

Understanding Trust

Trust is a decision, some people claim it an emotion, it is a complex quality of the human being. Unlike an emotion we choose to trust or not the trust based on how we feel about the target. We are capable to rationalize in a way to supersede how we feel about trusting. This means we can quantify it by applying a logical process. It also means we can assign trust values to objects and process as well as people based on that analysis. It further means Analysis with this skill can better control bias; identify fallacies (especially those from authorities or trusted sources, and handle unknowns for transparent reporting. One point to note however once the trust is quantified, it is only a vehicle of rationalizing the trust. It will not make something feel trustworthy now or in the future. Some People have strong feeling of aversion or attraction which may be at odds with the facts.

As a part of OpSec, Trust is one part of a target's porosity. It is wherever the target accepts interaction from other targets within the scope. People tend to use improper or incomplete operational controls with their trust like authentication. 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.

While using more controls works with objects and processes, it may not work between people. Many times social norms consider controls beyond simple authentication to be offensive.

Operation trust is measured as a negative thing which comes from an interaction between two entities in a scope. When a trust has no controls, it' a known as blind trust and is bad for operational security. People generally apply controls to trust even if they don't think of it. Some controls are inherently given more weight that others depending on the situation and the need. They are not actually giving more value to particular controls. Instead that are actually evaluating on the ten Trust Properties and looking for those specific controls for comfort to their Trust decisions.

The Trust Properties are the quantifiable, objective elements which are used to create Trust. We can say these properties give us "reason to trust". The properties are to be made into baseline rules based on the target and situation which we are verifying. Unfortunately, many illogical Trust Properties exist and are commonly in use which makes it more difficult for us to make proper Trust Decisions without it feeling wrong. However, it's exactly the feeling part which makes us more error prone. During research, many potential Trust Properties were discovered which are commonly in use and even official, Government and industry regulation recommend, however they failed log tests and were discarded from our set of properties leaving only ten.

Fallacies in Trust

Most people are bad at understanding and using Trust. Many illogical methods for Trust exist and are popularly used. Common fallacious, trust properties are Compos ability and Transitivity. These properties are most popularly used by people to make Trust Decisions about the unknown. People who often thrust "their gut" to make trust decisions are lauded when they are right as if they have some secret, powerful sense about other humans. However, other than luck, some people are better at paying attention to details, seeing emotional micro expressions in faces, and applying logic quickly to common situations. These people learned to do this naturally and built upon it with experience filled with trial and error not really obvious to themselves. The Trust Properties allow ordinary people who do not have this natural ability to analyze any of their Trust decisions with skill, distancing themselves from their own under developed "gut instinct" until they can recondition themselves to do so automatically, fluently, sharpen their instincts until they work "from the gut".

The Ten Trust Properties

The Ten Trust Properties to make proper trust analysis are:

Trust Property	Description
Size	The number to be Trusted
Symmetry	The vector (direction) of the Trust
Visibility	The level of transparency of all operational parts and processes of the target and its environment
Subjugation	Also called control, the amount of influence over the scope by the operator
Consistency	The historical evidence of compromise or corruption of the target
Integrity	The amount and timely notice of change within the target
Offsets	The offsets of sufficient assurance are compensated for the Trust giver or punishment for the Trust breaker
Value	The financial offset for risk, the amount of win or gain for which the risk of putting Trust in the target is sufficient to offset the risk of failure in the Trust
Components	The number of other elements which currently provide resources for the Target either through direct or indirect interactions
Porosity	The amount of separation between the target and the external environment

The Trust Rules

The properties on their own are useless if they cannot become quantifiable properties, objective, or understandable by the common person not necessarily involved in the security field. Therefore we need to turn the Trust properties into Trust Rules, Calculations of directly relevant operations made from all the Trust Properties. We do this in the form of questions where the answers are unbiased numbers which will be used to create a percentage for easier comprehension and which matches our common use of qualifiers of Trust in normal speech like almost, sometimes, always, and never.

When creating the Trust Rules from the Trust Properties it is important to note that Trust Decisions are not linear. There is no building towards Trust in a particular order or even an effort value system where it can be determined that one level requires more effort than another. In methodology terms, it appears irrational when calculated. A decision to Trust therefore may be concluded by an answer from just one of the following tests which makes up the Trust Rules. However, doing so is our conscious choice to make a Trust where the calculation specifically says not to. This may make most sense in a life or death situation where the result of trust worthiness is very low but the Value of Reward (one's life) is so incredibly great that no other choice can be made.

The Trust Rules must be created specifically for the target. While this may seem cumbersome, it is possible to make generically topic- specific Trust Rules which will suit the purpose. The benefit of this is that the Trust Properties can then be made onto rules fitting any purpose and any situation where one must make a Trust Decision on another person, thing process, system, or action. With practice, these Trust Rules can be made automatically and very quickly as part of one's decision process, focusing only on the rules which can be answered and discovering the ones where there can be no known answer with the information available.

The application of the Trust Rules onto specific verification tests that provide a quantity is good however ideally you need to determine a finite quantity. An infinite quantity may be too relative to the tester and does not provide the constraints necessary for expressing the result in a percentage. The resulting percentage for each trust rule can be viewed individually to show where controls must be applied to improve or maintain necessary levels of trust worthiness. This may also show where improvements must be made before a Trust can be considered. Another result from analyzing the percentages of individual Trust Rules is that unknowns become glaringly obvious because the less that is known, the lower the percentage will be. This means unknowns will be at or very close to 0%.

The end metric however is one which is the mean of all percentages. This provides a big picture understanding you could rationally have of the target of Trust. This is especially useful when it is difficult to make a Trust decision because of personal bias. Use of Trust Rules in formal security analysis as well as regular decision making can greatly minimize bias and mistakes. Therefore, the Analyst should be practiced in the skill so to be able to apply them quickly so that it can be used even in high-pressure or emergency situations where a snap decision is necessary and a wrong decision is tragedy.

Chapter 6 Work Flow

The OSTTMM flow begins with review of the target's posture. The posture is the culture, rules, norms, contracts, legislation, and policies defining the target. It ends with result comparisons to any alarms, alerts, reports, or access logs. This is a full-circle concept where the first step is to be aware of the operational requirements for interacting with the target, and the last step is the review of the records of the audit trail. For the Analyst, this is simply: you know what you need to do, you do it and then you check what you have done.

This methodology separates what needs to be done into this hierarchical format.

1. CHANNEL
2. MODULE
3. TASK

The work is described in the module description for each particular channel audit. Some audits apply to technologies which may straddle the border between two or more channels. This is why a properly defines testing plan is so important. The OSSTMM is fully capable of a "sidewalk to kernel' security review and therefore is completely capable of applying an analysis to a target whether its channels are clearly distinct and separate or comprised of multiple channels. Therefore, the Analyst should anticipate the need to define an audit to include multiple channels.

This methodology applies to all five channels. It has 17 modules and all the same properties apply to all five channels. While the methodology itself may be the same, each channel differs in task. Each module has an input and an output. This input is the information used in performing each task. The output is the result of completed tasks. This output may or may not be intelligence (analyzed data) to serve as an input for another module and this output may further serve as the input for more than one module or section. Therefore, failure to complete certain modules or task may limit the successful completion of other modules or task.

Some tasks yield no output, meaning that modules will exist for which there is no input. Modules which have no input can be ignored during testing but must be latter documented with an explanation for not having been performed. Tasks that have no resulting output can mean any of five things.

1. The channel was obstructed in some way during the performance of the tasks.
2. The tasks were not properly performed.
3. The tasks were not applicable.
4. The result data has been improperly analyzed.
5. The task reveals superior security.

In the OSSTMM, each module begins as an input and ends as an output exactly for the reason of keeping bias minimal. Therefore, each task gives a direction of what should be revealed to move to another point within the methodology.

A previous trust analysis may be incorporated to determine scope according to vector and channel. A trust analysis can also be used to predetermine which modules need to be performed as independent tests. However, remember that modules are part of a whole test and the assumption that any particular module can just be omitted is false and will lead to an improper test. It is important to communicate to the target owner exactly what of the scope has not or will not be tested. This manages expectations and potentially inappropriate risk assurances in the security of a system.

Testing time with the modules is relative to the plan. Determining the proper scope based on the vector is important because there may still be targets outside of the vector and still within the scope which will not make up the current testing scope. Overall, larger scopes with multiple channels and multiple vectors require more time spent on each module and its tasks. The amount of time allowed before returning with output data is not determined by the methodology and depends on the Analyst, the target, the test environment, and the test plan.

Methodology Flow

The OSSTMM does not allow for separation between what is considered active data collection and verification through agitation; because, in both cases, interaction is required. Nor does it differentiate between active and passive testing where active testing is the agitation to create an interaction with the target and passive testing is the recording, aggregation, and analysis of emanations from the target. This methodology requires both active and passive testing. Further more, the Analyst may not be able to differentiate between data collection passively from emanations of the operations and that which is the delayed or misdirected response to agitation. The introduction of any outside event, including the passive kind, has the potential to change the nature of the target's operations and lower the quality of an uninfluenced test on operational security. However, this does not represent a failure of the Analyst or the audit process, but simply an unavoidable evil of testing a system in a stochastic environment over a linear time frame.

The Memory of Operations

Tests in a stochastic environment over a linear time frame are affected by their own memory.

The Test Modules

To choose the appropriate test type, it is best to understand how the modules are designed to work. Depending on the thoroughness, business, time allotment, and requirements of the audit, the Analyst may want to schedule the details for the audit by phase.

There are four phases in the execution of this methodology:

A. Induction Phase B. Interaction Phase C. Inquest Phase D. Intervention Phase

Each phase lends a different depth to the audit, but no single phase is less important than another in terms of Actual Security.

A. Induction Phase

In the induction phase, the Analyst begins the audit with an understanding of the audit requirements, the scope, and the constraints to the auditing of this scope. Often, the test type is best determined after this phase.

Module	Description	Explanation
A.1	Posture Review	The review of the culture, rules, norms, regulation, legislation and policies applicable to the target know the scope and what tests must be done.
A.2	Logistics	The measurement of the interaction constrains such as distance, speed and fallibility to determine margins of accuracy within the results.
A.3	Active Detection Verification	The verification of the practice and breath of interaction, detection, response and response predictability.

B. Interaction Phase

The core of the basic security test requires knowing the scope in relation to interactions with the targets conveyed to interactions with assets. This phase will define the scope.

Module	Description	Explanation
B.4	Visibility Audit	The determination of the targets to be tested within the scope. Visibility is regarded as "presence" and not limited to human sight.
B.5	Access Verification	The measurement of the breadth and depth of interactive access points within the target and required authentication.
B.6	Trust Verification	The determination of trust relationships from and between the targets.
B.7	Control Verification	The measurement of the use and effectiveness of the process-based (class B) loss controls: non-repudiation, confidentiality, privacy and integrity. The control of alarm is verified at the end of the methodology.

C. Inquest phase

Much of security auditing is about the information that the Analyst uncovers. In this phase, the various types of values or the determinant from misplaces and mismanaged information as assets are brought to light.

Module	Description	Explanation
C.8	Process Verification	The determination of the existence and effectiveness of the record and maintenance of existing actual security levels or diligence define by the posture review and indemnification controls.
C.9	Configuration Verification /Training Verification	The research of the steady state (normal operations) of the targets as they have been designed to operate under normal conditions to determine underlying problems outside of the application of security stress tests.
C.10	Property Validation	The measure of the breadth and depth in the use of illegal or unlicensed intellectual properly or applications within the target.
C.11	Segregation review	A determination of the levels of personally identifiable information defined by the posture review.
C.12	Exposure Verification	The search for freely available information which describes indirect visibility of targets or assets within the chosen channel of the scope.
C.13	Competitive Intelligence Scouting	The search for freely available information, directly or indirectly, which could harm or adversely affect the target owner through external, competitive means.

D. Intervention Phase

These tests are focused on the resources the targets require in the scope. Those resources can be switched, changed, overloaded, or starved to cause penetration or disruption. This is often the final phase of a security test to assure disruptions do not affect responses of less invasive tests and because the information for making these tests may not be know until other phases have been carried out.

Module	Description	Explanation
D.14	Quarantine Verification	The determination and measurement of effective use of quarantine for all access to and within the target.
D.15	Privileges Audit	The mapping and measurement of the impact of misuse of subjugation controls, credentials and privileges or the unauthorized escalation of privilege.
D.16	Survivability Validation / Service Continuity	The determination and measurement of the resilience of the target to excessive or adverse changes where continuity and resilience controls would be impacted.
D.17	Alert and Log Review /End Survey	A review of audit actives performed with the true depth of those activities as recorded by the target or from a third-party as in the control of alarm.

One Methodology

Putting all the modules together provides one methodology to know and work with. This is one methodology which is applicable to any and all types of security tests. Whether the target be a particular system, a location, a person, a process, or thousands of them, this one methodology will assure the most thorough and efficient test possible.

Chapter 7 Human Security Testing

Human Security (HUMSEC) is a sub-section of PHYSSEC and includes Psychological Operations (PSYOPS). Testing this channel Requires interaction with people in gatekeeper positions of assets.

This channel covers the involvement of people, primarily the operating personnel with the target scope or framework. While some services consider this simply as "social engineering", the true compliance objective of security testing in this channel is personal security awareness testing and gap measurement to the required security standard outlines in company policy, industrial regulations, or regional legislation.

Competent Analysts will require both diligent people skills and critical thinking skills to assure factual data collection creates factual results through correlation and analysis.

Considerations 1. In persona: Target those personnel who are under direct legal contract with the scope owner. 2. Plausible deniability: No direct personnel security testing will take place for personnel who have not been trained, informed. 3. Human right: where personnel to be tested are randomly chosen or are not said to have job responsibilities directly related to gate keeping, Security, or safety, the Analyst will refrain from personally identifying the person. 4. Incommunicado: Personnel given time will discuss the action of the test with others and alter the course of the testing.

Posture Review

Initial studies of the posture include the laws, ethics, policies, industrial regulation, and political culture which influence the security and privacy requirements for the scope.

7.1.1 Policy

Review and document appropriate organizational policy in the scope.

7.1.2 Legislation and Regulations

Review and document appropriate regional and national legislation and industrial regulation regarding security requirements in the scope.

7.1.3 Culture

Review and document appropriate organizational culture in the scope.

7.1.4 Relationships

Review and document the appropriate influential relationships in the environment in which the scope resides.

7.1.5 Regional Culture

Review and document the appropriate influence of regional and foreign cultures in the environment in which the scope resides.

7.1.6. Economics

Review and document the appropriate influence of economics and pay scale on the social status of personnel in the scope.

Logistics

Preparation of the channel test environment needed to prevent false positives and false negatives which lead to inaccurate test results.

7.2.1 Communications Equipment

Test of communications that provide identification to the receiver.

7.2.2 Communications

Test which languages are used within the scope.

7.2.3 Time

Test of the time zone, holidays, and work schedules within the scope.

7.3 Active Detection Verification

Determination of active and passive controls to detect intrusion to filter or deny test attempts must be made prior to testing to mitigate the risk of creating false positives and negatives in the test result data as well as changing the alarm status of monitoring personnel or agents.

7.3.1 Channel Monitoring

Test whether help desk or support channels are monitored by a third party for quality control.

7.3.2 Channel Moderating

Test whether help desk or support channels are filtered or quarantined.

7.3.3 Supervision

Test whether support personnel may answer request without confirmation.

7.3.4 Operator Assistance

Test what access to which personnel must be made through an operator.

Visibility Audit

Enumeration and Verification test for the visibility of personnel with which interaction is possible via all channels.

7.4.1 Access Identification

Test for channels which provide interactions with personnel from outside the scope.

7.4.2 Personnel Enumeration

Enumerate the number of personnel within the scope with both authorized and unauthorized access to process within the scope.

Access Verification

Test for the enumeration of access points to personnel within the scope.

7.5.1 Access Process

Map and explore the use of channels onto the scope to reach assets.

7.5.2. Authority

Use personnel in positions of authority with access-control or who hold gatekeeper positions to assets within the scope.

7.5.3 Authentication

Enumerate and test for inadequacies from gateway personnel to assure that only intended parties are provided access.

Trust Verification

Test for trusts between personnel within the scope.

7.6.1 Misrepresentation

Test and document the depth of requirements for access to assets within the scope with the use of misrepresentation.

7.6.2 Fraud

Test and document the depth or requirements for access to assets within the scope with the use of fraudulent representation.

7.6.3 Misdirection

Test and document the depth of requirements for access within the scope with the use of misrepresentation as a member of support or delivery personnel from outside the scope.

7.6.4 Phishing

Test and document the depth of requirements for access with the use of a fraudulent gateway where personnel are asked to supply credentials.

7.6.5 Resource Abuse

Test and document the depth of requirements to take assets outside of the scope.

7.6.6 In Terrorem

Test and document the depth of requirements to incite fear, revolt, violence, and chaos through psychological abuse.

Controls Verification

Tests to enumerate types of loss controls used to protect the value of assets.

7.7.1 Non-repudiation

Enumerate and test for inadequacies to properly identify and log access or interactions to assets.

7.7.2 Confidentiality

Enumerate and test for inadequacies in interactions to protect the confidentiality of the information assets.

7.7.3 Privacy

Enumerate and test for inadequacies in interactions to protect the privacy of process, information, or physical assets.

7.7.4 Integrity

Enumerate and test for inadequacies in protecting and assuring that information or physical assets cannot be changed, switched, redirected, or reversed without being known to parties involved.

Process Verification

Test to examine the maintenance of functional Security awareness of personnel in established processes due diligence as defined in the Posture Review.

7.8.1 Maintenance

Examine and document the processes for the notification and security awareness of all personnel in regards to operations security, actual security, and loss controls.

7.8.2. Misinformation

Determine the extent to which personnel security notifications and security news can be expanded or altered with misinformation.

7.8.3 Due Diligence

Map and verify any gaps between practice and requirements as determined in the Posture review through all channels

7.8.4 Indemnification

Document and enumerate the abuse or circumvention of employee policy, insurance, non-disclosure, non-compete, liability contracts, or use/user disclaimers within the scope.

Training Verification

Test to examine the ability to circumvent or disrupt functional security awareness education and training.

7.9.1 Education Mapping

Map types and frequency of security awareness assistance, education courses, and training provided.

7.9.2 Policy Disruption

Discover and examine the process and depth of self-policing for the disruption or non-confirmation of security policy.

7.9.3 Awareness Mapping

Map the limitations discovered in security awareness training.

7.9.4 Awareness Hijacking

Discover and examine the extent to which a non-official person provided misinformation to purposely circumvent or break security policy

Property Validation

Test to examine information and Physical property within the scope which may be illegal or unethical.

7.10.1 Sharing

Verify the extent to which individual licensed, private, faked, reproduced, non-free, or non-open property is shared.

7.10.2 Black Market

Verify the extent to which individually licenses, private, faked, reproduced, non-free or non-open property is promoted, marketed, or sold.

7.10.3 Sales Channels

Verify public, out of scope businesses, auctions, or property sales which provide contact information through channels originating within the scope.

Segregation Review

Tests of appropriate separation of private or personal information assets from business information.

7.11.1 Privacy Containment Mapping

Map gatekeepers of private information assets within the scope.

7.11.2 Evident Information

Enumerate and map information regarding individual gateway personnel.

7.11.3 Disclosure

Examine and document types of disclosures of private information assets as determined in the Posture review and the basic human rights to privacy.

7.11.4 Limitations

Examine and document types of gateways accessible to people with physical limitations within that channel.

Exposure Verification

Tests for uncovering information which provide for leads to authenticated access or allows for unintended access to multiple locations.

7.12.1 Exposure Mapping

Enumerate and map personnel information regarding any particular organizational information stated implicitly as confidential in regulations and policy.

7.12.2 Profiling

Profile and verify the organization, employees’ skill requirement types, pay scales, channel and gateway information, technologies, and direction.

Competitive Intelligence Scouting

Test for scavenging property that can be analyzed as business intelligence.

7.13.1 Business Grinding

Map gatekeepers of business assets within the scope.

7.13.2 Business Environment

Explore and document from individual gateway personnel any particular business information or property stated implicitly as confidential in regulations and policy.

7.13.3 Organizational Environment

Examine and document types of disclosures of business assets from gatekeepers any particular organizational assets stated implicitly as confidential in regulations and policy.

Quarantine Verifications

Test for verifying the proper fielding and containment of aggressive or hostile contacts at the gateway points.

7.14.1 Containment Process Identification

Identify and examine quarantine methods and process at the gateways in all channels for aggressive and hostile contacts.

7.14.2 Containment Levels

Verify the state of containment, length of time, and all channels where interaction with gatekeepers has quarantine methods.

Privileges Audit

Test where credentials are supplied to the user and permission is granted for testing with those credentials.

7.15.1 Identification

Examine and document the process for obtaining identification through both legitimate and fraudulent means on all channels.

7.15.2 Authorization

Verify the use if fraudulent authorization on all channels to gain privileges similar to that of other personnel.

7.15.3 Escalation

Verify and map access to assets through the use of privileges to gain higher or more extensive privileges beyond that which is authoratively designed to the role.

7.15.4 Discrimination

Verify information requested and privileges granted from gatekeepers incases which may be discriminated against in accordance to the Posture review.

7.15.5 Subjugation

Enumerate and test from inadequacies of assets communicated over channels where those controls are not required, can be circumvented or ignored.

Service Continuity

Determining and measuring the resilience of the gatekeepers within then scope to changes designed to cause service failure.

7.16.1 Resilience

Enumerate and test for inadequacies on all channels within the scope whereby removing or quieting gateway personnel will allow for direct access to assets.

7.16.2 Continuity

Enumerate and test for inadequacies with regard to assess delays and services response time for access to alternate gateway personnel.

7.16.4 Safety

Map and document the process of gatekeepers disconnecting channels due to evacuation or safety concern as a gap analysis with regulation and security policy.

End Survey

A gap analysis between activities performed with the test and the true depth of those actives as recorded or from third party perceptions both human and mechanical.

7.17.1 Alarm

Verify and enumerate the use of a localized or scope-wide warning system, log or message for each access gateway over each channel when a suspect situation is noted by personnel upon suspicion of circumvention attempts, social engineering, or fraudulent activity.

7.17.2 Storage and Retrieval

Documents and verify the privileged and efficient access to alarm, log, and notification storage locations and property.

Chapter 8 - Physical Security Testing

PHYSSEC (Physical Security Testing) is a classification for the material security within the physical realm which is within the limits of human-interactive 3D space. Testing this channel requires non-communicative interaction with barriers and human gatekeeper positions of assets.

This channel covers the interaction of the Analyst within proximity of the targets. While some services consider this simply as “breaking and entering", the true compliance objective of security testing in this channel is physical and logical barrier testing and gap measurement to the required security standard as outlined in company policy, industry regulations, or regional legislation.

Considerations Please note the following considerations to assure a safe, high quality test:

1. Conatus: All attempts to traverse physical barriers require an unbiased judgment of the amount of difficulty required reaching and interacting with the target and the danger involved.

2. Ecce hora: All physical tests require close attention be made to time.

3. Abuse of Discretion; The Analyst must take care not to ignore or misinterpret the results from testing a physical barrier or obstacle because it is not within the range of the Analyst's physical possibilities.

4. Magister pecuarius: The Analyst should not dismiss the reasonable potential of an attacker using trained animals to circumvent barriers and obstacles where a human being cannot.

5. Plausible deniability: No direct or physical personnel security testing will take place for personnel who have not been trained, informed, or can be said to possess security awareness experience or obligations due to job responsibility requirements.

6. Sui generis; All interaction with physical barriers will leave record of this interactivity and, in more extreme cases, may weaken or destroy the barrier.

Posture Review

Initial studies of the posture include the laws, ethics, policies, industry regulations, and political culture which influence the security and privacy requirements for the scope. This review forms a matrix to which testing should be mapped but not constrained.

8.1.1 Policy

Review and document appropriate organizational policy regarding security, safety, integrity (i.e. supply chain), and privacy requirements for barriers in the scope.

8.1.2 Legislation and Regulations

Review and document appropriate regional and national legislation and industry regulations regarding the security and privacy requirements in the scope as well outside the scope.

8.1.3 Culture

Review and document appropriate organizational culture in the scope towards security and privacy awareness.

8.1.4 Relationships

Review and document the appropriate influential relationship between personnel within the scope.

8.1.5 Regional Culture

Review and document the appropriate influence of regional and foreign cultures in the environment in which the scope resides.

8.1.6 Economics

Review and document the appropriate influence of economics and pay scale on social status and criminal intent on personnel within the scope and that of the outside community in which the scope resides.

8.1.7 Environment

Review for the target region the weather patterns.

Logistics

Preparation of the channel test environment needed to prevent false positives and false negatives which lead to inaccurate test results.

8.2.1 Environment

(a) Examine the scope to determine if any special equipment is required for the environment of the targets.

(b) Verify damaged safety equipment.

(c) Examine the targets for hazardous, contaminated, or poorly maintained terrain, air, water, buildings, or structures.

(d) Examine noise, electromagnetic radiation, and magnetic field levels at the scope.

8.2.2 Communications

(a) Test which languages are used within and outside the scope.

(b) Examine the means of communication between personnel.

8.2.3 Time

(a) Test for the time zone, holidays, and work schedules within the scope.

(b) Determining if decreased mobility or visibility will have an impact upon operations at the target.

Active Detection verification

Determination of active and passive controls to detect intrusion to filter or deny test attempts must be made prior to testing to mitigate the risk of creating false positives and negatives in the test result data as well as change the alarm status of monitoring personnel or agents.

8.3.1 Monitoring

(a) Verify that the scope is monitored by a third party for intrusion.

(b) Determine the range of the monitoring and whether the travel of a threat to the target can be intercepted in a timely manner.

(c) Verify if travel to the target requires increased time on target and exposure.

(d) Verify that the lighting and visible contrast on approach to the target allows for interception of threats.

8.3.2 Reacting

(a) Verify if interactive controls for the target will react extreme environmental conditions according to the environment review task of the Posture Review.

(b) Verify if the target will react to a disturbance in air, water, and soil quality.

(c) Verify if the target will react to critical noise disturbances

(d) Verify if the target will react to magnetic field disturbances.

(e) Verify if the target will react to fires.

(f) Verify if the target will react to denial of target access via blockade or quarantine.

(g) Verify if the target will react to threats of fear revolt or violence within the scope

(h) Determine the finality of threat interception.

Visibility Audit

(a) Map and detail the scope perimeter.

(b) Enumerate and details targets and assets visible from outside the scope.

(c) Enumerate and detail target traffic patterns, foot traffic, occupied areas and sensors visible outside the scope.

(d) Enumerate directories and internal telephone books identifying locations of sensitive information processing facilities.

(e) Map and enumerate the physical location and layout of the targets, the size and navigability of obstacles, barriers, and hazards which will increase time on target.

Access Verification

Tests for the enumeration of access points to interact with the targets and assets within the scope. While access to walls and fences bordering property outside of the scope is a real scenario and one often used in an attack, this audit is limited to scope-only interaction to protect property rights of third parties.

8.5.1 Enumeration

(a) Map and explore the navigable of terrain into the scope to reach the targets and assets.

(b) Map and verify all access points that allow stealthy or unmonitored, direct interaction with the target.

(c) Verify the size and navigable of public and private access points and all paths to target.

8.5.2 Authentication

(a) Enumerate and test form inadequacies which privileges are required to access.

(b) Verify the process of authenticating which items may be taken into the scope.

(c) Verify the process of authenticating which items may be taken out of the scope.

(d) Verify the process of recording access and which items were entered and removed.

8.5.3. Location

(a) Map the distance from the scope perimeter to the visible targets and assets from outside the scope.

(b) Map and identify all paths to access points which can be reached in a noisy, not stealthy, direct (3 Seconds or less time on target) interaction with that access point.

8.5.4 Penetration

(a) Determine which barriers and obstacles in the scope provide remote access to change, disrupt, destroy or obtain assets.

(b) Determine the effectiveness of barriers and obstacles to withstand conditions defines in the Posture Review.

(c) Determine and rate the effectiveness of barriers and obstacles to withstand fire, explosions, and general concussive forces.

(d) Determine and rate the effectiveness of barriers and obstacles to reduce incoming: critical noise levels, heat, cold, smoke, humidity, disruptive or caustic odors, intense magnetic fields, harmful light, and pollutants.

(e) Determine and rate the effectiveness of barriers and obstacles to render outgoing; sounds, smells, vibrations, conditions for acclimatization, smoke, magnetic fields, waste, and pollutants.

Trust Verification

Test for trusts between processes within the scope where trust refers to access to assets without the need for identification or authentication.

8.6.1 Misrepresentation

(a) Test and document for access to assets with the use of misrepresentation.

(b) Test and document for access to assets with the use of misrepresentations as a disabled person.

8.6.2. Fraud

Test and document for access to assets with the use of fraudulent representation of authority as a member of the management or other key personnel.

8.6.3 Misdirection

Test and document for access to assets with the use of misrepresentation as a member of support or delivery personnel outside then scope.

8.6.4 Stowage

Test and document for access to assets through stealthy stowage with a transport of support or delivery to take the stowage outside the scope.

8.6.5 Embezzlement

Test and document to hide assets within the scope, take assets outside, and throughout the scope itself to other personnel without any established, required credentials.

8.6.6. In Terrorem

Test and document to incite fear, revolt, violence, and chaos.

Controls Verification

Tests to enumerate types of loss controls used to protect the values of assets.

8.7.1 Non-repudiation

Enumerate and test from monitors and sensors to properly identify and log access or interactions with assets for specific evidence to challenge repudiation.

8.7.2 Confidentiality

Enumerate and test from all signals, physical communication, and transported items between both internal and external-reaching processes and personal interactions to promote the confidentiality of the communication only to those with the proper security clearance .

8.7.3 Privacy

Enumerate and test from all interactions within the scope to hide or protect the privacy of the interaction and only to those with the proper security clearance.

8.7.4 Integrity

(a) Enumerate and test for all signals and communication between processes and personnel to protect and assure that assets cannot be changed, redirected, or reversed without being known to the parties involved.

(b) Enumerate and test in all processes and interactions with assets in transport to protect and assure that the assets cannot be changed, redirected or reversed without being known to the parties involved.

(c) Verify all storage mediums for information are not in danger from unnatural decay.

Process Verification

Test to examine the maintenance of functional security operations in established processes and due diligence as defined in the Posture Review.

8.8.1 Maintenance

(a) Examine and document the timeliness, appropriateness, access to, and extent of processes for equipment and barrier repair.

(b) Verify the repair and determine the extent to which notice and quality of repairs can be misrepresented and falsified.

8.8.2 Indemnification

(a) Document and enumerate the ability to abuse or circumvent employee policy, insurance, non-disclosure, non-compete, liability contracts, or use/user disclaimers for personnel within the scope.

(b) Enumerate the use of signs warning of danger, surveillance or alarms in effect, health issues, and posting of no entrance.

(c) Verify the extent and finality of legal action used to uphold indemnification.

Configuration Verification

Tests to examine the operation of processes under various levels of security conditions. Understanding how processes work under daily routine and efficiencies provides insight to how they should behave under more extreme conditions.

8.9.1 Education Mapping

Map types and frequency of physical security and safety assistance, education courses, and training provided to personnel, partners, customers, and specifically to gatekeepers.

8.9.2 Policy Disruption

Discover and examine the process and depth of self-policing for the disruption or non-conformity of physical and safety policy.

8.9.3 Threat Conditions

(a) Map the ready responses of security processes in reaction to increased threat condition levels as per requirements determined in the Posture Review.

(b)Determine which triggers are required to increase threat levels.

(c) Map the ready responses of security processes in reaction to decreased threat condition levels as per requirements determined in the Posture review.

(d) Discover and examine the extent to which a non-official person provides misinformation regarding threat levels in an authority’s manner to purposely rise or lower ready status.

Property Validation

Tests to examine physical property available within the scope or provided by personnel who may be illegal or unethical.

8.10.1 Sharing

Verify the extent to which personal assets or those of the organization have been faked, reproduced, or shared illegally and intentionally according to the requirements of the Posture review.

8.10.2 Black market

Verify the extent to which personal assets or those of the organization have been faked or reproduced and are being promoted, marketed, or sold between personnel or by the organization.

8.10.3 Sales Channels

Verify assets in auctions, flea markets, want-ads, yard sales, swap meets, or property sales which provide contact information through channels originating within the scope.

8.10.4 Storage

(a) Verify storage locations and small caches of organizational assets are in the appropriate location within the scope.

(b) Verify storage locations and small caches of organizational assets for use or sale publicly or to other members of the organization are not being deliberately hidden, hoarded, controlled, or saved.

8.10.5 Resource abuse

(a) Enumerate personal items which consume power, fuel, food, water, or other assets within the requirements defined in the Posture review.

(b) Enumerate personnel items using channels which are the property of the organization.

(c) Enumerate openly viewable personal items which symbolize beliefs not within the requirements defined in the Posture review.

Segregation Review

Tests for appropriate separation of private or personal information property from business information.

8.11.1 Privacy Containment Mapping

Map storage locations of private information property within the scope.

8.12.1 Evident Information

Enumerate and map the target documents and physical property with unsecured personal information as defined implicitly as private in regulations and policy of the Posture review.

8.13.1 Disclosure

Verify access to stores of private information property of personnel as determined in the Posture Review.

8.11.4 Offensive Materials

Verify openly viewable personal property does not flaunt or offend as determined offensive or private in the Posture Review.

Exposure Verification

Tests for uncovering information which provides for or leads to authenticated access or allows for access to multiple locations with the same authentication.

8.12.1 Exposure mapping

Discover and enumerate unsecured documents and items with building information regarding the organization.

8.12.2 Profiling

(a) Profile and verify the structural definition of the targets.

(b) Discover and enumerate access control sensors, cameras, monitors, man-traps, cages, gates, fences, etc for type, technology, maker, materials, and security or safety properties.

Competitive Intelligence Scouting

Test for scavenging property that can be analyzed as business intelligence.

8.13.1 Business Grinding

Discover and map storage locations of business properly within the scope.

8.13.2 Business Environment

Discover and enumerate documents and items with organizational details any particular business information or property determined implicitly as confidential or non-compete from the Posture Review.

8.13.3 Organizational Environment

Discover and enumerate documents and items with organizational details and any particular organizational property stated implicitly as confidential or non-compete from the Posture Review.

8.13.4 Operational Environment

Discover and enumerate processes which expose operational details and any particular operational property stated implicitly as confidential or non-compete from the Posture review.

Quarantine Verification

Tests for verifying the proper fielding and containment of people and processes with aggressive or hostile intent within the scope.

8.14.1 Containment Process Identification

(a) Identify and examine physical quarantine methods and processes within the scope for aggressive and hostile contacts.

(b) Identify and examine physical quarantine methods and processes within the scope for managing dangerous and harmful items or substances, illegal substances, and illegally removed company property.

(c) Identify and examine physical quarantine methods and processes within the scope for merely suspicious behavior.

8.14.2 Containment Levels.

(a) Verify the state of containment location, length of time, and process of the quarantine method.

(b) Verify proper procedures are followed for a full lock-down as per the requirements in the Posture Review for environmental threats, biological, chemical, or other contamination threats and in cases of workplace violence.

(c) Verify proper procedures for quarantine recovery and return to the proper secure state following a state of lock-down as per the requirements in the Posture Review.

Privileges Audit

Test for gaining access credentials and privileges as supplied to other personnel with the appropriate permissions.

8.15.1. Identification

Examine and document the process for obtaining identification through legitimate, illegal and fraudulent means.

8.15.2 Authorization

Verify the use of fraudulent authorization to gain privileges similar to that of other personnel.

8.15.3. Escalation

Verify and enumerate accesses to assets through the use of privileges to gain higher privileges to that of gatekeepers.

8.15.4 Special Circumstances

Verify gaining access privileges as requested in cases where, relationship, sex, race, custom/culture and religion are factors which may be granted special circumstances to discrimination against in accordance to the Posture Review.

8.15.5 Subjugation

Enumerate and test for inadequacies in access to assets not controlled by the source providing the access.

Survivability Validation

Determine and measure the resilience of the barriers and guards within the scope to excessive or hostile changes designed to cause operations failure.

8.16.1 Resilience

(a) Enumerate and verify that the distraction, removal or quieting of gateway personnel will not allow for direct access to assets or operations.

(b) Enumerate and verify that the disabling or destruction of operational security measures or controls will not allow for direct access to assets or operations

(c) Verify that the isolation of the scope from resources does not allow for direct access or operations.

(d) Verify that high alert threats conditions do not shut down or minimize operational security measures or controls.

8.16.2 Continuity

(a) Enumerate and verify conditions where access delays are properly addressed for access to services, processes and operations.

(b) Enumerate and verify that the distraction, removal or quieting of gateway personnel will not halt or deny access to services, processes and operations.

(c) Enumerate and verify that the disabling or destruction of operational security measures or controls will not deny access to services, process, and operations.

(d) Verify that the isolation of the scope from resources will not halt or deny access to services, processes and operations.

(e) Verify that the inabilities to remove waste, pollutants, or other contaminants from the scope will not halt or deny access to services, processes and operations.

(f) Verify that high alert threat conditions do not halt or deny access to services, processes and operations.

Alert and Log Review

A gap analysis between activities performed with the test and the depth of those activities as recorded or from third-party perceptions, both human and mechanical.

8.17.1 Alarm

Verify and enumerate the use if a localized or scope-wide warning system, log message for each access gateway where a suspect situation is noted by personnel upon suspicion of circumvention attempts, fraudulent activity, trespass, or breach.

8.17.2 Storage and Retrieval

Document and verify the permissions and efficient access to alarm, log, and notification storage locations and property.

Chapter 9 Wireless Security Testing

Spectrum security (SPECSEC) is the security classification which includes electronics security (ELSEC), signal security (SIGSEC), and emanations security (EMSEC). ELSEC are the measures to deny unauthorized access to information derived from the interception and analysis of non-communications electromagnetic radiations. SIGSEC are the measures to protect wireless communications from unauthorized access and jamming. EMSEC are the measures to prevent the machine emanations that, if intercepted and analyzed, would disclose the information transmitted, received, handled, or otherwise processes by information systems equipment. Testing this channel requires interaction with barriers to assets over Electromagnetic (EM) and Microwave (MW) frequencies.

This channel covers the interaction of the Analyst within proximity range of the targets. While some services consider this simply as "scanning", the true compliance objectives of security testing in this channel are physically and logical barrier testing and gap measurement to the required security standard outlined in company policy, industry regulations, or regional legislation.

Competent Analysts will require sufficient knowledge of EM and MW radiation and critical thinking skills to assure, factual data collection creates factual results thought correlation and analysis.

Considerations

1. Ignorantia legis neminem excusat: Analysts who do not do proper posture review for the scope as well as the regions targeted for business or interactions may not escape punishment for violating laws merely because they were unaware of the law; that is Analysts have presumed knowledge of the law.

2. In personam: Testing must specifically target only SPECSEC from personnel who are under direct legal contract with the scope owner, computer systems on then property of the scope owner, and EM or MW signal or emanations of power level great enough to disrupt or harm wireless communications within the scope.

Posture review

Initial studies of the posture include the laws, ethics, polices, industry regulation, and political culture which influence the security and privacy requirements for the scope.

9.1.1 Policy

Review and document appropriate organizational policy regarding security, integrity, and privacy responsibilities of the scope.

9.1.2 Legislation

Review and document appropriate regional and national legislation and industry regulations regarding the security and privacy requirements of the organization.

9.1.3 Culture

Review and document appropriate organizational culture in the scope towards security and privacy awareness.

9.1.4 Age

Review and document the age of systems, software, and services applications required for operations.

9.1.5 Fragile Artifacts

Review and document any systems, software, and service applications which require special care due to high use, instabilities, or a high rate of change.

Logistics

Preparation of the channel test environment needed to prevent false positives and false negatives which lead to inaccurate test results.

9.2.1 Communication Equipment

Test of equipment which may transmit electromagnetic radiation.

9.2.2 Communications

Test which protocols are used within the scope and methods of transmission.

9.2.3 Time

Test for the time frame of equipments operations.

Active Detection Verification

Determination of active and passive controls must be made prior to testing to mitigate the risk of creating false positives and negatives in the test result data as well as changing the alarm status of monitoring personnel or agents.

9.3.1 Channel Monitoring

Test whether controls are in place for monitoring intrusion or signal tampering.

9.3.2 Channel Moderation

Test whether controls are in place to block signals (jamming) or alert for unauthorized activities.

Visibility Audit

Enumeration and verification tests for the visibility of personnel with which interaction is possible via all channels.

9.4.1 Interception

Locate Access control, Perimeter Security, and ability to intercept or interfere with wireless channels.

9.4.2 Passive Signal detection

(a) Determine which frequencies and signals can leak into or out of the target area.

(b) Create a heat map of the scope.

(c) Test for sources that interact without authorization.

(d) Collect information broadcast by these sources.

(e) Map all found data to the emission limit values currently required in the region.

9.4.2 Active Signal Detection

Examine which frequencies or electromagnetic signal broadcasts trigger responses such as that from RFID or other interactive wireless sources.

Access Verification

Tests of the enumeration of access points to personnel within the scope.

9.5.1 Evaluate Administrative access to wireless devices

Determine if access points are turned off during portions of the day.

9.5.2 Evaluate device configuration

Test and document using directional and high-gain antennas that wireless devices are set to the lowest possible power setting.

9.5.3 Evaluate Configuration, Authentication, and encryption of wireless networks.

9.5.4 Enumerate and test for inadequacies in authentication and authorization methods.

9.5.5 Access Controls

Evaluate access controls, perimeter security, and ability to intercept or interfere with communication.

Trust Verification

Tests for trusts between personnel within the scope where trust refers to access to information or physical property without the need for identification or authentication.

9.6.1 Misrepresentation

Test and document the authentication-method of the clients.

9.6.2 Fraud

Test and document the depth of requirements for access to wireless devices within the scope with the use of fraudulent credentials.

9.6.3 Resources Abuse

Test and document the depth or requirements to send the property outside of the scope without any established or required credentials.

9.6.4 Blind Trust

Trust and documents the connections that are made to a false or compromised receiver.

Control Verification

Test to enumerate types of loss controls used to protect information.

9.7.1 Non-repudiation

Enumerate and test from daemons and systems to properly identify and log access or interactions for evidence to challenge repudiation.

9.7.2 Confidentiality

Enumerate and test for use of equipment to damper Electromagnetic transmission.

9.7.3 Privacy

Determine the level of physical access controls to access points and devices controlling them.

9.7.4 Integrity

Determine that data can only be accessed and modified by those that are authorized and ensure that adequate encryption is in use.

Process Verification

Test to examine the maintenance of functional security awareness of personnel in established processes.

9.8.1 Baseline

Examine and document the baseline configuration to ensure the security stance is in-line with the security policy.

9.8.2 Proper Shielding

Examine and determine that proper shielding is in place.

9.8.3 Due Diligence

Map and verify any gaps between practice and requirements as determined in the Posture Review.

9.8.4 Indemnification

Document and enumerate that targets and services which are protected from abuse or circumvention of employee policy, are insured for theft or damages, or use liability and permission disclaimers.

Configuration Verification

Test to examine the ability to circumvent or disrupt functional security in assets.

9.9.1 Common Configuration errors

Perform brute force attacks against access points to discern the strength of passwords.

9.9.2 Configuration Controls

Examine controls, including baseline configuration, to validate configurations are according to the security policy.

9.9.3 Evaluate and test wiring and emissions

Verify that all wiring feeds into and out of shielded rooms are made of fiber, where possible.

Property Validation

Test to examine information and physical property available within the scope which may be illegal or unethical.

9.10.1 Sharing

Verify the extent to which individually licensed, private, faked, reproduced, non-free, or non-open property is shared.

9.10.2 Rogue Wireless Transceivers

Perform a complete inventory of all wireless devices.

Segregation Review

Tests for appropriate separation of private or personal information property from business information.

9.11.1 Privacy Containment mapping

Map gatekeepers of private information within the scope.

9.11.2 Evident Information

9.11.3 Disclosure

Examine and document types of disclosure of private information in wireless spectrum.

9.11.4 Limitations

Examine and document types of gateways and channel alternatives accessible to people with physical limitation.

Exposure Verification

Test for information which leads to authenticated access.

9.12.1 Exposure Mapping

Enumerate and map personnel information regarding the organizational information stated implicitly as confidential in regulations and policy.

9.12.2 Profiling

Examine and verify if wireless signals with information regarding the device are extending out past the targets walls or property.

Competitive Intelligent Scouting

Tests for scavenging property that can be analyzed as business intelligence.

9.13.1 Business Grinding

Map targets within the scope from active and passive analysis of emanations.

9.13.2 Business Environment

Explore and document any particular business information or property stated implicitly as confidential in regulations and policy.

9.13.3 Organizational Environment

Examine and document types of disclosure of any particular organizational property stated implicitly as confidential in regulations and policy.

Quarantine Verification

The determination and measurement of effective use of quarantine for all access to and within the target.

9.14.1 Containment Process Identification

Identify and examine quarantine methods and processes at the target for aggressive and hostile contacts.

9.14.2 Containment levels

Verify the state of containment where interactions have quarantines methods.

Privileges Audit

Tests where credentials are supplied to the user and permission is granted for testing with those credentials.

9.15.1 Identification

Examine and document the process for obtaining identification through both legitimate and fraudulent means.

9.15.2 Authorization

Verify the use of fraudulent authorization to gain privileges similar to that of other personnel.

9.15.3 Escalation

Verify and map access to information through the use of privileges to gain higher privileges.

9.15.4 Subjugation

Enumerate and test for inadequacies to use or enable loss controls not enabled by default.

Survivability Validation

Determining and measuring the resilience of the target within the scope.

9.16.1 Continuity

Enumerate and test for inadequacies from target with regard to access delays and service response time through back-up personnel or automated means for alternate access.

9.16.2 Resilience

Map and document the process of gatekeepers disconnecting channels due to breach or safety concerns.

Alert and Log review

A gap analysis between activities performed with the test and the true depth of those activates.

9.17.1 Alarm

Verify and enumerate the use of a localized or scope-wide warning system where a suspect situation is noted by personnel upon suspicion of circumvention attempts, social engineering, or fraudulent activity.

9.17.2 Storage and retrieval

Document and verify unprivileged access to alarm, log, and notification storage locations and property.

Related Projects

OSSTMM research has entered into other ISECOM projects as well, using the unique philosophy and distinctions between security and safety to bring clarity to other areas.

• Bad People Project - A project to improve the security and safety message for children free from cultural and national biases or contradictions. Children (ages 4 – 10) are asked to draw a picture of a Bad Person with no coaching or further instruction from the parent or guardian. Their drawing and comments about the drawing are collected with no personal identifying information. Details of the drawing and the comments are categorized and aggregated to learn about the universal commonalities children have about the evils of the world to better reach them with a common message and set of safety rules.
• SCARE - The Source Code Analysis and Risk Evaluation uses the OSSTMM's ravs and definitions to measure the security from complexity in source code. The project is designed to allow for other languages to be plugged in as well. The example is in C. This project is used in the OpenTC project for measuring Linux source code for Trusted Computing.
• Hacker Highschool - A series of 12 lessons, freely available and translated into 5 languages to teach computer networking and security in an interesting way. It follows the OSSTMM philosophy as well as the definitions and means of testing.
• Child Safety and Security Methodology - A methodology for teaching real security and safety skills to children through games and stories. This methodology closely follows the OSSTMM definitions and applies OSSTMM controls to protecting children.
• Home Security Methodology - A methodology for securing ones home and keeping it safe from all possible threats. Started as a rebuttal to Home Security information provided by CNN on how to leave your home secure when you go on vacation. ISECOM quickly released the Home Security Vacation Guide, a checklist and philosophy that is both tongue-in-cheek and extreme in its thoroughness. The Vacation Guide was never meant for people to follow completely but rather to serve as an example of what real physical security would require. This methodology closely follows the OSSTMM definitions and applies OSSTMM controls to protecting and securing one's home.
• National Security Methodology - A methodology for rule and policy makers to improve national security efforts in realistic ways. This methodology closely follows the OSSTMM definitions of security and controls as applied to a nation and provides a language free of security jargon to reach a larger audience. The manual has not been released because it makes very clear where some nations are very weak. ISECOM is in the process of re-writing it to prevent misuse.

Certification & Training

ISECOM pays for its independent research through professional certifications. Individual and company certifications are available through ISECOM for the applied skills in professional security testing, analysis, methodical process, and professional standards as outlined in the OSSTMM's Rules of Engagement. Individuals may get certified in the following OSSTMM roles:

• Professional Security Tester (OPST)
• Professional Security Analyst (OPSA)
• Professional Security Expert (OPSE)
• Wireless Security Expert (OWSE)
• Certified Trust Analyst (CTA)

These certifications are the official ISECOM professionals certifications showing the knowledge and skills required to perform their respective roles properly and in accordance to the OSSTMM. The certifications each require up to a four hour open-book skills exam to prove ability over rote memorization. The company certification is the ISECOM Licensed Auditor (ILA) which requires the company to sign a contract of ethical compliance to the Rules of Engagement from the OSSTMM and an ISECOM certified security staff.

External links

• OSSTMM Open Source Security Testing Methodology Manual
• ISECOM
• Professional Security Analyst
• Professional Security Tester
• OSSTMM Wireless Security Expert
• OSSTMM Professional Security Expert
• Certified Trust Analyst
• ISECOM Licensed Auditors

References

ca:OSSTMM