Comparative analysis of OSSTMM v3 and OWASP 4.0
Table of content:
- Description of OSSTMM v3
- Description of OWASP 4.0
- Comparative analyses
Open-Source Security Testing Methodology Manual (OSSTMM)
Introduction
The Open-Source Security Testing Methodology Manual is strictly based on a scientific methodology that can provide a user with precise operational security characterisation. This is achieved through analyses and association of the test results in a regulated and reliable way.
Furthermore, the manual provides gaudiness for analysts to perform an OSSTMM audit. The guidelines, when followed correctly, can assure the following:
1. The test was conducted thoroughly.
2. The test included all necessary channels.
3. The posture for the test complied with the law.
4. The results are measurable in a quantifiable way.
5. The results are consistent and repeatable.
6. The results contain only facts as derived from the tests themselves.
One of the benefits of this manual is that it can be used as a central reference point regarding all security tests scaled and directed towards any organisation, technology, or protection [1,2].
OSSTMM is used as an auditing methodology which can be applied for regulatory purposes for corporate assets. However, it requires an auditor to have a fundamental and comprehensive skill set to complete each phase fully [1].
Workflow
The OSSTMM flow starts with a review of the rules, legislation, policies, culture, and norms called the target posture. This review helps define the target, and the result is an end-stage comparison to any logs, alarms, alerts, or reports.
In other words, the first step in this process is bound to awareness of operational requirements that allow interaction with the target. The last step is designed to evaluate the accounts of the audit path.
Hierarchy of the methodology:
1. Channel
2. Module
3. Task
The OSSTMM has 5 channels and 17 modules that are same for all channels. However, each channel will differ in a task.
When all the modules are put together, they provide a single point of reference or one methodology (Fig. 1.) that the analyst should know and implement.
The advantage of this methodology is that it could be used on any target no matter if it is a location, person, specific system, or a process (or thousands of them) [1].
Channels
Human Security Testing (HST)
The OSSTIMM considers Human Security Testing a subsection of Psychological Operations and treats it more than ‘social engineering’.
According to the manual HST encompasses personal security awareness testing and compliance analyses that determinates if current security standards are aligned with legislation, industry regulation or company policies [1].
Physical Security Testing (PST)
Physical security testing does not require communicative interaction with gatekeeping personnel and barriers at asset positions.
The PST encompasses classification of different aspects of material security confined to human interactive three-dimensional space.
According to the manual, the PST is not only “breaking and entering”, but its objective is a physical and logical barrier testing and analyses that determinates if current security standards are aligned with legislation, industry regulation or company policies [1].
Wireless Security Testing (WST)
Wireless security covers measures for securing non-communications electromagnetic radiation from unauthorised access that enables derivation of information from it.
Another aspect of WST is to create preventive measures against jamming and unauthorised access to wireless communication.
The last area in the scope of WST are measures targeted towards machine emanations that can be analysed when intercepted by the adversary. The adversary can intercept received, transmitted, handled, or processed in another way by the targeted equipment [1].
Telecommunication Security Testing (TST)
This channel deals with communication over a wired telecommunication network. The objective of TST is to conduct tests for logical barriers and compliance analyses that determinates if current security standards are aligned with legislation, industry regulation or company policies. An analyst is required to have an electronics background in analogy and digital area [1].
Data Network Security Testing (DNST)
The DNST is not considered only “penetration testing” but also provides operational quality and system interaction testing that determinates if current security standards are aligned with legislation, industry regulation or company policies. This channel focuses on providing the organisation with fixes to existing problems and provides designs for future improvements [1].
Open Web Application Security Project (OWASP) Testing Guide 4.0
Introduction
The Open Web Apician Security Project Testing Guide focuses on continuous improvement in application software security that has worldwide community support. Security testing is deeply integrated with the software development life cycle (SDLC), which plays a key role in this guide.
The guide, among other things, discusses different aspects of testing and emphasise a deep integration into each phase with organisations existing SDLC.
This guide provides techniques and tools to perform web application security testing [4].
Testing techniques
The OWASP testing guide provides a high-level summary of diverse testing methods that the organisation can deploy [4].
Manual Inspections & Review
Manual inspections are typically inspections of individuals that analyse processes, policies, and other security implications.
One of the critical aspects of manual inspections is to review the understanding of individuals about the security process, policies and verifying their skills which would allow them to create and implement secure applications.
Secure code policies, architectural design, security requirements or documentation review should be a part of manual inspection [4].
Threat Modelling
Threat modelling helps system designers assess the security threat landscape for their systems and applications. For this reason, this model can serve as a risk assessment that facilitates mitigation strategy development for known and possible vulnerabilities and direct limited system resources to most relevant processes.
Each application should have a threat model as soon as possible within the SDLC process that needs to be monitored and revised when the application evolves during the development process.
The NIST 800–30 is a recommended standard for thread modelling within the OWASP framework [4].
Source Code Review
Secure code review is a critical process that can detect serious security vulnerabilities which can not be otherwise detected.
The source code inspections can incorporate access control issues, concurrency problems, backdoors, cryptographic vulnerabilities, Trojans, time bombs, and other malicious code forms [4].
Penetration Testing
In penetration testing, the pen tester operates as an attacker and tries to discover and exploit vulnerabilities.
The penetration process for network security is an effective way to test network security. However, because of most web applications’ bespoke nature, this requires more diverse research and testing. Automatised pen testing tools for web applications testing usually have very low efficiency because of the custom design.
The OWASP testing guide highlights web app penetration testing as a popular method by which many companies primarily test their application. However, it does not recommend it to be used as a primary testing technique [4].
Workflow
The guide presents a generic and flexible development model that can help the organisation develop its framework using existing organisational processes. In other words, it could be viewed as a reference structure at various stages of the SDLC.
This model is not for contractors or consultants that the organisation uses for more specific and technical testing areas. Still, it should serve as a guide for creating a comprehensive vital testing process.
OWASP testing framework workflow (Fig.2) consists of 5 phases and 18 review and testing stages with the vertical flow and traceability measurement in each phase of the process [4].
Web Application Security Testing
This part of the guide presents in-depth technical documentation on conducting a test divided into 11 sections, including the overview [4].
Configuration and Deployment Management Testing
Application security testing plays a predominant role in testing. However, proper configuration and deployment of servers that host the web application are severely necessary as well. In other words, all parts of the chain need to be well designed and tested for all-around security [4].
Identity Management Testing
This area tests role definitions, user registration process, account provisioning process, account enumeration and guessable user accounts, weak or unenforced username policy [4].
Authentication Testing
Authentication testing could be described as an attempt to verify senders digital identity in communication, such as log on process and try to bypass the mechanism [4].
Authorization Testing
Authorization deals with access controls that allow access to resources only to people that were authorized to use them. The analyst must understand that authorization comes after authentication to validate if credentials fall into a pre-defined set of functions and privileges [4].
Session Management Testing
Session management tests the mechanism by which the web application control and maintains the state for a user. In this case, the analyst will verify if the cookies can sustain a broad range of attacks [4].
Input Validation Testing
Input validation testing is when the tester uses malicious or bogus requests to reach the server to examine the response [4].
Testing for Error Handling
Error code testing is one of the areas of testing. The analyst creates requests that should generate error codes that can reveal bugs, databases, and other elements associated with web applications [4].
Testing for weak Cryptography
In this area of testing the analyst tests for Padding Oracle, Weak SSL/TLS Ciphers, Sensitive information sent via unencrypted channels Insufficient Transport Layer Protection [4].
Business Logic Testing
Here the analyst tests for Process Timing, Number of Times a Function Can be Used Limits, Ability to Forge Requests, Business Logic Data Validation, Integrity Checks, Defences Against Application Misuse, Upload of Malicious Files, Upload of Unexpected File Type and Circumvention of Workflows [4].
Client-Side Testing
Client-Side testing is different from server-side testing in which case the server responds to requests. This type of testing executes code only on the client within a web browser or its plugin [4].
Comparative analyses
This report’s previous section describes two different methodological approaches for performing a penetration test and overall security test. To highlight, the differences in each approach this part of the report will compare goals, scope, and activities throughout the pre-engagement phase. And lastly, it will look at the post engagement passe [2].
Goals comparison
The OSSTMM is strictly based on a scientific methodology that can provide a user with precise operational security characterisation. This is achieved through analyses and association of the test results in a regulated and reliable way [2].
On the other hand, OWASP is the most practical guideline. The OWASP focuses on Web Application Penetration Testing Methodology. This methodology aims to provide a user with many potential techniques that can be used for testing. Additionally, it promises guideline updates periodically and explains each method used in the manual [2].
Scope comparison
I have chosen those two methodologies because they provide two different approaches regarding scope.
On the one hand, the OWASP methodology specific scope focuses on Web Application Testing. On the other hand, the OSSTM provides a broader (six channels) scope with almost any audit type possible [2].
Pre-engagement guidelines comparison
The OSSTMM in the pre-engagement phase focuses mostly on determining the test’s scope using the guideline and that the test complies with the rules of engagement [2].
As mentioned, it the main section, the OWASP guide centres mostly on testing during individual phases of SDLC [2].
Post-engagement guidelines comparison
Both methodologies provide guidelines on how to report and present the finding of a test. The OSSTMM provides a bespoke in-house framework called STAR (Security, Test, Audit, Report). The STAR serves as an executive summary within a specific scope that asserts the target’s Attack Surface with a precise and measurable calculation.
The OWASP guideline uses a report with two separate sections. One section for an executive summary and another to discuss and present the technical finding of all the tests performed within the organisation.
Conclusion
When comparing both methodologies, it becomes apparent that both present distinctive paths to penetration testing. The more comprehensive but broad is the OSSNTT guide while on the other hand, the OWASP guide is specific to web application testing with highly practical up to date examples.
I would recommend combining approaches from both guidelines (or more) to create a bespoke strategy that would fit the unique organisation characteristics.
References
[1] Created by Pete Herzog, Developed by ISECOM (2010) Open-Source Security Testing Methodology Manual (OSSTMM) . [Online]. Available at: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiZy8Gk6eLuAhWeQxUIHcQ3Aj8QFjAAegQIARAC&url=https%3A%2F%2Fwww.isecom.org%2FOSSTMM.3.pdf&usg=AOvVaw2K4_Nk-LYU-n3cVXq2pzyw (Accessed: 2021).
[2] Niek Jan van den Hout (2019) Standardised penetration testing? Examining the usefulness of current penetration testing methodologies. A case study of the Dutch penetration testing industry. [Online]. Available at: https://www.researchgate.net/publication/335652869_Standardised_Penetration_Testing_Examining_the_Usefulness_of_Current_Penetration_Testing_Methodologies/link/5e1b0e7e4585159aa4c9c53a/download (Accessed: 2021).
[3] Aleatha Shanley, Michael N. Johnstone (2015) Selection of penetration testing methodologies: A comparison and evaluation , Available at: https://ro.ecu.edu.au/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1181&context=ism#:~:text=OSSTMM%20is%20an%20open%20source,and%20Open%20Methodologies%20(ISECOM).&text=OWASP%20is%20a%20not%2Dfor,focused%20on%20improving%20software%20security. (Accessed: 2021).
[4] Project Leaders: Matteo Meucii and Andrew Muller (2019) Open Web Application Security Project — Testing Guide 4.0. [Online]. Available at: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjLm8iO6-LuAhWAZxUIHYOlBqAQFjAAegQIAhAC&url=https%3A%2F%2Fowasp.org%2Fwww-project-web-security-testing-guide%2Fassets%2Farchive%2FOWASP_Testing_Guide_v4.pdf&usg=AOvVaw2wUPlgVIRlP91IDkD-csvM (Accessed: 2021).
