Threat Modeling Group - Mission

[John Steven]

All,

We discussed a variety of scope-related topics on our first call and
Anurag agreed to produce call notes. While he's crafting those, I
thought I'd take a whack at characterizing what we discussed confined
to a "mission". I've chosen email b/c I reckon this will be a
discussion thread rather than a single draft/revision cycle:

[Mission]

Establish a single and inclusive, software-centric OWASP Threat
Enumeration Methodology, focusing first on interaction between client
browsers and the application-level services over the Internet.

[Motivation]

Disparity exists in practitioner methods and published material and
this OWASP project seeks to unify methodology simplifying adoption by
new practitioners and adopting organizations, while being open and
inclusive enough that individuals and organizations can innovate and
extend what we define.

[Scope]

The methodology will be software-centric, rather than asset- or
risk-centric in nature. The methodology will, in the foreseeable-term,
focus on threat and attack enumeration, rather than impact analysis
and risk management, as the latter two concepts tend to be
organization-/philosophy-specific. We do, however, recognize that
without risk management, threat enumeration has little value. We will,
as such, make efforts to establish methodology-neutral risk management
tie-in through factors (like threat skill and capabilities) as well as
through vulnerability factors (such as susceptibility or
accessibility).

Thoughts?

--
-jOHN

[Nam Nguyen]

This is right on. We care about threats, and threat factors more than
their impact or risk. And that's the way it should be, too. Risk is,
afterall, a subjective measure. Different people have different gauge
meters. People do, however, agree on possible threats.

I couldn't attend the call (it's 03:00 AM my timezone). Would you care
to elaborate on software/asset/risk-centric? What do these terms mean?

Thanks
Nam

[Tony UV]

All,

Good call last Friday. Will be interesting if we can preserve form to the
objectives outlined by a small minority who were able to take part. In lieu
of re-hashing thoughts related to what took place, will build off of the
content below (with my name in brackets)

Tony UcedaVelez, CISM, CISA, GSEC
Atlanta Chapter President
Membership Committee Global Board Member
OWASP Atlanta
http://www.owasp.org/index.php/Atlanta_Georgia
Twitter: @versprite

-----Original Message-----
From: owasp-thre...@googlegroups.com
[mailto:owasp-thre...@googlegroups.com] On Behalf Of John Steven
Sent: Monday, April 25, 2011 6:31 PM
To: owasp-thre...@googlegroups.com
Subject: Threat Modeling Group - Mission

All,

We discussed a variety of scope-related topics on our first call and
Anurag agreed to produce call notes. While he's crafting those, I
thought I'd take a whack at characterizing what we discussed confined
to a "mission". I've chosen email b/c I reckon this will be a
discussion thread rather than a single draft/revision cycle:

[Tony UcedaVelez] I slightly disagree here. A mission (as intimidating as
it is to admit that one was made for fear of error or weaknesses in said
mission) was somewhat defined, albeit with a loose form, which is why we
need everyone's input to the initial mission statement below.

[Mission]

Establish a single and inclusive, software-centric OWASP Threat
Enumeration Methodology, focusing first on interaction between client
browsers and the application-level services over the Internet.

