OSSTMM 2.1. - RULES OF ENGAGEMENT
CODE OF ETHICS (from the OSSTMM 2.1)
Those who are partners with ISECOM or publicly claim to use the OSSTMM for security testing must uphold the following
rules of engagement. These rules define the ethical code of acceptable practices in marketing and selling security
testing or security consulting, performing security testing work, and handling the results of security testing
engagements.
1. Sales and Marketing
1. The use of fear, uncertainty and doubt 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 crime, facts, criminal or hacker
profiling, and statistics.
2. The offering of free services for failure to penetrate or provide trophies from 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. Performing security tests against any network without explicit written permission from the appropriate authority
is strictly forbidden.
5. The use of names of past clients who you have provided security testing for is forbidden even upon consent of
said client. This is as much for the protection of the client's confidentiality as it is for the security testing
organization.
6. It is required to provide truthful security advice even when the advice may be to advise giving the contract
to another company. An example of this would be in explaining to a company that your security testers should not
be verifying a security implementation your organization designed and installed rather it should be tested by an
independent 3rd party.
2. Assessment / Estimate Delivery
1. Verifying possible vulnerable services without explicit written permission
is forbidden.
2. The security testing of obviously highly insecure and unstable systems, locations, and processes is forbidden
until the security has been put in place.
3. Contracts and Negotiations
1. With or without a Non-Disclosure Agreement contract, the security tester
is ethically bound to confidentiality, non-disclosure of customer information, and security testing results.
2. The tester must always assume a limited amount of liability as per responsibility. Acceptable limited liability
is equal to the cost of service. This includes both malicious and non-malicious errors and project mismanagement.
3. Contracts must clearly explain the limits and dangers of the security test.
4. In the case of remote testing, the contract must include the origin of the testers by telephone numbers and/or
IP addresses.
5. Contracts must contain emergency contact persons and phone numbers.
6. The contract must include clear, specific permissions for tests involving survivability failures, denial of
service, process testing, or social engineering.
7. Contracts must contain the process for future contract and statement of work (SOW) changes.
4. Scope
1. The scope must be clearly defined contractually before verifying vulnerable
services.
2. The scope must clearly explain the limits of the security test.
5. Providing Test Plan
1. The test plan must include both calendar time and man hours.
2. The test plan must include hours of testing.
6. Providing the rules of engagement to the client.
1. No unusual or major network changes allowed by the client during testing.
2. To prevent temporary raises in security only for the duration of the test, the client should notify only 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, and security
operations.
3. If necessary for privileged testing, the client must provide two, separate, access tokens whether they be logins
and passwords, certificates, secure ID numbers, etc. and they should be typical to the users of the privileges
being tested (no especially empty or secure accounts).
4. When performing a privileged test, the tester must first test without privileges in a black box environment
and then test again with privileges.
7. Testing
1. The testers 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.
2. The exploitation of Denial of Service tests may only be done with explicit permission. An OSSTMM security test
does not require one to exploit denial of service and survivability endangering type vulnerabilities in a test.
The tester is expected to use gathered evidence only to provide a proper review of such security processes and
systems.
3. Social engineering and process testing may only be performed in non-identifying statistical means against untrained
or non-security personnel.
4. Social engineering and process testing may only be performed on personnel identified in the scope and may not
include customers, partners, associates, or other external entities.
5. High risk vulnerabilities such as discovered breaches, vulnerabilities with known, high exploitation rates,
vulnerabilities which are exploitable for full, unmonitored or untraceable access, or which may put immediate lives
at risk, discovered during testing must be reported to the customer with a practical solution as soon as they are
found.
6. Distributed Denial of Service testing over the Internet is forbidden.
7. Any form of flood testing where a person, network, system, or service, is overwhelmed from a larger and stronger
source is forbidden.
8. Client notifications are required whenever the tester changes the testing plan, changes the source test venue,
has high risk findings, previous to running new, high risk or high traffic tests, and if any testing problems have
occurred. Additionally, the client should be notified with progress updates weekly.
8. Reporting
1. Reports must include practical solutions towards discovered security
problems.
2. Reports must include all unknowns clearly marked as unknowns.
3. Reports must state clearly all states of security found and not only failed security measures.
4. Reports must use only qualitative metrics for gauging risks based on industry accepted methods. These metrics
must be based on a mathematical formula and not on feelings of the analyst.
9. Report Delivery
1. The client must be notified when the report is being sent as to expect
its arrival and to confirm receipt of delivery.
2. All communication channels for delivery of report must be end to end confidential.
TEAM ACCESS