VICAR: Bridging the Gap Between Threat Modeling and Remediation

[LFB]

VICAR: Bridging the Gap Between Threat Modeling and Remediation

Sharing an approach that helped our internal threat modeling team have more impact.

This article introduces VICAR, a structure for documenting and communicating threats more effectively.

It explores how continuous, structured documentation can support better threat management over time.

If you’ve found it difficult to turn threat modeling into concrete actions, this approach may be worth exploring.

[Dave]

+1 for adding more structure to threat modelling. Thanks for sharing!

[sjgibbs]

Hi

Structures like this have done well in small engineering teams (see also Given When Then, As a.. I want .. So that… etc) so as an engineer I like this idea.

Did anyone give VICAR a try since it was posted here?

Simon

[Vikram_N]

I did consider it when I was building out Precogly

I’m still not sure how VICAR which is a way to communicate threats to engineers leads to increased implementation of countermeasures. Also, it was not clear as to why VICAR is better than the traditional severity assessment. Hence, I just stuck to a format wherein you can just prioritize threats based on severity. And then assign countermeasures to appropriate team members via an email or Jira ticket.

Would love to understand how one could implement VICAR structures in such an interface as the attached screenshot.

[LFB]

If the attack chain is complex and you have multiple possible countermeasures, the challenge becomes less about prioritizing the threat and more about choosing the right fix. You often can’t apply every control, so you have to make trade-offs. Instead of discarding a threat, you end up discarding certain controls while still mitigating the risk. VICAR just makes the relationship between threats and controls more visible.

I agree it can be overkill for small teams that have full ownership of the application and can directly implement all the fixes themselves. Where it’s been useful for me is in larger environments, where multiple teams are involved in remediation and you start seeing recurring missing or weak controls across different threats.

As for the representation in Precogly, I think the next step is a visual representation of VICAR. The goal would be to show where controls sit within the DFD and help identify the right owner responsible for implementing them. My team is currently working on a prototype to explore this, and it’s still a work in progress.

[Vikram_N]

Thanks for the detailed explanation LFB … really appreciate you taking the time.

I went through the VICAR elements and mapped them against what Precogly currently handles:

• Vector: I associate threats with specific components, but don’t break down the exploit technique as a separate structured field. That’s a gap worth closing.
• Impact: Handled via severity assessment (impact and likelihood).
• Controls and Ranking: Handled via status tracking on countermeasures, along with Zone Protections and Platform Controls for recurring weak controls across multiple threats.

Two things VICAR surfaces that we’re missing:

• Actor: This is an important one. Knowing who can carry out a threat adds useful context for prioritization. I’ll be adding this soon.
• Exploit: Having the specific technique as a structured metadata field on a threat (rather than buried in a description) is valuable. Planning to add this as well.

Your point about visually representing where controls sit within the DFD is also super-valuable. Right now there’s a disconnect between the DFD editor and the threat analysis workspace. They operate on the same underlying data but don’t reflect each other visually. Bridging that gap is something I’m actively scoping out.

Would love to hear more about what your team is exploring with then prototype if you’re open to sharing.

[sjgibbs]

Hi

CyberSec Games visited BSides Prague and we ran two short workshops using our Threat Cards to record player generated insights for Elevation of Privilege and Elevation of MLSec games. Some of the feedback had me again thinking of where VICAR might fit into the CS Games offering.

We noticed workshop attendees did not know what to fill out during the game and what to leave until later. I recall we have had that feedback before.

I think there were several issues:

• The card face mixes threat, control, and gameplay oriented fields. Only two of those (threat and play) are deliberately mixed but even those can be separated.
• Participants were highly conscientious and wanted to be thorough despite playing the games with invented system DFDs. Filling out some fields for an invented system is not really possible in reality so is just a source of stress for the conscientious personality.
• The language on the cards doesn’t align with any particular framework and
• they mix the factual or assumed input data with data that is speculative or calculated

Elevation of Privilege and VICAR both seem to be aimed at developers / software engineers so I set about applying VICAR to the threat card design to better support game based threat modeling.

