TLDR: This article highlights the Yarix Red Team’s daily challenges and internal work done to improve the quality of our outcomes. We will explore the topic by taking the Mobile Security field as a case: we will start with the common reporting problems every red team faces day after day, as well as those arising from the gaps in the industry standards (e.g. OWASP, MITRE, etc.), to finish with what lies behind our Mobile Security assessment outcomes. Although the start and the end may sound totally unrelated, they are interconnected through the new version of the OWASP Mobile Application Security project.

Introduction

Many teams all over the world are engaged in ethical hacking activities, investing a large amount of time in projects such as red teaming, penetration testing, security assessments, bug bounty, and security research. These efforts are constantly followed by detailed reports that provide an in-depth overview of the work done and the vulnerabilities identified. The global community has consistently aimed to enhance reporting, ensuring that the outcome is clear and suitable for its intended audience.

Security teams must consider not only the technical aspects of their outcomes, but also the descriptive and theoretical elements while reporting. From my friends, colleagues, and my own experience, security teams often build and develop their internal knowledge base over the years to shape their reporting uniqueness and distinctiveness. Building this internal knowledge base requires dedication to ensure it remains valuable, relevant over time, and, more crucially, a core asset within the team. Keeping up with the constant updates and breakthroughs in the ethical hacking world and security standards, like MITRE and OWASP, is essential to achieve these objectives.

Recently, OWASP has made huge advancements in Mobile Security, releasing new updates and standards to improve security practices. The community's contributions have been amazing, and I cannot express my gratitude enough.

The purpose of this article is to highlight how Yarix addresses these aspects, especially in Mobile Security, sharing the behind-the-scenes approaches that help to consistently improve the Yarix Red Team's (YRT) outcomes. But first, we will be looking at the OWASP Mobile Application Security project's latest 2024 update.

OWASP Mobile Security Application Refactoring 2024

Before delving into the topic, it is useful to look at the evolution of the OWASP Mobile Application Security (MAS) project to better understand its strengths and limitations throughout time.

Anyone in mobile security knows the OWASP MAS project is a must-read and valuable resource. In my opinion, no better project covers all the technical security concerns of a mobile application as the OWASP project. It is not only well-documented but also exceptionally organized, at least now.

Over the years, this open-source project has provided comprehensive information on mobile app security, addressing storage, networking, platform usage, code development, resilience, and more. Importantly, the project has diversified into what I would call subprojects, such as the Mobile Application Security Verification Standard (MASVS), which was created in 2016, and the Mobile Security Testing Guide (MSTG), which was released in 2019. The drive followed the conventional OWASP approach: starting with more theoretical and abstract documents (MASVS) and moving to more practical and technical ones (MSTG).

Despite ongoing updates and revisions, the industry standards have faced challenges and shortcomings over the years. As a result, security teams often couldn't rely solely on the common standards, frameworks, and tools - not limited to OWASP but also including MITRE, CVSS, CWE, and others in the industry. They had to fill certain gaps using their own knowledge, expertise, or the limited information available online.

If you have ever been part of a security team, you might have encountered situations where it was complex calculating the CVSS score because the impact was not clear for example, or you couldn’t exploit the vulnerability but still felt it needed to be reported. Portswigger mentioned CVSS system failures, highlighted by JFrog, here. Still, you might have struggled to fit a vulnerability neatly into a specific category or CWE. Recently, a famous web security expert Tib3rius talked about how the evolution of OWASP Top Ten over the years has created confusion on specific topics.