Threat modeling the quick and dirty way - Revision history

Lilith2 at 14:40, 9 October 2015

2015-10-09T14:40:11Z

Lilith2: /* Fill in the table */

2015-10-08T09:59:58Z

‎Fill in the table

Lilith2 at 09:39, 8 October 2015

2015-10-08T09:39:23Z

Lilith2 at 09:38, 8 October 2015

2015-10-08T09:38:11Z

Lilith2 at 09:36, 8 October 2015

2015-10-08T09:36:30Z

Lilith2 at 09:29, 8 October 2015

2015-10-08T09:29:26Z

Lilith2 at 09:28, 8 October 2015

2015-10-08T09:28:55Z

Lilith2 at 09:27, 8 October 2015

2015-10-08T09:27:22Z

Lilith2: /* Examples */

2015-10-08T09:26:40Z

‎Examples

Lilith2 at 09:25, 8 October 2015

2015-10-08T09:25:42Z

← Older revision		Revision as of 14:40, 9 October 2015
Line 1:		Line 1:
−	~~The traditional way of doing threat modelling, if it was done at all, was to sit down and think up attacks until bored (often ones that applications defended against anyway) and then declare victory.~~
−
−	* If we have non-security geeks doing the threat modelling then many attacks get missed or mis-identified. An expert facilitator can catch those.
−	* If we have security geeks involved then there tends to be a focus on attacks like ''sending a server custom-crafted messages that take advantage of the unusual mathematical properties of specially-formatted PKCS #1 message padding in RSA-encrypted data blocks and ignore the fact that the server’s private-key file is world-readable and indexed by Google.'' <ref>Peter Gutmann https://www.cs.auckland.ac.nz/~pgut001/ (yes, the professional paranoid guy, inventor of the Gutmann method, an algorithm for securely erasing the contents of computer hard drives by writing a series of 35 patterns over the region to be erased, and presented in the paper Secure Deletion of Data from Magnetic and Solid-State Memory in July 1996.)</ref>
−	* The problem with checklist-based approaches is that they only work when the attacker is using the same checklist as we are, and isn’t aware that a particular type of attack isn’t supposed to work, then they can walk right past the checklist-standardised defences.
−	* A variation of checklist-based threat modelling is risk mitigation: documenting every risk we can think of and then getting sign-off from someone in authority on the document. As a defense strategy, this is even less effective. But, more job-security oriented.
−	* Even more job-security oriented is an obfuscated checklist in a notation called Common Criteria, that was recovered from an UFO crash site . Don't allow people understanding it near sharp objects. Better yet, shoot on sight.
−
−	~~In the past this has delivered vulnerabilities and measures that provide the best (theoretical) security but very little effective security:~~
−
−	* The Internet Threat Model: I’m OK, you’re OK, and eavesdropping on credit card information sent over the Internet is the threat. Then we build something that people without a phone can not use (while ignoring all other threats).
−	* Inside-out Threat Model: A wonderful piece of circular reasoning which states that the threat model is whatever the security design is capable of defending against (anything that’s hard to defend against is excluded from the threat model).
−	* Provable Security for cryptographic algorithms: algorithms being proven secure against the threats that are defined by the provers (the attacker is transformed into some theoretical bogey man capable of doing anything that we know how to protect against).
−
−	~~Then how?~~
−
	[[File:Dystopia.gif\|500px\|thumb\|right]]		[[File:Dystopia.gif\|500px\|thumb\|right]]

@@ Line 23: / Line 23: @@
 === Fill in the table ===
-I recommend doing a brainstorm on threats as initial filling of the threat columns in the table, before thinking about the other columns.
+I recommend doing iterative brainstorming on "known and experienced threats" as initial filling of the first column in the table, before thinking about the other columns.
 === Reorder the list according to your set of priorities ===

@@ Line 18: / Line 18: @@
 == Basic choreography ==
