Modeling organizations’ defensive mechanisms with MITRE D3FEND

Funded by the National Security Agency, MITRE’s D3FEND framework is helping to provide standardization, specificity, and repeatability needed by cybersecurity engineers. As the framework moves from the beta version to version 1.0 in 2024, we asked D3FEND creator Peter Kaloroumakis how D3FEND will strengthen the cybersecurity community.

Can you walk us through the inception of D3FEND and what specific needs in the cybersecurity landscape it aims to address?

There are several needs we wanted to address with D3FEND. Primarily we wanted simple and clear definitions of specific cybersecurity capabilities and functionalities. The current state of the art describes these technologies with very broad acronyms. This works in casual conversation, but when you’re designing a complex system, it is quite insufficient.

Given the complexity of cybersecurity threats, how does D3FEND facilitate a more proactive and dynamic defense mechanism for organizations?

D3FEND aims to help organizations model their defensive mechanisms, which we call countermeasures. Previously, modeling has been an area of underinvestment in cybersecurity, mostly due to questionable returns on investment. However, by taking a radically different approach, we will lower the cost of entry and make modeling your defenses useful.

You’ve opted to keep D3FEND in beta since its release in 2021. What have been the most significant changes or improvements made to the model based on user feedback?

We’ve significantly expanded the hardening section of D3FEND, looking at the plethora of vulnerabilities that attackers could use to gain access. Practitioners are interested in prevention technologies and configurations because doing detection and cleanup is expensive.

D3FEND has seen a significant increase in collaboration and adoption by vendors. Can you share some insights on how these collaborations have shaped the evolution of the solution?

As D3FEND grows, we’ll need our community to grow even more. We’re incredibly thankful to the security architects, application security analysts, detection engineers, compliance experts, expert ontologists, and all whose contributions have been essential to D3FEND’s progress.

For instance, some vendors, despite having their own product objectives, remain vendor neutral in their functionality definitions because their product integrates other products from the ecosystem. Thus, a desire for vendor-neutral language coming from the vendors themselves prioritized additions to D3FEND that we were not initially planning but have been highly valuable.

Regarding usability, what steps are you taking to ensure that D3FEND can be easily applied across various domains, and what challenges have you had in this endeavor?

We outline our roadmap to D3FEND 1.0. Ease of use is a key focus of this roadmap. We have released an early version of a REST API (REpresentational State Transfer Application Programming Interface), but a simpler, client-side API is necessary to accelerate integration and use amongst vendors and practitioners.

D3FEND is built on semantic graph technology, however, most people in cybersecurity are not familiar with this technology domain and there is a lot of complexity. Our approach with the client-side APIs will abstract these complexities from the user to make data access more ergonomic.

How does D3FEND balance being a formal model and a knowledge base, and what are the challenges in maintaining this dual purpose?

This is a great question, and to date, this is a truly unique aspect of D3FEND. The biggest challenge is update speed. Sometimes concepts in cybersecurity are so general that it makes it difficult to model the knowledge in a formal way. Like most challenges, this is an opportunity. When we can break concepts down and fit them in the model, we are creating new shared knowledge and clarity.

Integrating the Common Weakness Enumeration (CWE) is a significant step. How will this integration improve D3FEND’s capability to address software and hardware weaknesses?

A key insight we had was modeling exactly what the weakness or vulnerability is in. Inside of D3FEND is a complex computer systems model, which we call the digital artifact ontology, and it is further discussed in our paper. Once we identify which component has a weakness, we can then infer potential countermeasures to address that weakness.

Perhaps using isolation, detection, or hardening techniques as countermeasures. These would be in addition to just updating the software with the specific vulnerability, assuming there is an update available. This work is in an early stage, and there is a lot more to do. We hope to share more on this in the future.

Can you elaborate on the importance of aligning D3FEND with formal upper ontologies like BFO and UFO and what challenges this alignment presents?

Ontology is really the secret sauce of D3FEND. However, this is a complicated topic which warrants significant discussion. Many people disagree on what even qualifies as an ontology. Our approach to date has been use-case-focused design of the D3FEND ontology, contrasting with a purely academic arrangement of concepts without a specific use-case in mind.

The consequences of these different approaches are significant and have implications when you are in the model-based systems engineering domain (MBSE). Compatibility with these upper ontologies is crucial to enable MBSE applications of D3FEND. This is something we have had planned for years, but over the next year, it will be a top development priority.

Finally, a deprecation strategy is critical for the evolution of any framework. How would you like to implement this strategy without disrupting the workflow of current D3FEND users?

The depreciations will be embedded in the model itself; this is a feature of the ontology technology we are using. Our goal is that this will be transparent to the user, and we will share more details on this once we have completed the design.