次の方法で共有

A discussion on threat modeling

  • [アーティクル]

There is a discussion I had recently with a few folks over email around threat modeling that I thought would be nice to share on this blog. I’ll reduce the discussion down to 3 questions/responses.

Question: Where does the line between Threat Modeling and documenting operational best practices begin and end?

Response: A good threat model document’s OUTPUTs should be used as the INPUTs to tech specs and operational best practices. E.g., I just threat modeled our new Data Backup process and discovered a flaw that I can mitigate with a technique X that is not documented in our guidance, operational documents, policies, standards, etc. So maybe I should update them. And WOW, wouldn’t it be great if then I can share this knowledge with folks doing TMs against same similar kinds of processes so they don’t have to research X? This is the example of the interplay between Threat Models and CTL in TAMe.”

Question: How does an operational ‘attack’ like stealing backup tapes fit into CIA or STRIDE?

Response: CIA is a THREAT categorization and STRIDE is more of a SOFTWARE ATTACK categorization. Threats are like “what if” scenarios: what if my credit card numbers are stolen… what if my backup tapes are stolen. Attacks are active actions that give rise to the realization of a threat: I can SQL inject on this entry point to get credit cards… I can steal the backup tapes from the courier’s truck while it’s in transit. Jumping to think about attacks without knowing the threat is ineffective as you don’t have any prioritization (do I need to worry about data integrity here with this attack? Do I need to worry about DoS attack here for availability compromise?).

Question: How is TAMe (Threat Analysis & Modeling Enterprise) intended to model non-application scenarios (operational, infrastructure, etc.)”

Response: TAM/TAMe has been application focused (through the nomenclature and interface) on purpose so even though it may not seem like it can model operational/infrastructure/etc. scenarios, it EASILY CAN*. For operational scenario, for example, you would identify different component (one of those would be the courier’s car). You would also define Roles (one of those would be the driver/courier). You would also define data pieces (one of those would be the backup tapes). Then you would bind these pieces together under a use cases through a sequence of calls. One of these calls would be the driver (Role) initiating a transfer (Action) of backup tapes (Data) into the truck (Component). At this point, the tool/process would force you to consider three distinct threats in isolation for this call:

  1. Confidentiality: What if someone takes the backup tapes, makes a copy, and then returns the tape as if nothing happened.
  2. Integrity: What is someone takes the tapes, overrates the content, and then returns the tapes as if nothing happened.
  3. Availability: What is someone takes the tapes. Period.

Then when you start looking at these 3 threats, and propose different countermeasures (we’ll skip attacks):

  1. Confidentiality: I need to make sure data is encrypted.
  2. Integrity: I need to make sure data is digitally signed so it can’t be tampered.
  3. Availability: (operational) I need to make sure the backup tapes are always in site and secured in the truck (e.g., through physical locks).

Threat modeling is not a magic process/tool where you just throw stuff in and out comes goodness. Threat modeling is a structured way of thinking about and addressing the risks to what you are about to build rather than going about it randomly.

As always, continue to provide your feedback/questions through submitted comments or sending an email through the ‘Email’ link on the top.
*Imagine in the future being able to go into TAM and Select File - > New -> Operational Threat Model or Application Threat Model or Infrastructure Threat Model… oops, I’ve said too much... :-)

Thanks.

-Talhah

Comments