[Tony UcedaVelez] Establish a single and inclusive, software-centric OWASP
Threat
[Mission 0.2]
Methodology that addresses coding/ design flaws amongst client
browsers and web application-level services over the Internet. (excluded
'Enumeration' b/c the exercise of enumerating anything in its literal sense
does not require a methodology. Added 'design' and 'coding' and terms to
stay true and topical to a software centric approach to threat modeling.

[Motivation]

Disparity exists in practitioner methods and published material and
this OWASP project seeks to unify methodology simplifying adoption by
new practitioners and adopting organizations, while being open and
inclusive enough that individuals and organizations can innovate and
extend what we define.

[Tony UcedaVelez]
[Motivation v0.2]
Provide a repeatable and extensible methodology for which web technologies
can be analyzed for improved code quality, security, and design.

[Scope]

The methodology will be software-centric, rather than asset- or
risk-centric in nature. The methodology will, in the foreseeable-term,
focus on threat and attack enumeration, rather than impact analysis
and risk management, as the latter two concepts tend to be
organization-/philosophy-specific. We do, however, recognize that
without risk management, threat enumeration has little value. We will,
as such, make efforts to establish methodology-neutral risk management
tie-in through factors (like threat skill and capabilities) as well as
through vulnerability factors (such as susceptibility or
accessibility).

[Tony UcedaVelez]
The scope depicted here is more along the lines of an extended mission
rather than a technical scope for which we need to define proper boundaries
to the OWASP based threat modeling methodology. We need to first
differentiate scope as it relates to the object of the methodology AND scope
as it relates to our efforts as a group (i.e. - intended deliverables for
which we will mass produce for OWASP disciples worldwide. In regards to the
former, I recommend that we define the scope of our efforts to be INITIALLY
confound to the browser and the server environment that encompasses web
applications and services, potentially later including an application layer
tier and deliberating excluding the data tiers. I said INITIALLY in order
that we can create a strong foundation for methodology and not one that
tries to eat an elephant during one sitting. We need to have digestible
morsels of efforts that we can consume and produce in a much more colorful
metaphor than what I just depicted unintentionally.
In terms of scope of work effort, we need to define a list of deliverables,
of which I think the following makes sense:

- Taxonomy of terms
- OWASP (Software Centric) Threat Modeling Methodology (actionable steps to
perform, with examples and underlying components for each step)
- Threat Enumeration Library (may later beget Attack Library which may stem
from research sources from MITRE, etc.

Thoughts?

--
-jOHN

[Tony UV]

Software centric focuses on improved code/ design for the gains of greater efficiency compounded by security benefits. Network related considerations for example are less involved in this approach as countermeasures.

Asset centric (A.K.A risk centric) focuses on the preservation and impact of the asset of a given application environment. Threat modeling's key purpose in this approach is for mitigating assets that are able to introduce a greater level of impact if adversely affected.

Security centric is focused essentially on defense and stifling attacks across multiple layers of the security onion. It does not consider benefits of improved code handling but rather implementing countermeasures that reduces the attack surface or its effectiveness for channeling successful exploits.

There are benefits and flaws in each, but the reason we chose SW centric was in order to not enter into the hot debate of risk religions, which have their own place, but we need something that can be implemented for mass consumption that is more geared towards the perceived demographic of our audience and doesn’t incite unending debates on risk related principles, but instead improved SW design.

Tony UcedaVelez, CISM, CISA, GSEC
Atlanta Chapter President
Membership Committee Global Board Member
OWASP Atlanta
http://www.owasp.org/index.php/Atlanta_Georgia
Twitter: @versprite

[Venkatesh Jagannathan]

My Comments between <Venki>...</Venki> tags.

<Venki>

    When doing a threat assessment, we will not be looking directly at coding or the style of writing code. Its only on the design that we need to do the threat assessment as such. Hence, I feel adding "coding" to the mission statement when dioing threat modeling is not in the right spirit.

 

We need to come out of the mind set that threats are "code-centric", when actually trhey are design-centric. When describing your design, we must provide the correct approach to solve the problem as such as that makes the design more complete. The design must directly translate into a proper adaptation of the code as such.

 

Annother point to note: We need not ncessarily stick to applicaitons accessed through browsers. it may also be accessed through web services. Hence, let us not stic to "web-bvrowser" mode of looking at a design, whereas as let us look at it from a point of view of accessing the applicatiobn by any proper channel.

</Venki>

 

[Motivation]

Disparity exists in practitioner methods and published material and
this OWASP project seeks to unify methodology simplifying adoption by
new practitioners and adopting organizations, while being open and
inclusive enough that individuals and organizations can innovate and
extend what we define.

[Tony UcedaVelez]
[Motivation v0.2]
Provide a repeatable and extensible methodology for which web technologies
can be analyzed for improved code quality, security, and design.

 

<Venki>

I agree to Tony's point here. Once this becomes repeatable, we will be able to assure everyone that the process is straightforward and there is no "suibjective" opinion here. That is what would make it critical. The next step to that would be to create a web application that can capture all these inputs and create a threat modle by itself after doing proper abnalysis of the inputs.

</Venki>

<Venki>

Without a tangilbe risk value, the threat posted will not be measurable and it will be difficult to convince the management on the possible outcome of a poor design. hence, I feel that we SHOULD have a kind of rating/value to the risk at least at a very high level. And the rating should describe the risk in the business terms to enable the m,anagement to understand what they will tend to loose if this is allowed to be ignored.

</Venki>

Thoughts?

--
-jOHN

[Tony UV]

Venki,

 

Overall, I think there is some misunderstood takes from my comments. My attempts for clarity are inline below.

 

Tony UcedaVelez, CISM, CISA, GSEC

Atlanta Chapter President

Membership Committee Global Board Member

OWASP Atlanta

http://www.owasp.org/index.php/Atlanta_Georgia

Twitter: @versprite

 

 [Tony UcedaVelez]  Here we see our first morphing of words as the word ‘assessment’ is introduced.  The wrapper here is a threat model.  We’re not assessing threats as the objective, we are modeling them and if by chance we assess them in the pure sense of the English word w/o porting over any nuances to risk, issues tables, remediation terminology, the better.  In relation to ‘coding’, the software centric approach embellishes aspects of writing improved code as one of many types of countermeasures.  It’s not strictly coding – its coding and design (and beyond, but more on that later). If you think that designing countermeasures to application attacks can be accomplished with no referenced to improved secure coding techniques, I’m definitely all ears.  By design, if you we want to cheat and reference ‘fictitious, pre-existing APIs’ that will handle parameterization, input validation, proper output encoding, etc….then there is a lot assumed in that application design that such APIs exist or don’t need to be originated – via coding ironically.  There is a misunderstanding here that I’m implying that mitigation will be all code centric when in fact it will not.  Some code, some design, and some configuration. No network.  Hence the software centric approach.

We need to come out of the mind set that threats are "code-centric", when actually trhey are design-centric. When describing your design, we must provide the correct approach to solve the problem as such as that makes the design more complete. The design must directly translate into a proper adaptation of the code as such.[Tony UcedaVelez]  How does design properly adapt to security related information that is stored in hidden fields or hard coded in source?  Even if by design, we were to mitigate those weaknesses in application development, how does that affect the performance of the application?  A SW centric approach extends beyond a security centric approach b/c it demands for how does the application behave with the inclusion of new design implementations. No one said that threats are code-centric. Again, there are three widely regarded approaches to threat modeling.  The software centric approach is one geared with educating groups within a given SDLC process (i.e. – developers, application architects, QA testers, etc) on a threat model against a given application environment.  The SW centric approach seeks to create a balance in both the efficiency of the application and security, as compared to security centric where it’s more of a one sided regard.    

 

Annother point to note: We need not ncessarily stick to applicaitons accessed through browsers. it may also be accessed through web services. Hence, let us not stic to "web-bvrowser" mode of looking at a design, whereas as let us look at it from a point of view of accessing the applicatiobn by any proper channel.[Tony UcedaVelez]  I do think that we need to reword the mission b/c this was implied, although not very explicitly. The ‘application level services over the internet’ would be the non-defined blob that I presume John and I intended to encompass web services (at least from my part that was the case)

</Venki>

[Tony UcedaVelez] I think the approach via a software centric threat model is aimed at a technology focused audience versus risk professionals, so if we retain this course, we can remain pure to the cause of the intended mission (once we decide on one). Ultimately, risk professionals can use the byproducts of this type of threat model in order to substantiate their subjective qualitative analysis or go beyond their means of taking technical risk ratings from product to a higher form of relevant business risk.  The threat model to be produced will help them to see logistically how their application is defeated and then they can be in charge of developing a risk rating based upon another, more valuable input to their risk assessment and analysis. If we’re still on the fence, we could ultimately have our own SW centric rating scale that maps to everything on the planet including CoBIT, ValIT, ITAF, ISO 27001, JSOX, Billboard Top 40, and beyond.  J

Thoughts?

--
-jOHN

 

[Anurag Agarwal]

Hi Guys – Apologies for not sending the notes out yet. I have not been keeping well for past few days and haven’t got a chance to work on those yet. I will try to send them out this week.

 

Thanks John for not waiting on me and get the ball rolling.

 

Anurag

[Anurag Agarwal]

To address the risk component, I dont want to come up with our own risk methodology. However, we can use any established risk methodology from the industry and tie into our threat modeling methodology as an example (maybe create a template). Purely an academic exercise to show others how to apply any risk methodology to the output of our project.

-Anurag

[John Steven]

All, Updated version... based on the thread (original quoted for the
purpose of comparison):

[Mission]
Establish a single and inclusive software-centric OWASP Threat modeling
Methodology, addressing vulnerability in client and web

application-level services over the Internet.

[Motivation]
Provide a repeatable and extensible threat modeling methodology for which
applications or the web technologies on which they're built can be
analyzed in order
to drive activities within a secure development cycle.

[Scope]
The scope of this project, in terms of approach, will be
"software-centric", rather
than asset- or risk-centric. We do, however, recognize that without
risk management,
threat modeling provides little value. We will make efforts to
establish methodology-

neutral risk management tie-in through factors (like threat skill and
capabilities) as
well as through vulnerability factors (such as susceptibility or
accessibility).

From a technical perspective, this group's efforts will be confined to
the application
layer of the OSI stack, focusing first on interaction between a
browser-based client
and the server-side web technologies that service it. The group will
not confine itself
based on languages, platforms, or tool kits at this time.
Architecturally, this group will
consider classic n-tier applications, federated applications, RESTful
services, and
simple client-server interaction.

[Deliverables]
Pursuant to its mission, this group will deliver:
* A glossary of threat modeling terms
* An OWASP Threat Modeling methodology document
* Step-wise activities to be performed
* Examples of each step's result
* Threat Library (which may beget an Attack library)

[Explanation]

* General - 1) I really enjoyed the discussion this generated.
Particular thanks to Nam, Tony, Venki, and Anurag for their comments.
I tried to include everyone's input calling out conflict below where
it remains. 2) Note that the above fits on one page even with
aggressive word-wrapping. I think it's important that we be able to
confine talking about what we're going to do to a "one pager"
otherwise all may already be lost ;-) 3) If there's sufficient
agreement on this, I'll place it in a Google Doc and foist it up in
the sharing area.

