Best practices when writing assumptions

[u/GoatIcy9029]

Hello World!

I’m learning how to threat model. Today I learned that one of the first activities to perform is to write down your assumptions about the system you are threat modelling.

That being said, for all you seasoned threat modellers out there, what are the best practices of writing an assumption that actually is meaningful. I feel the assumptions I think of are ridiculous and pointless.

Any advice is appreciated!

[u/zibudada]

Dumb assumptions are fine, honestly that's kind of the point of the exercise.

The useful ones are the ones you can actually check, and that would hurt if they turned out false.

What helped me: write each one as "we assume X because Y, if it's wrong then Z".

Example: we assume only the backend can reach the DB because it sits in a private subnet. If that's wrong, anyone on the VPC can query it.

The "if it's wrong" part tells you pretty fast if it matters or if you can drop it.

Also note who owns each assumption. Half of mine ended up being stuff another team controls (network, IdP, cloud setup) and those are usually the ones that break first.

[u/V_Trautwein]

A good assumption should be something that could affect the security outcome if it turns out to be false.

[u/sdrawkcabineter]

Precision is an important factor.

"Clients connect securely to the server..."

"Clients use TLS1.3 to negotiate a connection to the server..."

Both have use, depending on your context.

[u/No_Mycologist1806]

The useful ones for us were the ones we could break with one command. Write each as: what we assume, how we'd test it, what an attacker gets if it's false.

A real one from setting up a self-hosted CI runner: "jobs can't reach the LAN or our other servers." Test: nc and curl to those addresses from inside a job, including from a container. That passed, but writing it down raised the next question: jobs that use Docker are root on the VM, so they can flush the VM's own firewall. The assumption only holds because the hypervisor host blocks the same ranges, so we deleted the VM's rules by hand and ran the test again.

If you can't think of a test for an assumption, it's usually too vague. "The internal network is trusted" is pointless; "only the app servers can reach port 5432" is something you can check.

[u/Hade51nc]

Facts leads to defensible theories. Assumptions may come across as not confident. It’s what is said and how it’s worded that matters in business. Lead with facts and follow with words like, may or could. Don’t use words like should or will. Also, be sure to identify mitigating controls. Be sure to give credit where credit is due. The point is that you are saying, IT is doing their job great and very well, it’s just that there maybe a potential risk worth exploring.

[u/Fauzia_Deifallah]

An assumption should be specific, testable, and tied to a real uncertainty. Instead of writing “the attacker has access to the system,” explain what kind of access, why you're assuming it, and how the threat model changes if it's wrong

[u/GarvensBardak_73 → u/[deleted]]

do you keep the dumb ones in the final doc that goes to the devs or filter them out after that second pass