Saturday, August 30, 2008

Ubiquity Security Concerns Part 1: An Introduction

Introduction

I recently watched a short video about a Mozilla Labs project called Ubiquity. After watching this video, I became extremely excited about using the features presented and extremely scared of how the extension could be exploited to compromise personal data. I wanted to both benefit from this awesome and fun extension and also find ways to execute arbitrary JavaScript within others' browsers (the same feeling I get whenever I use Google). It may be helpful to briefly watch this video to understand this sentiment:

http://www.vimeo.com/1561578?pg=embed&sec=1561578

After watching this video, my first thoughts were:

1. I wonder if an attacker could write a command to send arbitrary GMail messages on the users' behalf, watch every page the users visit, steal passwords, and even compromise users' computers.

and

2. How difficult would it be for an attacker to trick a user into installing the command or cause the command to be installed in an automated fashion?

The short answer to 1. is YES (details provided below)! Answering 2., specifically the automated portion, will require some research.

Ubiquity Developers' Awareness of Security Concerns

Before anyone gets too worked up about these security issues, I should make sure it is clear that this project is far from being complete, the authors are well aware that there a significant security concerns, and they are in the process of determining a method to reduce the risk of malicious commands or other exploits.

Examples of this awareness can be found in Atul's blog entries:

Trusting Functionality and Towards Inter-Community Trust

"At present, because our project is still in the prototyping stage, we’re opting for freedom of expressiveness and experimentation over security. That means that all the various verbs we write, while written in JavaScript, are always executed with Chrome privileges, meaning that they’re capable of doing whatever they want to the end-user’s computer."

"So the particular dilemma that needs to be solved here is: how can an end-user trust that a verb won’t do anything harmful to their data or privacy—be it intentional or accidental—while still providing a low barrier of entry for aspiring authors to write and distribute their own verbs?"

More specific concerns can be found in the Ubiquity Author Tutorial.

Ubiquity_0.1_Author_Tutorial#Sharing_it_with_the_World

"If the user chooses to subscribe to a command from an untrusted source, they will get a security warning message before they can install the command. (And in Ubiquity 0.1, ALL sources are considered untrusted, so don't take it personally!) Because Ubiquity commands can execute arbitrary javascript with chrome privileges, subscribing to a command from a website means allowing that site full access to do whatever it wants to your browser. We want to make sure people understand the dangers before subscribing to commands, so we made the warning page pretty scary."

"In the future, we're going to have something set up that we call a "trust network". When you try out a Ubiquity command from a website, and determine that the command is safe (or unsafe), you'll be able to leave an approval (or a warning). When your friends with Ubiquity installed visit the same site, they'll see the approval or the warning that you left. In this way, users will be able to rely on the judgement of other people they already know and trust in order to help them make decisions about whether a command is safe to install or not."

"By the way, the reason we call it "subscribing" to a command, rather than "installing" a command, is that if the javascript file changes -- if the site owner adds new commands, removes old commands, or updates existing commands -- all users subscribed to that URL will automatically get the updates. This will be very convenient for both users and developers, but it will also introduce another type of security risk: just because you decided a command was safe at one point in time doesn't mean that the command will always remain safe. For this reason, we'll need to make sure that the trust network keeps track of when commands have been modified, and notifies users of changes that may make a command unsafe."

Possible topics for Part 2 - ?

I plan on digging into these ideas in future posts, and have listed a few possibilities below. If you have a preference or other suggestions, feel free to leave a comment.

Using Ubiquity for Evil:
Basically, a discussion of Ubiquity features and how they could be used maliciously.

Subscription Exploits:
Results of research into whether commands could be installed in an automated fashion without the user's permission.

Ubiquity Trust Model:
Examination of how the trust model protects users from subscribing to malicious commands. This article may have to occur once that trust model has been determined by the project developers.

Saturday, August 9, 2008

Presentation Layer Output Encoding: Apache Commons Lang StringEscapeUtils vs. OWASP Reform

*Updated to include OWASP ESAPI Results on August 21, 2008*

In order to compare the effectiveness of the Apache Commons Lang StringEscapeUtils and the OWASP Reform library, I created a JSP page that encodes ASCII values from 0 to 255. I chose to examine the ability of each library to encode HTML and JavaScript values for the purpose of preventing cross-site scripting attacks. The results are shown at the bottom of this post.