* Mission - I took Tony's re-write of enumeration, and tweaked the
wording around focus, resulting in 'vulnerability'. I did pull back
off the suggested "coding/design flaws" language because I felt it was
overly specific and thus restrictive. The words coding and design
flaw themselves suffer from ambiguity that I feel could be
distracting. From the glossary, however, I think we could all agree
that regardless of whether it's 1) failure in a business objective,
violation of a policy, or an intermediate attack objective, that from
a software-centric perspective _something_ has to be 'vulnerable' in
order for an attack to succeed. This, of course, includes very
intentional functionality at times.

Though I personally like using the term "Threat Enumeration" to
differentiate the aspects of threat modeling that aren't risk
management, I realize this is my own convention. So, I replaced the
word "enumeration" with "modeling" hoping this would fully sate Tony
and Venki's comments on the matter.

At Venki's request, I removed the word "browser", which tony has
explicitly suggested on the phone call. At the time I had agreed that
the word "browser" was a good way to confine scope but think that
Venki raises a good point: RESTful endpoints and other browser
alternatives fit just as well when we include web-services on the
other side of the river. I think we just need to watch, explicitly,
for scope creep around the edges where people are using web services
in decidedly thick client scenarios that don't conform to our initial
focus (such as when people interact with web pages from ObjectiveC on
IOS to create their first-pass phone app). And, I believe (without
talking out of both sides of my mouth) we can leave the mission stated
W/OUT the browser but agree that our first forays into methodology and
example will be CONFINED to it (as Tony suggests).