+Steward Brand: Build a room
-=== Step 1. Set up a table ===
+=== Set up a table ===
 The first column contains a short description of the threat, the second the likelihood of it occurring, the third what impact it would have if it did happen, and the fourth an assessment (grade) of the time and energy you would need to protect yourself from the threat (for instance you can have no stars denote that there is no protection from that threat, hence it will cost nothing (except for the cost of the impact if it did happen).
-=== Step 2. Fill in the table ===
+=== Fill in the table ===
 I recommend doing a brainstorm on threats as initial filling of the threat columns in the table, before thinking about the other columns.
-=== Step 3. Reorder the list according to your set of priorities ===
+=== Reorder the list according to your set of priorities ===
 Choose your ordering strategy carefully. Several strategies are possible.
 * If this is a learning experience or you are a fan of "only time for putting out fires" cultures, no need for ordering.

@@ Line 24: / Line 24: @@
 === Step 2. Fill in the table ===
 I recommend doing a brainstorm on threats as initial filling of the threat columns in the table, before thinking about the other columns.
 {| class="wikitable sortable"
@@ Line 44: / Line 54: @@
 || ***** Implanting stomata. Costly.  Management has suggested we need more surveillance equipment to study the problem of the breaks.
 |}
 === Journalist, observer or sousveillant in europe ===

@@ Line 5: / Line 5: @@
 * The problem with checklist-based approaches is that they only work when the attacker is using the same checklist as we are, and isn’t aware that a particular type of attack isn’t supposed to work, then they can walk right past the checklist-standardised defences.
 * A variation of checklist-based threat modelling is risk mitigation: documenting every risk we can think of and then getting sign-off from someone in authority on the document. As a defense strategy, this is even less effective. But, more job-security oriented.
-* Even more job-security oriented is an obfuscated checklist in a notation recovered from an UFO crash site called Common Criteria. Don't allow people understanding it near sharp objects. Shoot on sight.
+* Even more job-security oriented is an obfuscated checklist in a notation called Common Criteria, that was recovered from an UFO crash site . Don't allow people understanding it near sharp objects. Better yet, shoot on sight.
 In the past this has delivered vulnerabilities and measures that provide the best (theoretical) security but very little effective security:

@@ Line 9: / Line 9: @@
 In the past this has delivered vulnerabilities and measures that provide the best (theoretical) security but very little effective security:
-* The Internet Threat Model: I’m OK, you’re OK, and eavesdropping on credit card information sent over the Internet is the threat. Then we build something that people without a phone can not use.
+* The Internet Threat Model: I’m OK, you’re OK, and eavesdropping on credit card information sent over the Internet is the threat. Then we build something that people without a phone can not use (while ignoring all other threats).
 * Inside-out Threat Model: A wonderful piece of circular reasoning which states that the threat model is whatever the security design is capable of defending against (anything that’s hard to defend against is excluded from the threat model).
 * Provable Security for cryptographic algorithms: algorithms being proven secure against the threats that are defined by the provers (the attacker is transformed into some theoretical bogey man capable of doing anything that we know how to protect against).

← Older revision		Revision as of 09:27, 8 October 2015
Line 113:		Line 113:
	* [[Timeline merchants of death]]		* [[Timeline merchants of death]]
	* [[Threats, detection, protection and (counter) moves]]		* [[Threats, detection, protection and (counter) moves]]
		+
		+	== References ==

← Older revision		Revision as of 09:26, 8 October 2015
Line 52:		Line 52:

	== Examples ==		== Examples ==
−
−	~~=== Protesting in the united states ===~~
−
−	~~{\| class="wikitable sortable"~~
−	\|-
−	~~! Threat !! Likelihood !! Impact !! Protection~~
−	\|-
−	~~\| \|\| \|\| \|\|~~
−	\|}
−
−	~~=== Protesting in the westbank and gaza strip ===~~
−
−	~~{\| class="wikitable sortable"~~
−	\|-
−	~~! Threat !! Likelihood !! Impact !! Protection~~
−	\|-
−	~~\| \|\| \|\| \|\|~~
−	\|}
−
−	~~=== Blogging from egypt ===~~

	=== Journalist, observer or sousveillant in europe ===		=== Journalist, observer or sousveillant in europe ===

@@ Line 1: / Line 1: @@
-The usual pentesting seems to focus mostly on vulnerabilities and measures that provide the best (theoretical) security but very little effective security.
+The traditional way of doing threat modelling, if it was done at all, was to sit down and think up attacks until bored (often ones that applications defended against anyway) and then declare victory.
 * The Internet Threat Model: I’m OK, you’re OK, and eavesdropping on credit card information sent over the Internet is the threat. Then we build something that people without a phone can not use.
@@ Line 5: / Line 13: @@
 * Provable Security for cryptographic algorithms: algorithms being proven secure against the threats that are defined by the provers (the attacker is transformed into some theoretical bogey man capable of doing anything that we know how to protect against).
-[[File:Dystopia.gif|500px|thumb|right]]
+Then how?
-== So how are we going to build a realistic threat model for applications? ==
+[[File:Dystopia.gif|500px|thumb|right]]
-−
-The traditional way of doing this, if it was done at all, was to sit down and think up attacks until bored (often ones that applications defended against anyway) and then declare victory.
-−
-* If we have non-security geeks doing the threat modelling then many attacks get missed or mis-identified. An excellent tech facilitator catches those.
-* If we have security geeks involved then they tend to focus on attacks like ''sending a server custom-crafted messages that take advantage of the unusual mathematical properties of specially-formatted PKCS #1 message padding in RSA-encrypted data blocks and ignore the fact that the server’s private-key file is world-readable and indexed by Google.'' <ref>Peter Gutmann https://www.cs.auckland.ac.nz/~pgut001/ (yes, the professional paranoid guy, inventor of the Gutmann method, an algorithm for securely erasing the contents of computer hard drives by writing a series of 35 patterns over the region to be erased, and presented in the paper Secure Deletion of Data from Magnetic and Solid-State Memory in July 1996.)</ref>
-* The problem with checklist-based approaches is that they only work when the attacker is using the same checklist as we are, and isn’t aware that a particular type of attack isn’t supposed to work, then they can walk right past the checklist-standardised defences.
-* A variation of checklist-based threat modelling is risk mitigation: documenting every risk we can think of and then getting sign-off from someone in authority on the document. As a defense strategy, this is even less effective. But, more job-security oriented.
-* Even more job-security oriented is an obfuscated checklist in a notation recovered from a UFO crash site called Common Criteria. Don't allow people understanding it near sharp objects. Shoot on sight.
 == Basic choreography ==