**Interactive 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, Subjugation, Continuity, and Resilience.

1. Authentication is a control through the challenge of credentials based on identification and
authorization.

2. Indemnification is a control through a contract between the asset owner and the interacting
party. This contract may be in the form of a visible warning as a precursor to legal action if posted
rules are not followed, specific, public legislative protection, or with a third-party assurance
provider in case of damages like an insurance company.

3. Resilience is a control over all interactions to maintain the protection of assets in the event of
corruption or failure.

4. Subjugation is a control assuring that interactions occur only according to defined processes. The
asset owner defines how the interaction occurs which removes the freedom of choice but also the
liability of loss from the interacting party.

5. Continuity is a control over all interactions to maintain interactivity with assets in the event of
corruption or failure.

From : https://www.isecom.org/OSSTMM.3.pdf

**Process Controls**

The other half of operation controls are the Class B controls which are used to create defensive processes.
These controls do not directly influence interactions rather they protect the assets once the threat is
present. These are also known as Process Controls and include Non-repudiation, Confidentiality, Privacy,
Integrity, and Alarm.

6. Non-repudiation is a control which prevents the interacting party from denying its role in any
interactivity.

7. Confidentiality is a control for assuring an asset displayed or exchanged between interacting
parties cannot be known outside of those parties.

8. Privacy is a control for assuring the means of how an asset is accessed, displayed, or exchanged
between parties cannot be known outside of those parties.

9. Integrity is a control to assure that interacting parties know when assets and processes have
changed.

10. Alarm is a control to notify that an interaction is occurring or has occurred.


While controls are a positive influence in OpSec, minimizing the attack surface, they can themselves add
to the attack surface if they themselves have limitations. Often times this effect is not noticed and if the protection mechanisms aren’t tested thoroughly as to how they work under all conditions, this may not
become apparent. Therefore the use of controls must assure that they do not insinuate new attack
vectors into the target. Therefore, sometimes no controls are better than bad controls.


2.4 Rules Of Engagement
These rules define the operational guidelines of acceptable practices in marketing and selling testing,
performing testing work, and handling the results of testing engagements.
A. Sales and Marketing
1. The use of fear, uncertainty, doubt, and deception may not be used in the sales or marketing
presentations, websites, supporting materials, reports, or discussion of security testing for the
purpose of selling or providing security tests. This includes but is not limited to highlighting crimes,
facts, glorified criminal or hacker profiles, and statistics to motivate sales.
2. The offering of free services for failure to penetrate the target is forbidden.
3. Public cracking, hacking, and trespass contests to promote security assurance for sales or
marketing of security testing or security products are forbidden.
4. To name past or present clients in the marketing or sales for potential customers is only allowed if
the work for the client was specifically the same as being marketed or sold and the named client
has provided written permission to do so.
5. It is required that clients are advised truthfully and factually in regards to their security and security
measures. Ignorance is not an excuse for dishonest consultancy.

B. Assessment / Estimate Delivery
6. Performing security tests against any scope without explicit written permission from the target
owner or appropriate authority is strictly forbidden.
7. The security testing of obviously highly insecure and unstable systems, locations, and processes is
forbidden until the proper security infrastructure has been put in place.
C. Contracts and Negotiations
8. With or without a Non-Disclosure Agreement contract, the security Analyst is required to provide
confidentiality and non-disclosure of customer information and test results.
9. Contracts should limit liability to the cost of the job, unless malicious activity has been proven.
10. Contracts must clearly explain the limits and dangers of the security test as part of the statement of
work.
11. In the case of remote testing, the contract must include the origin of the Analysts by address,
telephone number or IP address.
12. The client must provide a signed statement which provides testing permission exempting the
Analysts from trespass within the scope, and damages liability to the cost of the audit service with
the exception where malicious activity has been proven.
13. Contracts must contain emergency contact names and phone numbers.
14. The contract must include clear, specific permissions for tests involving survivability failures, denial
of service, process testing, and social engineering.
15. Contracts must contain the process for future contract and statement of work (SOW) changes.
16. Contracts must contain verified conflicts of interest for a factual security test and report.