I think that at least a few of us are vehement that we need to leave
the philosophies and mechanics of risk management on the side lines
for the foreseeable future. Tony, IMO, hits hits this nail on the head
with his discussion of "threat modeling" as a technique that fits
within a broader "assessment" service or practice. As I say in every
threat modeling talk I give (and Tony places in bold italic at his
last post's end) I strongly suggest that OWASPers focus on the
technical software design aspects and we agree that any threat modeler
will--in practice--need to establish the appropriate stakeholder
relationships in order to rate risk and respond accordingly. It is
for this reason I've made a nod to risk management in the discussion
of scope.

* Motivation - I started with Tony's near-complete re-write of the
motivation, because bluntly I liked it so much better than what I
produced. I (again) removed what I believed was overly-specific SDL
activity call out because I believe that threat modeling is a moniker
for a raft of activities that both stand alone and augment existing
activities commonly undertaken by development teams. In other words, I
don't believe it's something you "stop and do" so much as something
you do "as you go", continuing to iteratively improve both depth and
resolution... ...as well as increase fidelity to the business'
understanding of risk.

I took a chance in teasing apart the notion of an application (which I
always dither on: does this implicitly include "Services" and
"Systems" or do those things need called out separately?) and the
web-technologies that Tony mentioned in his motivation. Yes, you can
threat model a channel, dependency, a framework or toolkit you're
thinking of supporting, or the application wholesale. I thought this
was an important distinction to call out.

* Scope - I took a few chances on the scope section, explicitly
calling out aspects of perspective, process, and technology. We'll see
where it lands with the group.

* Deliverables - I took Tony's suggestions regarding scope and made a
"Deliverables" section.

-jOHN

[Anurag Agarwal]

John - Thanks for helping me out with this.

Group - If you have any additional comments, please raise them now. If
nobody has anything to add by Friday, I will update the project wiki with
it. I plan to start working on individual line items from Monday onwards.

Thanks,

Anurag Agarwal
MyAppSecurity Inc
Cell - 919-244-0803
Email - anu...@myappsecurity.com
Website - http://www.myappsecurity.com
Blog - http://myappsecurity.blogspot.com
LinkedIn - http://www.linkedin.com/in/myappsecurity

-----Original Message-----
From: owasp-thre...@googlegroups.com
[mailto:owasp-thre...@googlegroups.com] On Behalf Of John Steven
Sent: Wednesday, April 27, 2011 9:25 PM
To: owasp-thre...@googlegroups.com
Subject: Re: Threat Modeling Group - Mission

[Antonio Fontes]

On Apr 28, 3:10 pm, "Anurag Agarwal" <anurag.agar...@yahoo.com> wrote:
> John - Thanks for helping me out with this.
>
> Group - If you have any additional comments, please raise them now. If
> nobody has anything to add by Friday, I will update the project wiki with
> it. I plan to start working on individual line items from Monday onwards.
>
> Thanks,
>
> Anurag Agarwal
> MyAppSecurity Inc
> Cell - 919-244-0803
> Email - anu...@myappsecurity.com
> Website -http://www.myappsecurity.com
> Blog -http://myappsecurity.blogspot.com
> LinkedIn -http://www.linkedin.com/in/myappsecurity

Guys,

I read the entire thread, it's great work that you did there!

Mission -> ok!
Motivation -> ok!
Scope -> not ok (see below)
Deliverables -> ok!

The one thing that I disagree with is the following sequence, in the
scope, saying "focusing first on interaction between a browser-based
client".

Does this statement exclude web applications/services specifically
designed to service mobile applications or web applications that, due
to a lack of usable APIs, get used as web services thanks to
aggressive wrapping? If this is not the case, I would find it clever
to not use the "browser" word and use a concept that encompasses any
form of web application client. The change proposition would be: "From

a technical perspective, this group's efforts will be confined to the
application layer of the OSI stack, focusing first on interaction

between a client and the server-side web technologies that service
it."

(As a non-English native, I understand there is a chance that I am not
treating the "browser" word as it should be. If the word semantically
encompasses all sorts of web application clients, then you can just
ignore my proposition)

your thoughts?

Antonio

[Tony UV]

On the point related to technical scope, I think we agreed in an earlier
thread that anything client-server/service or service-service will be
covered by our project. So if you have two web services that communicate
with one another as an application vignette that we could address, we shall
do so. We're in agreement there I believe.

Tony UcedaVelez, CISM, CISA, GSEC
Atlanta Chapter President
Membership Committee Global Board Member
OWASP Atlanta
http://www.owasp.org/index.php/Atlanta_Georgia
Twitter: @versprite

-----Original Message-----
From: owasp-thre...@googlegroups.com
[mailto:owasp-thre...@googlegroups.com] On Behalf Of Antonio Fontes
Sent: Thursday, April 28, 2011 9:45 AM
To: OWASP Threat Modeling
Subject: Re: Threat Modeling Group - Mission