A Look at RACI Models within Application Threat Modeling

Application threat modeling is known to be one of the most effective cybersecurity frameworks. A common question we receive is who should be involved in conducting application threat models.

VerSprite developed a RACI model, which depicts who is Responsible, Accountable, Consulted, and/or Informed as part of the overall threat modeling process. VerSprite customized a RACI model to align with the PASTA threat modeling methodology to bring clarity and a better understanding of where the responsibilities lie across an organization. RACI is a role distribution diagram that helps companies adopt threat modeling while leveraging the roles within an organization and its InfoSec department. It is a straightforward visual to save your team time and resources.

Why is RACI important?

RACI is important in threat modeling in order to build a workflow where there are multiple beneficiaries and stakeholders to a threat modeling process. The risk-centric threat modeling approach of PASTA goes through seven stages where multiple stakeholders will contribute or receive deliverables/ inputs from each stage.  This helps to ensure that the process is both meaningful and effective in building a model of threats for a given application or product.  When everyone involved understands their role in the security and how they can contribute, it makes the threat modeling implementation and sustaining more effective.

In a recent video, Tony UcedaVelez, VerSprite’s CEO and Founder, expands on the importance of the role distribution in cybersecurity:

“It’s surprising to see that no other approach in application threat modeling has constructed a RACI model for other types of approach (e.g. – security centric, software centric, etc.).  VerSprite has spent time to develop the RACI model based upon its interactions with product development teams across various industries.”

RACI Use Cases in PASTA

The security of application does not just rely on code itself. It relies on design, the infrastructure, and the platform or frameworks that it is running on. Oftentimes, threat modeling conversations are not factoring in all these different components, especially the people that have jurisdiction or stewardship over those technologies or efforts.

For example, in threat modeling, during dataflow diagraming exercise, you have developers that call out dataflows that are part of the software model. However, the architects, engineers, business analysts, or even the project managers, that are involved early on in defining requirements for the business are often not factored in. This is why it is so important to make application threat modeling very collaborative and to be an effort that many people can come to the table on.

Quality assurance engineers typically focus on the functional testing. With the role distribution RACI offers, many of them now have an opportunity to also run security unit tests, especially as part of sprints. This becomes really important because quality assurance engineers are able to run some security scripts that are developed by, for example, a DevSecOps group.

One important role that oftentimes gets overlooked is architect, who is responsible for architecting the overall design and patterns to be used and abided by the software product. Many developers are not architects and they simply focus on developing software that relates to their modular component of the product. The architect has the responsibility of overseeing the process and understanding what types of possible permission roles, dataflows, requirements by the business, and compliance laws that should be supported for the overall application model. Not inviting the architect is a major oversight, and in many threat-modeling activities and methodologies you don’t have the inclusion of the architect at all.

Final Thoughts and Prescriptive Advice

It should be mentioned that it is not an obligation to have all of this community of individuals come together and build a threat model. That would be very time consuming. The advantage of using RACI is having a set and efficient way to get either byproduct from each of these constituents, roles, and responsibilities to be used and leveraged, or to get their direct input into the threat model. The overall participation of some of these individuals makes for a better threat model. The better the input, the better the values that go into the understanding of flows, dependencies, the attack surfaces, threats, or threat intel. There are many pieces of information that can be derived by individuals in security operations, engineering, and development in other groups. At the same time, a lot of the roles have limited involvement in building of the threat model. Some of the roles are consulted or informed. This drastically reduces the amount of time and effort required for building an effective threat model while closing important informational gaps.

VerSprite’s RACI diagram is now made available for free on our GitHub page or directly from our website.

To learn more about the importance and implementation of threat modeling, click here.

VS-Labs:Security Research

We Solve Complex Technical Challenges VerSprite’s Research and Development division (a.k.a VS-Labs) is comprised of individuals who are passionate about diving into the internals of various technologies. Our clients rely on VerSprite’s unique offerings of zero-day vulnerability research and exploit development to protect their assets from various threat actors. From advanced technical security training to our research for hire B.O.S.S offering, we help organizations solve their most complex technical challenges.

Learn More