D. Scope Definition
17. The scope must be clearly defined contractually before verifying vulnerable services.
18. The audit must clearly explain the limits of any security tests according to the scope.
E. Test Plan
19. The test plan may not contain plans, processes, techniques, or procedures which are outside the
area of expertise or competence level of the Analyst.
F. Test Process
20. The Analyst must respect and maintain the safety, health, welfare, and privacy of the public both
within and outside the scope.
21. The Analyst must always operate within the law of the physical location(s) of the targets in addition
to rules or laws governing the Analyst’s test location.
22. To prevent temporary raises in security for the duration of the test, only notify key people about the
testing. It is the client’s judgment which discerns who the key people are; however, it is assumed
that they will be information and policy gatekeepers, managers of security processes, incident
response personnel, and security operations staff.
23. If necessary for privileged testing, the client must provide two, separate, access tokens whether
they be passwords, certificates, secure ID numbers, badges, etc. and they should be typical to the
users of the privileges being tested rather than especially empty or secure accesses.
24. When testing includes known privileges, the Analyst must first test without privileges (such as in a
black box environment) prior to testing again with privileges.
25. The Analysts are required to know their tools, where the tools came from, how the tools work, and
have them tested in a restricted test area before using the tools on the client organization.
26. The conduct of tests which are explicitly meant to test the denial of a service or process or
survivability may only be done with explicit permission and only to the scope where no damage is
done outside of the scope or the community in which the scope resides.
27. Tests involving people may only be performed on those identified in the scope and may not
include private persons, customers, partners, associates, or other external entities without written
permission from those entities.
28. Verified limitations, such as discovered breaches, vulnerabilities with known or high exploitation
rates, vulnerabilities which are exploitable for full, unmonitored or untraceable access, or which
may immediately endanger lives, discovered during testing must be reported to the customer with
a practical solution as soon as they are found.
29. Any form of flood testing where a scope is overwhelmed from a larger and stronger source is
forbidden over non-privately owned channels.
30. The Analyst may not leave the scope in a position of less actual security than it was when
provided.

G. Reporting
31. The Analyst must respect the privacy of all individuals and maintain their privacy for all results.
32. Results involving people untrained in security or non-security personnel may only be reported via
non-identifying or statistical means.
33. The Analyst may not sign test results and audit reports in which they were not directly involved.
34. Reports must remain objective and without untruths or any personally directed malice.
35. Client notifications are required whenever the Analyst changes the testing plan, changes the
source test venue, has low trust findings, or any testing problems have occurred. Notifications must
be provided previous to running new, dangerous, or high traffic tests, and regular progress updates
are required.
36. Where solutions and recommendations are included in the report, they must be valid and
practical.
37. Reports must clearly mark all unknowns and anomalies.
38. Reports must clearly state both discovered successful and failed security measures and loss
controls.
39. Reports must use only quantitative metrics for measuring security. These metrics must be based on
facts and void of subjective interpretations.
40. The client must be notified when the report is being sent as to expect its arrival and to confirm
receipt of delivery.
41. All communication channels for delivery of the report must be end to end confidential.
42. Results and reports may never be used for commercial gain beyond that of the interaction with
the client.

Combining the Trifecta and the 4 Point Process
The Trifecta combined with the Four Point Process provide a substantially thorough application of this
methodology. The steps in this application can be summarized as follows:
1. Passively collect data of normal operations to comprehend the target.
2. Actively test operations by agitating operations beyond the normal baseline.
3. Analyze data received directly from the operations tested.
4. Analyze indirect data from resources and operators (i.e. workers, programs).
5. Correlate and reconcile intelligence from direct (step 3) and indirect (step 4) data test results to
determine operational security processes.
6. Determine and reconcile errors.
7. Derive metrics from both normal and agitated operations.
8. Correlate and reconcile intelligence between normal and agitated (steps 1 and 2) operations to
determine the optimal level of protection and control which would best be implemented.
9. Map the optimal state of operations (step 8) to processes (step 5).
10. Create a gap analysis to determine what enhancements are needed for processes governing
necessary protection and controls (step 5) to achieve the optimal operational state (step 8) from
the current one.


Test Results
Test results are often accompanied by recommended solutions or consulting offers, neither of which is required
in an OSSTMM audit. Recommended solutions may be provided as a value-add to a security test but are not
considered mandatory. Often there are no proper solutions based on the limited view an Analyst has of the
client environment. Therefore, solutions are not required as part of an OSSTMM audit.
Frequently, a test will exceed the limits of a security control. Within an engagement, the Analyst must always
report the factual current state of security, any limitations within that current state, and any of the processes
which caused those limitations of the applied controls and protections.
To measure both the thoroughness of the test and the security of the target, use of this methodology should
conclude with the Security Test Audit Report (STAR), available within this manual or at the ISECOM website.
STAR requires the following information:
1. Date and time of test
2. Duration of test
3. Names of responsible Analysts
4. Test type
5. Scope of test
6. Index (method of target enumeration)
7. Channel tested
8. Test Vector
9. Attack surface metric
10. Which tests have been completed, not completed, or partially completed, and to what extent
11. Any issues regarding the test and the validity of the results
12. Any processes which influence the security limitations
13. Any unknowns or anomalies
Successful use of the OSSTMM shows an actual measurement of security and controls. Misrepresentation of
results in reporting may lead to fraudulent verification of security controls, and an inaccurate security level. For this, the Analyst must accept responsibility and limited liability for inaccurate reporting.