I always tell my team the caliber of their reporting lies within every step of engagement, not the end. The actuality is reporting is the only thing our clients and fellow security teams receive as a final product. This generally consists of a 15-30 page document as a result of our weeks or months of effort and man-hours. We have set out to help solve, improve and hopefully make reporting more enjoyable. We would like to formally introduce the OS-CFDB (Open Source Common Finding Database). This project was developed out of necessity to support multiple reporting lines of effort taking place from mobile to Red Teaming assessments.
TL;DR (To Long; Don’t Read): https://os-cfdb.obscuritylabs.com/
Our goal is to simply enhance the security industries ability to report in a meaningful way.
When put into perspective reporting is crucial to the success of an internal or external assessment team, and sorrowfully often seen as a burden placed on the team in the first place. When done improperly your consumers will let you know, this, in turn, can be a major demotivating event. That’s why we feel it’s imperative to introduce automation and community-sourced feedback to try to provide customers of our reporting meaningful insight. At Obscurity Labs, we grasp reporting is a critical component of many teams around the world, and we plan on sustaining the project at a higher level moving forward this year. With focusing on finding corporate contribution at a not for profit level. Helping support the maturity of the finding data, delivery, and road mapping out precise reporting guidelines. Simply put we love <3 open source and plan on supporting open source as much as possible!
This post is broken down into a few core areas that I feel are necessary to understand where OS-CFDB stemmed from:
- The problem - reporting is not standardized, lacking true subsistence
- Why the problem exists - time, resources and public conversation
- The solution - OS-CFDB
- The how - web, markdown, RESTful automation services
Fallacies We Need To Break as a Industry
Photo by Devin Avery / Unsplash
If you do vulnerability research, vulnerability analysis, vulnerability management, Red Team, and Pen-test work you know reporting is “inebriating”. It’s always a cumbersome challenge and burden to convey usable data/metrics to your clients or support organizations. When done wrong it has a sweeping impact on the well-being of an organization and its trust in its operational divisions (I.E Pentest Teams).
Operationally I have now served on internal and external teams, bearing the responsibility to build, maintain and deliver reports to clients. It single-handedly has been the hardest portion of the job to get right. This solely rested on factors such as delivering quality reporting that was actually useful to the customer. In many cases, this is sadly no, without comprehensive out-briefs and one-on-one synergy with the customer to convey the data. This is a luxury of being part of an internal team when conducting assessments, while in many cases external teams will not have this ability to sustain reachback support. This is merely the reality of using an external team and their ability to provide support post mortem, and that’s only if they have the cycles to even support such endeavors. While this works for small teams, in an enterprise with multiple parties influenced by your testing, the documentation you publish needs to be strong enough to stand on its own, especially if you’re an external firm! That’s why we feel developing a supporting OS-CFDB will have a major impact on the community as the project grows.
“No one will use the report anyway”
I have heard many offensive security practitioners mention this as a core reason why they don’t invest a large set of time in reporting. You should ask your self: “Well who’s at fault? Why is my information is not an authoritative source?” Yours, we did this as a community by not providing detailed insightful information and honestly useful metrics. While I’m slightly speaking for the industry as a whole, those that have gotten right require extensive resources to maintain. Yet another reason we feel a source such as this needs to exist.
OS-CFDB plans on tackling this on many fronts, and it all starts with data enrichment. No we don’t want or need a 70 page Nessus print out, but the data in the findings must provide a few key factors:
- Finding Details
- Technical Information
- Finding Metadata
Using this reporting layout which may be familiar to many, we start to enrich these sections over time with remediation resources, and deep technical insight into the root cause of the finding.
“I Always Use The Latest TTPs”
The reality is you are the front line of defense, as offensive security expert you are true blue. That may hurt to hear, but your role exists to enhance security control coverage. Which boils down to exposing ground truth so executives can make informed intelligible decisions. This not only helps reduce coverage gaps but trains analyst on true IR actions and their outcomes. Some of the most rewarding engagements I have been a part of grew from escalation events and guiding SOC analysts to understand impact and correlation of events tied to its operational TTP. This is exactly why the Mitre ATT&CK Framework (https://attack.mitre.org/) is so popular today, and with many security organizations. It allows them to tie operational TTP to toolsets and formalize their ability to detect, alert and remediate effectively.
As a security partitioner of offensive security, I found in many cases the basic TTP still work. Among the past 5 years is all about in-memory execution, we have found dropping an EXE in the Windows startup folder still works like a charm! I began to ask my self; why is this? Why are we not making progress within our organization? It comes down to what is truly useful for a contemporary SOC? I can tell you now it’s not the latest and transcendent tool that you built. It’s the knowledge you have, and creative mindset that has made you a Red Teamer in the first place. This precise notion is everything purple teaming presents to solve, by bridging the connection between operational arms of a modern security organization. The OS-CFDB was built around this premise that the data we supply needs to not inform them, but further their interpretation and analysis.
“I Just Break Things, I Don’t Fix Them”
Naturally, at the beginning of my career, I fell for this concept that my job is merely to break and not to help implement true detection and remediation strategies. This paradox is, unfortunately, a toxic pollutant of our role in the security industry. As the CEO of Obscurity Labs, I have spent a substantial subset of my time on designing the vision and cultivating true values that we operate within. We as practitioners of the security industry need to be held to a higher standard honestly, especially when it comes to reporting.
What is OS-CFDB
This project aims to provide a single source of common findings seen on Web/Application, Network, and Red Team assessments. While this project is scalable, it may not cover every single scenario applicable to your needs or reporting SOP (Standard Operating Procedures).
The core principles behind the project are simple:
- Provide the community with vetted and clear findings
- Provide multiple ingest points for automation
- Provide reporting templates, samples and guidelines
How To Interact With The Data?
OS-CFDB was built to provide access to the data with ease, and multiple endpoints to retrieve necessary components of the data source.
Web Console
The web console can be accessed at https://os-cfdb.obscuritylabs.com/. currently, we do have plans to move to its own domain so beware this may change but we will redirect all queries.
Search
Using the search console you are able to locate findings by name. We plan on enabling ElasticSearch in the upcoming roadmap for full text search, plus filtering. For the time being we only have structured search based on the finding name.
Expanding the Data
Each finding contains the common data types that may be needed to include in reporting metadata and allow for toolset integration.
- Title - The title of the finding
- VSR - Vulnerability Severity Rating - Custom developed default rating to place a finding
- CVSS - Applied score that depicts a translation from VSR to CVSS
- Risk - The commonly applied label of the finding
- Service - Descriptor of how a finding denoted identification
- NIST 800-53 - Specific correlating controls to finding
- MITRE ATT&CK - Linked tactics that may relate to the finding for further risk analysis
- References - Curated list of sources that should be used during reporting
Technical Information
- Description - The technical overview of a finding, this is not meant to be all-inclusive.
- Impact - A section of a how the result will affect an organization.
- Recommendation(s) - Current plan of action to implement.
Finding Metadata
- Author(s) - List of people that worked on a finding.
- Source(s) - Sources the author used for research of a finding.
- Created - Time and date of creation.
- Updated - time and date of an update to a finding.
The recommendation and remediation sections plan to grow over the next few months as we have sizable backlog of tasks to complete! This all can be seen within the web UI as well:
Finding Classification
Each finding is provided a Default Vulnerability Severity Rating (VSR) & a correlated Common Vulnerability Scoring System (CVSS) identifier. This may not work for many organizations, but we feel these are sane defaults.
| Vulnerability Severity Rating | Common Vulnerability Scoring System (CVSS) | Vulnerability Severity Evaluation Criteria |
|---|---|---|
| Level 5 | 8.0 – 10.0 | Finding may allow an attacker to gain remote execution as a privileged or unprivileged user that exposes sensitive data, or allows read/write of a remote system. This may allow an attacker to execute code, change or read sensitive data and break all confidentiality, integrity or accountability of the affected system. |
| Level 4 | 6.0 – 7.9 | The finding may allow an attacker to gain read-only, denial or resources or under certain conditions, the exploitability allows user-mode code execution. |
| Level 3 | 4.0 – 5.9 | The finding may allow an attacker to manipulate or abuse application functionality, denial of service or partial read-only access to application data in a constrained environment. |
| Level 2 | 2.0 – 3.9 | The finding may allow an attacker to obtain sensitive information about a system, internal network, or other identifying data that could lead to further compromise. |
| Level 1 | 0.0 -1.9 | The finding may allow an attacker to gather vague system information. This often occurs to do best practices not being properly implemented. |
API
OS-CFDB also comes with a public API that users can interact with for different automation needs. It will continue to be well documented using Postman https://documenter.getpostman.com/view/4987837/RWThTLeK. This documentation will continue to be updated as the API changes and grows. To get started by running your first API command you simply use CURL:
curl --location --request GET "https://os-cfdb.obscuritylabs.com/api/v1/status"
{
"status": "ok"
}
Our CTA (Call To Action)
Photo by Icons8 team / Unsplash
Too often in prior experience reporting was repetitive, inaccurate and led to time loss incurred. These limitations were due to the absence of a centralized repository for findings, a single source of truth. However, this can raise a greater question of how we can integrate into automation. Moving forward this project hopes to help small, over-tasked, and startups produce valuable data for clients and the organizations they support.
We ask organizations large and small help contribute to the data set to help security organizations of any size understand true risks of a finding, its sources, and enriched with proper remediation strategies.
How can you help us?
1) Contribute Findings
While I have built many of the starter templates there's a long way to go overall, we are missing many of the core areas such as Application testing, IOT, and Mobile. We would love to see technical experts in these areas contribute to the overall project.
2) Contribute Technical Remediation Resources
One of the key factors of reporting is making it useful. We can do this in a number of ways, but within OS-CFBD we envision enriched data accompanied by deep technical Remediation Resources. We plan on publishing a large set of these moving forward for the community as the project grows.
3) Contribute Technical Detection Resources
Finally, the last area of contention for the project lies in Detection resources that are truly actionable for mission sustainment teams to implement. We imagine that technical experts from IR/SOC roles would help play a large key in this. Although we believe in tool agnostic approaches, so this will be a challenge overall. We have seen some decent detection standardization lately, so we hope this is possible.
Article Link: https://blog.obscuritylabs.com/os-cfdb/