Open Source Security ISECOM Result and Analysis

This is a document of security testing methodology; it is a set of rules and guidelines for which, what, and when events are tested. This methodology only covers external security testing, which is testing security from an unprivileged environment to a privileged environment or location, to circumvent security components, processes, and alarms to gain privileged access. It is also within the scope of this document to provide a standardized approach to a thorough security test of each section of the security presence (e.g. physical security, wireless security, communications security, information security, Internet technology security, and process security) of an organization. Within this open, peer-reviewed approach for a thorough security test we achieve an international standard for security testing to use as a baseline for all security testing methodologies known and unknown.


The limitation to the scope of external security testing is due to the substantial differences between external to internal and internal to internal testing. These differences are fundamentally in the access privileges, goals and deliverables associated with internal to internal testing. The testing towards the discovery of unknown vulnerabilities is not within the scope of this document nor is it within the scope of an OSSTMM security test. The security test described herein is a practical and efficient test of known vulnerabilities, information leaks, and deviations from law, industry standards, and best practices.

ISECOM requires that a security test may only be considered an OSSTMM test if it is:
• Quantifiable.
• Consistent and repeatable.
• Valid beyond the "now" time frame.
• Based on the merit of the tester and analyst not on brands.
• Thorough.
• Compliant to individual and local laws and the human right to privacy.
 
ISECOM does not claim that using the OSSTMM constitutes a legal protection in any court of law however it does serve as the highest level of appropriate diligence when the results are applied to improve security in a reasonable time frame.

Intended AudienceThis manual is written for security testing professionals. Terms, skills, and processes mentioned in here may not be clear to those not directly involved and experienced with security testing. Designers, architects, and developers will find this manual useful to build better defense and testing tools. Many of the tests do not have a way to be automated. Many of the automated tests do not follow a methodology or follow one in an optimal order. This manual will address these issues.


AccreditationA security test data sheet is required to be signed by the tester(s) and accompany all final reports to submit an OSSTMM certified test. This data sheet available with OSSTMM 2.5. This data sheet will show which modules and tasks had been tested to completion, not tested to completion and why, and not applicable and why. The checklist must be signed and provided with the final test report to the client. A data sheet which indicates that only specific Modules of an OSSTMM Section has been tested due to time constraints, project problems, or customer refusal can NOT be said then to be a full OSSTMM test of the determined Section.

Reasons for the data sheet are:
• Serves as proof of thorough, OSSTMM testing.
• Makes a tester(s) responsible for the test.
• Makes a clear statement to the client.
• Provides a convenient overview.
• Provides a clear checklist for the tester.

The use of this manual in the conducting of security testing is determined by the reporting of each task and its results even where not applicable in the final report. All final reports which include this information and the proper, associate checklists are said to have been conducted in the most thorough and complete manner and may include the following statement and a stamp in the report:

This test has been performed in accordance to the Open Source Security Testing Methodology available at http://www.osstmm.org/and hereby stands within best practices of security testing.

Result
The ultimate goal is to set a standard in security testing methodology which when used results in meeting practical and operational security requirements. The indirect result is creating a discipline that can act as a central point in all security tests regardless of the size of the organization, technology, or defenses.

Analysis
The scope of this document does not include direct analysis of the data collected when using this manual. This analysis is the result of understanding the appropriate laws, industry regulations, and business needs appropriate to the particular client and the best practices and regulations for security and privacy other the client’s regions of operation. However, analysis of some form is implied by the use of “Expected Results” within the methodology so some analysis must be done to assure at least these expected results are met.

Internet and Network Related Terms
Throughout this manual we refer to words and terms that may be construed with other intents or meanings. This is especially true through international translations. For definitions not associated within this table below, see the reference of the OUSPG Vulnerability Testing Terminology glossary available at http://www.ee.oulu.fi/research/ouspg/sage/glossary/.

Application Test The security testing of any application whether or not it’s part of the Internet presence.
Assessment An overview of the security presence for the estimation of time and man hours.
Automated Testing Any kind of unattended testing that also provides analysis
Black Box The tester has no prior knowledge of the test elements or environment
Black Hat A hacker who is chaotic, anarchistic and breaks the law
Client This refers to a sales recipient with whom confidentiality is enforced through a
signed non-disclosure agreement.
Competitive Intelligence A practice legally for extracting business information from competitors.