In general, both the ESAPI and Reform libraries encode any value other than a-z, A-Z, and 0-9 (there are some exceptions). This is a great approach to ensuring client-side input cannot be interpreted as HTML or JavaScript commands when it is redisplayed in the browser.

ESAPI is under active development and boasts a variety of other security related functionality that may benefit an organization. I encourage everyone to take a look at the ESAPI OWASP project.

The rest of this post is provided as a reference.

Apache Commons Lang StringEscapeUtils Methods:
  • escapeHtml
  • escapeJava
  • escapeJavaScript
  • escapeSql
  • escapeXml
  • unescapeHtml
  • unescapeJava
  • unescapeJavaScript
  • unescapeXml

OWASP Reform Methods:
  • HtmlEncode
  • HtmlAttributeEncode
  • XmlEncode
  • XmlAttributeEncode
  • JsString
  • VbsString
OWASP ESAPI (SVN Snapshot 2008-08-21) Methods:
  • canonicalize
  • normalize
  • encodeForCSS
  • encodeForHTML
  • encodeForHTMLAttribute
  • encodeForJavaScript
  • encodeForVBScript
  • encodeForSQL
  • encodeForLDAP
  • encodeForDN
  • encodeForXPath
  • encodeForXML
  • encodeForXMLAttribute
  • encodeForURL
  • decodeFromURL
  • encodeForBase64
  • decodeFromBase64

Legend:
ASCII - The numerical ASCII value
Char - The symbol or character associated with that ASCII value
SEU HTML - org.apache.commons.lang.StringEscapeUtils.escapeHtml
Reform HTML - org.owasp.reform.Reform.HtmlEncode
ESAPI HTML - org.owasp.esapi.Encoder.encodeForHTML
SEU JS - org.apache.commons.lang.StringEscapeUtils.escapeJavaScript
Reform JS - org.owasp.reform.Reform.JsString
ESAPI JS - org.owasp.esapi.Encoder.encodeForJavaScript

ASCIICharSEU
HTML
Reform
HTML
ESAPI
HTML
SEU
JS
Reform
JS
ESAPI
JS
0

�
\u0000'\x00'\0
1 
\u0001'\x01'\x01
2 
\u0002'\x02'\x02
3 
\u0003'\x03'\x03
4 
\u0004'\x04'\x04
5 
\u0005'\x05'\x05
6 
\u0006'\x06'\x06
7 
\u0007'\x07'\x07
8 
\b'\x08'\b
9

	
\t'\x09'\t
10



\n'\x0a'\n
11    
\u000B'\x0b'\v
12    
\f'\x0c'\f
13


\r'\x0d'\r
14 
\u000E'\x0e'\x0E
15 
\u000F'\x0f'\x0F
16 
\u0010'\x10'\x10
17 
\u0011'\x11'\x11
18 
\u0012'\x12'\x12
19 
\u0013'\x13'\x13
20 
\u0014'\x14'\x14
21 
\u0015'\x15'\x15
22 
\u0016'\x16'\x16
23 
\u0017'\x17'\x17
24 
\u0018'\x18'\x18
25 
\u0019'\x19'\x19
26 
\u001A'\x1a'\x1A
27 
\u001B'\x1b'\x1B
28 
\u001C'\x1c'\x1C
29 
\u001D'\x1d'\x1D
30 
\u001E'\x1e'\x1E
31 
\u001F'\x1f'\x1F
32




