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.