BEFORE:

(the back here has a pretty picture, but no fields)

AFTER:

The changes align language explicitly to Shostack’s 4 question framework with the front tackling Q2 and the back tackling Q3.

We always describe EoP and it’s variants as scoped to Q2 which means the back contains everything that isn’t required during the game

As a result, I think the “impossible” fields are now all on the back

VICAR labels are used front and back for anything falling within VICAR

With the exception of the Date and Notes field (which have no pre-defined purpose) everything gameplay related is boxed off on the right behind the yellow line.

I called out the association with VICAR by spelling it out faintly with the relevant letters highlighted bold. VICAR and VICAR. I kept this faint so folk can write over it in dark pen. I’m not sure how useful this is but wanted to give folks holding the card something googleable to orient themselves within

If this survives an initial review from this forum, I’d like to support facilitators with some physical copies to see if they help in practice and get some feedback. Reach out if that sounds interesting to you.

Simon

[hewerlin]

Looks beautiful @sjgibbs !

I notice the articulations are quite hypothetic: “What could go wrong?” / “What might we do about it?”

I think in a gaming / kata background, where the goal is not to actually secure a system, this is totally fine. In a real setup, we want to investigate the will-do, not only the might-do.

What are your thoughts?

Is the goal to provide something for both situations - play and real?

[hewerlin]

Also - practical consideration: If the card has a front and a back, I can’t pin it on a wall and see both. Is that a problem?

I’m thinking about my previous experiences with red and green post-its…

[hewerlin]

I like the VICAR-structure that you provide @LFB !

What’s your concept of an actor? Does this comprise the preconditions?

I’ve experimented with structures such as Attacker with [preconditions / actor?] achieves [postconditions / impact] by [attack / vector]. See also GIVEN WHEN THEN Threat Modeling. You add the So we will [control] with prio [ranking].

We seem to have similar thoughts here…

[sjgibbs]

That’s a philosophical question @hewerlin.

During “play” we’re like WOPR. We don’t distinguish between real and simulated inputs. See the whitepaper for some discussion of the pros and cons of that, and the case studies where it’s used on real inputs.

However, if your inputs are simulated then I don’t see a reason to fill out the back, except maybe as an in-class exercise. That means in a play session with simulated inputs the lifecycle of the card ends at the end of the game, or at the end of the training course. They won’t get displayed on a board. The back is “wasted” but that is OK.

Given real inputs I would assume folks are going to do some further work after the game to identify controls and rank them. They might then collect them up, choose which to prioritise and place the controls on a physical kanban board to be implemented, or possibly transfer them into JIRA, or bin them entirely. If the proposed control progresses, then work being visualised becomes the implementation of the control, with the threat as context. Context feels OK on the “back” after the card is reversed.

Does all that match how folks here would understand how to carry forward insights after an in-person threat modeling session with developers?

With respect to the language, I did make Q2 one step less committed by mistake, and Q3 less committed deliberately.

The precise Q2 language is “what can go wrong?”. I don’t see that being material but I will align it to the official language.

For the back (Q3) the accurate language would be “What are we going to to about it?” but that language could be interpreted as a time commitment if placed on a physical kanban board.

I think in the scenario where users brainstorm multiple possible controls that would scare the scrum master and cause confusion. I prefer to clearly label these as suggestions and allow users to improvise another mechanism to record their level of commitment to each option.

I think based on that discussion I’ll add a field for that commitment and retain the modified Q3 language.

Let me know if you have any further thoughts.

Thanks

Simon

[hewerlin]

@sjgibbs Related to that topic, I posted in this particular post why propose-then-choose is a good style for mitigation planning and how my tool supports that with done / favorite / rejected status selection. When we took a look at AttackTree.online, we learned that they have a fascinating dropdown for mitigation status - see image #8. For simplicity, you can just add a " will do" checkbox or something Depends on the kind of workshop you intend to support and there’s tradeoffs in keeping the card simple…