' '
33!!!!!'\x21'\x21
34""""\"'\x22'\"
35#####'\x23'\x23
36$$$$$'\x24'\x24
37%%%%%'\x25'\x25
38&&&&&'\x26'\x26
39''''\''\x27'\'
40((((('\x28'\x28
41)))))'\x29'\x29
42*****'\x2a'\x2A
43+++++'\x2b'\x2B
44,,,,,',',
45-----'\x2d'-
46.....'.'.
47////\/'\x2f'\x2F
4800000'0'0
4911111'1'1
5022222'2'2
5133333'3'3
5244444'4'4
5355555'5'5
5466666'6'6
5577777'7'7
5688888'8'8
5799999'9'9
58:::::'\x3a'\x3A
59;;&#59;&#59;;'\x3b'\x3B
60<&lt;&#60;&lt;<'\x3c'\x3C
61==&#61;&#61;='\x3d'\x3D
62>&gt;&#62;&gt;>'\x3e'\x3E
63??&#63;&#63;?'\x3f'\x3F
64@@&#64;&#64;@'\x40'\x40
65AAAAA'A'A
66BBBBB'B'B
67CCCCC'C'C
68DDDDD'D'D
69EEEEE'E'E
70FFFFF'F'F
71GGGGG'G'G
72HHHHH'H'H
73IIIII'I'I
74JJJJJ'J'J
75KKKKK'K'K
76LLLLL'L'L
77MMMMM'M'M
78NNNNN'N'N
79OOOOO'O'O
80PPPPP'P'P
81QQQQQ'Q'Q
82RRRRR'R'R
83SSSSS'S'S
84TTTTT'T'T
85UUUUU'U'U
86VVVVV'V'V
87WWWWW'W'W
88XXXXX'X'X
89YYYYY'Y'Y
90ZZZZZ'Z'Z
91[[&#91;&#91;['\x5b'\x5B
92\\&#92;&#92;\\'\x5c'\\
93]]&#93;&#93;]'\x5d'\x5D
94^^&#94;&#94;^'\x5e'\x5E
95__&#95;__'\x5f'_
96``&#96;&#96;`'\x60'\x60
97aaaaa'a'a
98bbbbb'b'b
99ccccc'c'c
100ddddd'd'd
101eeeee'e'e
102fffff'f'f
103ggggg'g'g
104hhhhh'h'h
105iiiii'i'i
106jjjjj'j'j
107kkkkk'k'k
108lllll'l'l
109mmmmm'm'm
110nnnnn'n'n
111ooooo'o'o
112ppppp'p'p
113qqqqq'q'q
114rrrrr'r'r
115sssss's's
116ttttt't't
117uuuuu'u'u
118vvvvv'v'v
119wwwww'w'w
120xxxxx'x'x
121yyyyy'y'y
122zzzzz'z'z
123{{&#123;&#123;{'\x7b'\x7B
124||&#124;&#124;|'\x7c'\x7C
125}}&#125;&#125;}'\x7d'\x7D
126~~&#126;&#126;~'\x7e'\x7E
127&#127;
'\x7f'\x7F
128&#128;&#128;
\u0080'\u0080'\x80
129&#129;&#129;
\u0081'\u0081'\x81
130&#130;&#130;
\u0082'\u0082'\x82
131ƒ&#131;&#131;
\u0083'\u0083'\x83
132&#132;&#132;
\u0084'\u0084'\x84
133&#133;&#133;
\u0085'\u0085'\x85
134&#134;&#134;
\u0086'\u0086'\x86
135&#135;&#135;
\u0087'\u0087'\x87
136ˆ&#136;&#136;
\u0088'\u0088'\x88
137&#137;&#137;
\u0089'\u0089'\x89
138Š&#138;&#138;
\u008A'\u008a'\x8A
139&#139;&#139;
\u008B'\u008b'\x8B
140Œ&#140;&#140;
\u008C'\u008c'\x8C
141&#141;&#141;
\u008D'\u008d'\x8D
142Ž&#142;&#142;
\u008E'\u008e'\x8E
143&#143;&#143;
\u008F'\u008f'\x8F
144&#144;&#144;
\u0090'\u0090'\x90
145&#145;&#145;
\u0091'\u0091'\x91
146&#146;&#146;
\u0092'\u0092'\x92
147&#147;&#147;
\u0093'\u0093'\x93
148&#148;&#148;
\u0094'\u0094'\x94
149&#149;&#149;
\u0095'\u0095'\x95
150&#150;&#150;
\u0096'\u0096'\x96
151&#151;&#151;
\u0097'\u0097'\x97
152˜&#152;&#152;
\u0098'\u0098'\x98
153&#153;&#153;
\u0099'\u0099'\x99
154š&#154;&#154;
\u009A'\u009a'\x9A
155&#155;&#155;
\u009B'\u009b'\x9B
156œ&#156;&#156;
\u009C'\u009c'\x9C
157&#157;&#157;
\u009D'\u009d'\x9D
158ž&#158;&#158;
\u009E'\u009e'\x9E
159Ÿ&#159;&#159;
\u009F'\u009f'\x9F
160 
&nbsp;&#160;&nbsp;\u00A0'\u00a0'\xA0
161¡&iexcl;&#161;&iexcl;\u00A1'\u00a1'\xA1
162¢&cent;&#162;&cent;\u00A2'\u00a2'\xA2
163£&pound;&#163;&pound;\u00A3'\u00a3'\xA3
164¤&curren;&#164;&curren;\u00A4'\u00a4'\xA4
165¥&yen;&#165;&yen;\u00A5'\u00a5'\xA5
166¦&brvbar;&#166;&brvbar;\u00A6'\u00a6'\xA6
167§&sect;&#167;&sect;\u00A7'\u00a7'\xA7
168¨&uml;&#168;&uml;\u00A8'\u00a8'\xA8
169©&copy;&#169;&copy;\u00A9'\u00a9'\xA9
170ª&ordf;&#170;&ordf;\u00AA'\u00aa'\xAA
171«&laquo;&#171;&laquo;\u00AB'\u00ab'\xAB
172¬&not;&#172;&not;\u00AC'\u00ac'\xAC
173­&shy;&#173;&shy;\u00AD'\u00ad'\xAD
174®&reg;&#174;&reg;\u00AE'\u00ae'\xAE
175¯&macr;&#175;&macr;\u00AF'\u00af'\xAF
176°&deg;&#176;&deg;\u00B0'\u00b0'\xB0
177±&plusmn;&#177;&plusmn;\u00B1'\u00b1'\xB1
178²&sup2;&#178;&sup2;\u00B2'\u00b2'\xB2
179³&sup3;&#179;&sup3;\u00B3'\u00b3'\xB3
180´&acute;&#180;&acute;\u00B4'\u00b4'\xB4
181µ&micro;&#181;&micro;\u00B5'\u00b5'\xB5
182&para;&#182;&para;\u00B6'\u00b6'\xB6
183·&middot;&#183;&middot;\u00B7'\u00b7'\xB7
184¸&cedil;&#184;&cedil;\u00B8'\u00b8'\xB8
185¹&sup1;&#185;&sup1;\u00B9'\u00b9'\xB9
186º&ordm;&#186;&ordm;\u00BA'\u00ba'\xBA
187»&raquo;&#187;&raquo;\u00BB'\u00bb'\xBB
188¼&frac14;&#188;&frac14;\u00BC'\u00bc'\xBC
189½&frac12;&#189;&frac12;\u00BD'\u00bd'\xBD
190¾&frac34;&#190;&frac34;\u00BE'\u00be'\xBE
191¿&iquest;&#191;&iquest;\u00BF'\u00bf'\xBF
192À&Agrave;&#192;&Agrave;\u00C0'\u00c0'\xC0
193Á&Aacute;&#193;&Aacute;\u00C1'\u00c1'\xC1
194Â&Acirc;&#194;&Acirc;\u00C2'\u00c2'\xC2
195Ã&Atilde;&#195;&Atilde;\u00C3'\u00c3'\xC3
196Ä&Auml;&#196;&Auml;\u00C4'\u00c4'\xC4
197Å&Aring;&#197;&Aring;\u00C5'\u00c5'\xC5
198Æ&AElig;&#198;&AElig;\u00C6'\u00c6'\xC6
199Ç&Ccedil;&#199;&Ccedil;\u00C7'\u00c7'\xC7
200È&Egrave;&#200;&Egrave;\u00C8'\u00c8'\xC8
201É&Eacute;&#201;&Eacute;\u00C9'\u00c9'\xC9
202Ê&Ecirc;&#202;&Ecirc;\u00CA'\u00ca'\xCA
203Ë&Euml;&#203;&Euml;\u00CB'\u00cb'\xCB
204Ì&Igrave;&#204;&Igrave;\u00CC'\u00cc'\xCC
205Í&Iacute;&#205;&Iacute;\u00CD'\u00cd'\xCD
206Î&Icirc;&#206;&Icirc;\u00CE'\u00ce'\xCE
207Ï&Iuml;&#207;&Iuml;\u00CF'\u00cf'\xCF
208Ð&ETH;&#208;&ETH;\u00D0'\u00d0'\xD0
209Ñ&Ntilde;&#209;&Ntilde;\u00D1'\u00d1'\xD1
210Ò&Ograve;&#210;&Ograve;\u00D2'\u00d2'\xD2
211Ó&Oacute;&#211;&Oacute;\u00D3'\u00d3'\xD3
212Ô&Ocirc;&#212;&Ocirc;\u00D4'\u00d4'\xD4
213Õ&Otilde;&#213;&Otilde;\u00D5'\u00d5'\xD5
214Ö&Ouml;&#214;&Ouml;\u00D6'\u00d6'\xD6
215×&times;&#215;&times;\u00D7'\u00d7'\xD7
216Ø&Oslash;&#216;&Oslash;\u00D8'\u00d8'\xD8
217Ù&Ugrave;&#217;&Ugrave;\u00D9'\u00d9'\xD9
218Ú&Uacute;&#218;&Uacute;\u00DA'\u00da'\xDA
219Û&Ucirc;&#219;&Ucirc;\u00DB'\u00db'\xDB
220Ü&Uuml;&#220;&Uuml;\u00DC'\u00dc'\xDC
221Ý&Yacute;&#221;&Yacute;\u00DD'\u00dd'\xDD
222Þ&THORN;&#222;&THORN;\u00DE'\u00de'\xDE
223ß&szlig;&#223;&szlig;\u00DF'\u00df'\xDF
224à&agrave;&#224;&agrave;\u00E0'\u00e0'\xE0
225á&aacute;&#225;&aacute;\u00E1'\u00e1'\xE1
226â&acirc;&#226;&acirc;\u00E2'\u00e2'\xE2
227ã&atilde;&#227;&atilde;\u00E3'\u00e3'\xE3
228ä&auml;&#228;&auml;\u00E4'\u00e4'\xE4
229å&aring;&#229;&aring;\u00E5'\u00e5'\xE5
230æ&aelig;&#230;&aelig;\u00E6'\u00e6'\xE6
231ç&ccedil;&#231;&ccedil;\u00E7'\u00e7'\xE7
232è&egrave;&#232;&egrave;\u00E8'\u00e8'\xE8
233é&eacute;&#233;&eacute;\u00E9'\u00e9'\xE9
234ê&ecirc;&#234;&ecirc;\u00EA'\u00ea'\xEA
235ë&euml;&#235;&euml;\u00EB'\u00eb'\xEB
236ì&igrave;&#236;&igrave;\u00EC'\u00ec'\xEC
237í&iacute;&#237;&iacute;\u00ED'\u00ed'\xED
238î&icirc;&#238;&icirc;\u00EE'\u00ee'\xEE
239ï&iuml;&#239;&iuml;\u00EF'\u00ef'\xEF
240ð&eth;&#240;&eth;\u00F0'\u00f0'\xF0
241ñ&ntilde;&#241;&ntilde;\u00F1'\u00f1'\xF1
242ò&ograve;&#242;&ograve;\u00F2'\u00f2'\xF2
243ó&oacute;&#243;&oacute;\u00F3'\u00f3'\xF3
244ô&ocirc;&#244;&ocirc;\u00F4'\u00f4'\xF4
245õ&otilde;&#245;&otilde;\u00F5'\u00f5'\xF5
246ö&ouml;&#246;&ouml;\u00F6'\u00f6'\xF6
247÷&divide;&#247;&divide;\u00F7'\u00f7'\xF7
248ø&oslash;&#248;&oslash;\u00F8'\u00f8'\xF8
249ù&ugrave;&#249;&ugrave;\u00F9'\u00f9'\xF9
250ú&uacute;&#250;&uacute;\u00FA'\u00fa'\xFA
251û&ucirc;&#251;&ucirc;\u00FB'\u00fb'\xFB
252ü&uuml;&#252;&uuml;\u00FC'\u00fc'\xFC
253ý&yacute;&#253;&yacute;\u00FD'\u00fd'\xFD
254þ&thorn;&#254;&thorn;\u00FE'\u00fe'\xFE
255ÿ&yuml;&#255;&yuml;\u00FF'\u00ff'\xFF

Thursday, August 7, 2008

SAML Research Road Map

Recently, I have been asked by several people about SAML as it pertains to single sign-on for web applications. At the time, I was not familiar with this standard or the technology surrounding it and decided to do some research. I discovered there were a lot of valuable resources on the web, but there was not an easy to understand road map describing the order in which to read these items.

This article is an attempt to provide that road map, so others can understand and appreciate SAML.

Note: This article pertains to SAML 2.0 and not SAML 1.x.

Introduction

From the OASIS SAML Technical Overview Document:

“The OASIS Security Assertion Markup Language (SAML) standard defines an XML-based framework for describing and exchanging security information between on-line business partners.”

While this description makes sense to those already familiar with SAML, it may be incomprehensible to everyone else. To help everyone else, I’m going to provide a simplified, high-level overview. Then, once some of the basics have been established, I will provide a resource from the OASIS site that describes the technical details of the SAML standard.

High-level Overview

The SAML standard can be broken down into several components, some of which are listed below.
  • SAML Assertions
  • SAML Protocols
  • SAML Bindings
  • SAML Profiles
SAML Profiles or Use Cases

SAML Profiles are a collection of SAML components organized into use cases suited to solve a business problem or need. Examples of major profiles or use cases defined within the SAML Standard are listed below.
  • Web Browser Single Sign-On Profile (Web Browser SSO)
  • Single Logout Profile
  • Web Services Security (WS-Security) and SAML
The goal of the Web Browser SSO profile is to provide a single sign-on experience for users to move seamlessly between web applications of disparate organizations or companies. For example, if three distinct companies providing complimentary services (such as a hotel booking, flight booking, and car rental service) wish to form a partnership, they can create a single sign-on experience for their users (and share information) without the consolidation of servers or data.

The Single Logout Profile provides a mechanism to simultaneously log a user out of all sites participating in a particular single sign-on experience.

The combination of WS-Security and SAML is actually an extension of SAML and not directly defined as a profile. However, this use case is a valuable way to use SAML as a security token for authentication and authorization of a principle interacting with a system through SOAP web services.

SAML Assertions

SAML Assertions consist of XML data that contains authentication, authorization, or additional attributes about a principal (a user, application, or other subject wishing to access a resource). SAML assertions are often provided by an identity provider or authentication service to a service provider. The service provider can understand the Assertions and trusts the identity provider due to agreements made between the organizations that own or operate the services.

An example assertion is shown below. Discussion of the structure of a SAML Assertion will be addressed by a resource provided later in this article.


SAML Protocols

SAML Protocols define mechanisms for communicating SAML Assertions between identity providers, principals, and service providers. The standard provides a detailed set of request and response strategies to suit a variety of business and technical requirements.

SAML 2.0 includes the following protocols:
  • Assertion Query and Request Protocol
  • Authentication Request Protocol
  • Artifact Resolution Protocol
  • Name Identifier Management Protocol
  • Single Logout Protocol
  • Name Identifier Mapping Protocol
An example request and response is shown below. Discussion of the SAML Protocol sequences and the structure of the request and response below will be addressed by a resource provided later in this article.

SAML Protocol Authentication Request:


SAML Protocol Authentication Response:


SAML Bindings

SAML Bindings determine how SAML messages are encapsulated within other protocols such as HTTP or SOAP. SAML 2.0 describes the following bindings:
  • SAML SOAP Binding
  • Reverse SOAP (PAOS) Binding
  • HTTP Redirect (GET) Binding
  • HTTP POST Binding
  • HTTP Artifact Binding
  • SAML URI Binding

Next Step

Now that a basic understanding of SAML has been established, I suggest reading the Security Assertion Markup Language (SAML) V2.0 Technical Overview. This document is written by OASIS and summarizes the SAML standard in a way that is easy to understand.

What About Security?

There are many security considerations that must be analyzed before the implementation of a product leveraging SAML takes place. Often authentication or authorization information is allowed to pass through untrusted users or may be intercepted by attackers. The Security and Privacy Considerations for the OASIS
Security Assertion Markup Language (SAML) V2.0 document provides a detailed discussion of these issues and appropriate mitigation techniques.

If I was asked to summarize the mitigation strategies described in this document, I would provide the following recommendations:
  • Use TLS/SSL 3.0 with strong ciphers and verifiable certificates (usually for just the server, but sometimes needed for the client as well).
  • If the application must ensure data integrity remains intact, use XML Signature to ensure it is not manipulated while in transit.
  • If confidential, sensitive, or private data passes through the client use XML Encryption to ensure it is not disclosed to unauthorized parties.

Wednesday, August 6, 2008

Threat Modeling as the Only Secure Development Activity

Purpose

This article discusses why it is important for threat modeling to be supported by a full secure development process within an organization. If threat modeling is the only secure development activity performed, it will be difficult to identify threats, mitigate risks, and leverage knowledge gained during threat modeling efforts in future projects.

This article does NOT describe how to perform threat modeling, however it does provide a brief introduction to ensure it is clear what the author means by the term "threat modeling."

Introduction to Threat Modeling

At its core, threat modeling is a secure development activity in which developers, architects, designers, security personnel, and sometimes managers consider possible attack scenarios or threats against an application. This process typically occurs during a planning or design phase of development before any code is written.

One threat modeling strategy may include the following steps:

1. Resource <- 2. Capability <- 3. Use Case <- User
1. Resource <- 2. Capability <- 4. Threats <- Attacker

  1. Identify resources within the application, such as database tables, file systems, and application servers.
  2. Determine the capabilities or actions that can be performed on each item. One example for a database table may be to read checking account transaction data.
  3. Consider the proper way in which a valid user may invoke a capability. Following with the previous example, a customer may login to Online Banking and access their checking account details.
  4. Consider the threats to a particular resource based on the associated capabilities. Threat modeling participants can base threats on defined use cases or by brainstorming in a free form manner. Example: An attacker may wish to access another user's checking account data.
  5. Assign a risk level to each threat, such as high, medium, and low.
  6. Define countermeasures based on the analysis of the risk level vs. the cost of implementing the solution
There are many ways threat modeling can be performed. For more information, please visit the OWASP Threat Modeling page.


Threat Modeling as the Only Secure Development Activity

Threat modeling is a necessary component within a secure development process. However, if threat modeling is the only security activity your organization has implemented, you may not be realizing its full value or potential.

During the threat modeling process, threats and countermeasures must be defined. Typically, it is difficult for threat modeling participants to think from an attacker's perspective without basic application security awareness training. Often, the end result will be an incomplete threat model that does not include enough of the relevant application attack scenarios or threats.

Once threats have been enumerated, participants must identify viable and effective countermeasures. The most effective countermeasures are those based on application security best practices. Often, developers are not familiar with these best practices leading to the creation of countermeasures that only partial protect resources. Security training is necessary to provide application security knowledge and these essential best practices.

Once appropriate countermeasures have been designed, implemented, and tested to ensure they are complete and effective solutions for eliminating risks, this knowledge should be captured to be reused in future projects. If this knowledge is not captured, the organization will be forced to start from scratch each and every time threat modeling is performed. This can be an unnecessary allocation of time or money.

To effectively capture and reuse this knowledge, an organization should wrap security best practices and solutions into the organization's security policies and secure coding standards. In future projects, the designer or requirements specifier can create security requirements based on this documentation. During the threat modeling process, threats can be matched up with defined security requirements allowing participants to focus on threats that have not been mitigated in past efforts.

Conclusion

Threat modeling should not be the only secure development activity used within an organization. It must be supported by a full process including security training, security policies, secure coding standards, and many more activities. The OWASP Comprehensive, Lightweight Application Security Process is one fully featured secure development process that should be considered.

OWASP CLASP Overview Presentation

The OWASP Comprehensive, Lightweight Application Security Process (CLASP) is an "Activity driven, role-based set of process components whose core contains formalized best practices for building security into your existing or new-start software development life cycles in a structured, repeatable, and measurable way"

In other words, it is one method of many (others examples are Microsoft SDL and Software Security Touchpoints) for implementing a secure development process.

A couple months ago, I created a presentation that gave a high-level overview of CLASP. I wanted to make this presentation available to the community as well as gather input from industry practitioners regarding how feasible this model is within their environment. I encourage anyone who is interested to join the OWASP CLASP mailing list or comment directly.

The presentation can be found here: OWASP CLASP Overview