Skip to content

Announcing Product Registry and Analytics

ross-sneddon-sWlDOWk0Jp8-unsplashEarlier this month we opened the early access for the Community Edition of the Tidal Platform. The Community Edition delivers on a core value of the Tidal team: to give back to the community, giving them the tools and data to implement threat-informed defense. A key aspect to this is to help them better leverage the MITRE ATT&CK® knowledge base that so many have benefited from, and so many more should.

We are marching towards the public opening of the platform, and as we do, we continue to take feedback from our users and release additional functionality. Today’s release is special for a couple of reasons, namely the addition of Product Registry and Analytics to our Platform. Why are these features so important? Because they let us move beyond information about the threat to what to do about the threat.

Product Registry

product registry screenshotThe Product Registry is core to the Tidal Platform. It is meant to show users the possible solutions they may have or could get to address specific adversary behaviors. Included in the Registry are both capabilities, which describe how the product protects, detects, responds, or tests ATT&CK Techniques, as well as product data sources, which describe the data products generate that map to ATT&CK Data Components.

Today when you go to the Product Registry you will see two open-source capabilities: Atomic Red Team’s Invoke-Atomic and Olaf Hartong’s Sysmon Modular. In the coming weeks, you will begin to see commercial data starting to populate the Registry alongside these open-source capabilities. A special thanks to both the Red Canary team and Olaf for allowing us to showcase their capabilities in our platform and making it extremely easy for us to integrate due to their existing ATT&CK mappings.

A unique trait to the Registry is that it is the vendors who submit their ATT&CK mappings to Tidal for publication. We intentionally wanted to give the vendors, who know their tools better than anyone, the platform to be able to describe their capabilities in their own words. We then made it free for vendors to submit, to make it as easy as possible for any of them wanting to share this information to do so. This also ensures that Tidal maintains a vendor-neutral environment so we can always advocate for the end-users leveraging the information.

One of the key challenges with the Product Registry is how to make ATT&CK mappings useful. Too often vendors and end-users alike have created overly generic mappings, treating ATT&CK as a checklist rather than giving end users the context needed to make the decisions on whether to use a product or enable a capability. The solultion to this issue is providing context to the mappings.

If we asked for too much context, the burden would be too high to get vendors to share the data for a variety of reasons, from security to intellectual property to level of effort. We need to thread the needle of providing enough information to be useful, but not too much to ensure vendors can and will share the data. In the end, we determined the most important context relates to how the capability can be obtained.

For example, in my prior life in ATT&CK Evaluations, some vendors would come with a default configuration, others with increased sensitivity, and some with specialized rulesets. All of these were permitted within the rules of engagement, and for valid reasons. But unfortunately, you didn’t know what capability required that special ruleset or was part of the default configuration. This made any kind of comparison hard.

So, the solution? Give the vendor a chance to show their coverage, but then give them a clear mechanism to say how you achieve that coverage in their own words. Let them say it’s in a special ruleset, and here is where you get it, and these are the considerations to make if that’s the case. Or tell their users they are safe because it’s part of the default configuration. No one wants disappointed customers, so rather than making them be overly generic, which could lead to frustration, instead we can bring more transparency and common understanding of capabilities.

Another challenge to ATT&CK mappings often comes down to accuracy. This often comes up when people start talking about procedures. While we recognize the value in better definition around procedures, we have taken the deliberate incremental step of more structured definition around techniques. We have several ideas on how to bring procedures into more focus as we evolve. For now, we hope this will be a significant step forward, and we won’t make perfect be the enemy of the good.

If you are a Vendor or open-source tool creator, and you would like to see your mappings within the Tidal platform, please let us know here. We are actively working with many vendors across the spectrum from EDR/XDR to BAS to PAM and beyond, and would love to include you.

Analytics

You might be thinking, “I just read about capabilities, and detection capabilities are included in there, so why is there another section on analytics?” To us, we consider a detection capability to be different than an analytic. A detection capability can be an instantiation of an analytic. Put another way, an analytic is a product-less capability. A prime example of this is a Sigma rule. Sigma defines themselves as:

Sigma is a generic and open signature format that allows you to describe relevant log events in a straightforward manner. The rule format is very flexible, easy to write and applicable to any type of log file. The main purpose of this project is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.

Key words there are generic, flexible, applicable to any type of log file, and sharable. Analytics are tool agnostic. Capabilities, on the other hand, are inherently tied to the tools that execute them.

To help tease out the differences, take this use case: someone is investigating a specific technique. In this example, they do not have a product with a capability. What they do have is the data component information that ATT&CK provides. They have the rules that Sigma provides. They have the product data sources mapped to ATT&CK data components. They have all the pieces to go and create a new detection capability, by writing that rule for that product.

Today we released the first analytics within the platform: Sigma’s ATT&CK rules. Thank you to Florian Roth, Sigma and all their contributors for their hard work, and we hope to expose more people to their great work. We plan to continue to expand our analytic support into other repositories in the future, but if you have specific open-source information you would like to see us integrate, or if you would like to submit your own content, please contact us.

Join the Rising Tide!

The Tidal Platform is still in Early Access, but we welcome new members to our growing community. To join, please register here. We are continually releasing new content and appreciate anyone’s interest in providing feedback on how to improve our platform ahead of our public launch, as well as what they would like to see in our next great threat-informed defense enablement feature.