[SC-L] Microsoft SDL report card

[Gary McGraw]

hi sc-l,

Yesterday, Microsoft released an SDL report card of sorts called "The SDL 
Progress Report."  It covers the history of the SDL from 2004-2010.  You should 
read it.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=918179a7-61c9-487a-a2e2-8da73fb9eade

For some reason the tech press is mostly discussing DEP and ASLR adoption 
(covered on pages 18 and 19).  Though I guess that is the "news" hook the PR 
flacks are hyping, I think there are many other parts of the report that have 
plenty to teach about how a software security initiative evolves.  (WRT the two 
anti-exploit tactics, see an article I co-authored with Ivan Arce from Core 
Assume Nothing: Is Microsoft Forgetting a Crucial Security 
Lesson? (April 30, 
2010).)

Microsoft has made huge strides since the days of CodeRed, NIMDA and Slammer.  
The best part of what they're doing is being very open about the progress they 
are making and the approach that seems to be working for them.  I, for one, 
would love to see other reports like this issued by software vendors.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[security curmudgeon]

: 
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=918179a7-61c9-487a-a2e2-8da73fb9eade

: Microsoft has made huge strides since the days of CodeRed, NIMDA and 
: Slammer.  The best part of what they're doing is being very open about 
: the progress they are making and the approach that seems to be working 
: for them.  I, for one, would love to see other reports like this issued 
: by software vendors.

Is "no CodeRed/NIMDA/Slammer worms lately" really the bar we're using for 
judging success?

Circumstancial evidence suggests Microsoft's SDLC isn't making much 
progress (e.g., 2011-02-08, 2010-12-14):

http://osvdb.org/search?search[vuln_title]=microsoft&search[text_type]=titles

Specifically, not just the amount of vulnerabilities but the types. Things 
don't appear to have changed much over the years.
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Steven M. Christey]

On Thu, 31 Mar 2011, security curmudgeon wrote:


Circumstancial evidence suggests Microsoft's SDLC isn't making much
progress (e.g., 2011-02-08, 2010-12-14):

http://osvdb.org/search?search[vuln_title]=microsoft&search[text_type]=titles

Specifically, not just the amount of vulnerabilities but the types. Things
don't appear to have changed much over the years.


Microsoft is a victim of its own vague advisories by using generic terms 
like "memory corruption" that make people assume it's always the same old 
problem.  But in general, the types of vulnerabilities that they're 
getting hit with are related to access of uninitialized data, 
use-after-frees/use-after-deletes, array index errors, pointer calculation 
errors, etc. - all issues for which detection and reliable exploitation 
are still fairly rare.  (Other vendors/products are getting hit with 
these, too.)


When software is getting flagged with more obscure issues, instead of the 
same old classic overflows and format strings (SCADA anyone?), that 
suggests a noticeable improvement in the SDLC.


You know better than most about the dangers of relying too much on 
information about published vulnerabilities ;-)  For example, Microsoft 
products are probably aggressively targeted by more attackers / 
researchers than most other products ever will be, thanks in large part to 
market share.  So the raw numbers of reported issues aren't surprising.


But I believe that qualitative indicators (such as "novel" vuln types) can 
be informative, unless/until our software security practice develops 
repeatable, consistent metrics (which also assumes accuracy improvements 
in automated code scanning and consistent threat/architecture/design 
analysis).


Interested parties can see my 2007 "Unforgivable Vulnerabilities" paper, 
which describes different phases of software maturity in terms of the 
kinds of vulnerabilities being discovered in the product.


If anything, Microsoft's continued troubles are an indicator of how far 
the whole software industry needs to go.


- Steve
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Gary McGraw]

In my opinion, the most interesting thing about stuxnet was the payload.
See:
How to p0wn a Control System with Stuxnet
 (September 23,
2010)

You might also listen to Langner on Silver Bullet (the longest episode
ever, but a good one):
http://www.cigital.com/silverbullet/show-059/

gem


On 4/1/11 9:16 AM, "Ben Laurie"  wrote:

>On 31 March 2011 13:03, Gary McGraw  wrote:
>> hi sc-l,
>>
>> Yesterday, Microsoft released an SDL report card of sorts called "The
>>SDL Progress Report."  It covers the history of the SDL from 2004-2010.
>>You should read it.
>>
>> 
>>http://www.microsoft.com/downloads/en/details.aspx?FamilyID=918179a7-61c9
>>-487a-a2e2-8da73fb9eade
>>
>> For some reason the tech press is mostly discussing DEP and ASLR
>>adoption (covered on pages 18 and 19).  Though I guess that is the
>>"news" hook the PR flacks are hyping, I think there are many other parts
>>of the report that have plenty to teach about how a software security
>>initiative evolves.  (WRT the two anti-exploit tactics, see an article I
>>co-authored with Ivan Arce from Core Assume Nothing: Is Microsoft
>>Forgetting a Crucial Security
>>Lesson? (April
>>30, 2010).)
>>
>> Microsoft has made huge strides since the days of CodeRed, NIMDA and
>>Slammer.
>
>Stuxnet?
>
>>  The best part of what they're doing is being very open about the
>>progress they are making and the approach that seems to be working for
>>them.  I, for one, would love to see other reports like this issued by
>>software vendors.
>>
>> gem
>>
>> company www.cigital.com
>> podcast www.cigital.com/silverbullet
>> blog www.cigital.com/justiceleague
>> book www.swsec.com
>>
>> ___
>> Secure Coding mailing list (SC-L) SC-L@securecoding.org
>> List information, subscriptions, etc -
>>http://krvw.com/mailman/listinfo/sc-l
>> List charter available at - http://www.securecoding.org/list/charter.php
>> SC-L is hosted and moderated by KRvW Associates, LLC
>>(http://www.KRvW.com)
>> as a free, non-commercial service to the software security community.
>> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
>> ___
>>


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Ben Laurie]

On 4 April 2011 16:45, Gary McGraw  wrote:
> In my opinion, the most interesting thing about stuxnet was the payload.

So what was the huge stride made since Code Red wrt Stuxnet?

> See:
> How to p0wn a Control System with Stuxnet
>  (September 23,
> 2010)
>
> You might also listen to Langner on Silver Bullet (the longest episode
> ever, but a good one):
> http://www.cigital.com/silverbullet/show-059/
>
> gem
>
>
> On 4/1/11 9:16 AM, "Ben Laurie"  wrote:
>
>>On 31 March 2011 13:03, Gary McGraw  wrote:
>>> hi sc-l,
>>>
>>> Yesterday, Microsoft released an SDL report card of sorts called "The
>>>SDL Progress Report."  It covers the history of the SDL from 2004-2010.
>>>You should read it.
>>>
>>>
>>>http://www.microsoft.com/downloads/en/details.aspx?FamilyID=918179a7-61c9
>>>-487a-a2e2-8da73fb9eade
>>>
>>> For some reason the tech press is mostly discussing DEP and ASLR
>>>adoption (covered on pages 18 and 19).  Though I guess that is the
>>>"news" hook the PR flacks are hyping, I think there are many other parts
>>>of the report that have plenty to teach about how a software security
>>>initiative evolves.  (WRT the two anti-exploit tactics, see an article I
>>>co-authored with Ivan Arce from Core Assume Nothing: Is Microsoft
>>>Forgetting a Crucial Security
>>>Lesson? (April
>>>30, 2010).)
>>>
>>> Microsoft has made huge strides since the days of CodeRed, NIMDA and
>>>Slammer.
>>
>>Stuxnet?
>>
>>>  The best part of what they're doing is being very open about the
>>>progress they are making and the approach that seems to be working for
>>>them.  I, for one, would love to see other reports like this issued by
>>>software vendors.
>>>
>>> gem
>>>
>>> company www.cigital.com
>>> podcast www.cigital.com/silverbullet
>>> blog www.cigital.com/justiceleague
>>> book www.swsec.com
>>>
>>> ___
>>> Secure Coding mailing list (SC-L) SC-L@securecoding.org
>>> List information, subscriptions, etc -
>>>http://krvw.com/mailman/listinfo/sc-l
>>> List charter available at - http://www.securecoding.org/list/charter.php
>>> SC-L is hosted and moderated by KRvW Associates, LLC
>>>(http://www.KRvW.com)
>>> as a free, non-commercial service to the software security community.
>>> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
>>> ___
>>>
>
>

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Gary McGraw]

hi ben,

Strides (with an s).  Take a quick look at the Microsoft report card at
the beginning of this thread
.  Then see if that sparks more specific questions.

Does Microsoft make bug/flaw free software?  No.  Is the software they are
producing today far superior to the kernel-less bug ridden disaster of the
mid-90s?  Yes.

FWIW, Google is also working diligently on software security but is taking
a different tack (with more focus on unit testing and much less on static
analysis, for example).  Google seems to have been blindsided by sticking
their software out in attackerland (on desktops or running phones) after
relying on their "slit" interface for so many years.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com




On 4/5/11 7:32 AM, "Ben Laurie"  wrote:

>On 4 April 2011 16:45, Gary McGraw  wrote:
>> In my opinion, the most interesting thing about stuxnet was the payload.
>
>So what was the huge stride made since Code Red wrt Stuxnet?
>
>> See:
>> How to p0wn a Control System with Stuxnet
>>  (September 23,
>> 2010)
>>
>> You might also listen to Langner on Silver Bullet (the longest episode
>> ever, but a good one):
>> http://www.cigital.com/silverbullet/show-059/
>>
>> gem
>>
>>
>> On 4/1/11 9:16 AM, "Ben Laurie"  wrote:
>>
>>>On 31 March 2011 13:03, Gary McGraw  wrote:
 hi sc-l,

 Yesterday, Microsoft released an SDL report card of sorts called "The
SDL Progress Report."  It covers the history of the SDL from 2004-2010.
You should read it.


http://www.microsoft.com/downloads/en/details.aspx?FamilyID=918179a7-61
c9
-487a-a2e2-8da73fb9eade

 For some reason the tech press is mostly discussing DEP and ASLR
adoption (covered on pages 18 and 19).  Though I guess that is the
"news" hook the PR flacks are hyping, I think there are many other
parts
of the report that have plenty to teach about how a software security
initiative evolves.  (WRT the two anti-exploit tactics, see an article
I
co-authored with Ivan Arce from Core Assume Nothing: Is Microsoft
Forgetting a Crucial Security
Lesson? (April
30, 2010).)

 Microsoft has made huge strides since the days of CodeRed, NIMDA and
Slammer.
>>>
>>>Stuxnet?
>>>
  The best part of what they're doing is being very open about the
progress they are making and the approach that seems to be working for
them.  I, for one, would love to see other reports like this issued by
software vendors.

 gem

 company www.cigital.com
 podcast www.cigital.com/silverbullet
 blog www.cigital.com/justiceleague
 book www.swsec.com

 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
 List charter available at -
http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC
(http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at:
http://twitter.com/KRvW_Associates
 ___

>>
>>


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Kevin W. Wall]

On 04/05/2011 09:25 AM, Gary McGraw wrote:
> hi ben,
>
> Strides (with an s).  Take a quick look at the Microsoft report card at
> the beginning of this thread
>  487a-a2e2-8da73fb9eade>.  Then see if that sparks more specific questions.
>
> Does Microsoft make bug/flaw free software?  No.  Is the software they are
> producing today far superior to the kernel-less bug ridden disaster of the
> mid-90s?  Yes.

I agree with Gary here. Attacks have gotten much more sophisticated since
Gates' Trustworthy Computing memo was issued in Jan 2002. But I think
that Microsoft has done pretty well in dealing with the attacks like buffer
overflows and heap corruption that were so prevalent to their code in the late
90s to early 2000s. Of course, one could argue that was move because of a move
away from C++ to .NET/C# than it was because of any secure SDLC they were
pushing or that this was just the low hanging fruit. Nevertheless, they
seemed to have mostly addressed these things where other companies haven't
so they must be doing something right.

I think that what is being overlooked here though is how much worse would
things have been had Microsoft not had a such big push toward an SSDLC.

We have to acknowledge at least that Microsoft no longer seems to be
the #1 poster child for insecure software any longer. That unenviable
position would now seem to belong Adobe with Flash and Acrobat Reader.
Their two products along seem to account for more zombied PCs than
all of the Microsoft software combined.

> FWIW, Google is also working diligently on software security but is taking
> a different tack (with more focus on unit testing and much less on static
> analysis, for example).  Google seems to have been blindsided by sticking
> their software out in attackerland (on desktops or running phones) after
> relying on their "slit" interface for so many years.

Odd how you mention Google and being blindsided. I think that's going
to get a lot worse and happen soon. Shameless plug: I recently blogged
about how Google and Apple are making the same mistakes with mobile devices
that the personal computing industry made in the 80s and 90s. You can read
about it here if you are interested:




I'd be interested in this crowd's (and especially Ben's, since he's now
at Google) thoughts about it...am I just crying wolf here or do you think
this is a real problem in the making?

Regards,
-kevin
-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."-- Nathaniel Borenstein, co-creator of MIME
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Ben Laurie]

On 6 April 2011 03:20, Kevin W. Wall  wrote:
> On 04/05/2011 09:25 AM, Gary McGraw wrote:
>> hi ben,
>>
>> Strides (with an s).  Take a quick look at the Microsoft report card at
>> the beginning of this thread
>> > 487a-a2e2-8da73fb9eade>.  Then see if that sparks more specific questions.
>>
>> Does Microsoft make bug/flaw free software?  No.  Is the software they are
>> producing today far superior to the kernel-less bug ridden disaster of the
>> mid-90s?  Yes.
>
> I agree with Gary here. Attacks have gotten much more sophisticated since
> Gates' Trustworthy Computing memo was issued in Jan 2002. But I think
> that Microsoft has done pretty well in dealing with the attacks like buffer
> overflows and heap corruption that were so prevalent to their code in the late
> 90s to early 2000s. Of course, one could argue that was move because of a move
> away from C++ to .NET/C# than it was because of any secure SDLC they were
> pushing or that this was just the low hanging fruit. Nevertheless, they
> seemed to have mostly addressed these things where other companies haven't
> so they must be doing something right.
>
> I think that what is being overlooked here though is how much worse would
> things have been had Microsoft not had a such big push toward an SSDLC.
>
> We have to acknowledge at least that Microsoft no longer seems to be
> the #1 poster child for insecure software any longer. That unenviable
> position would now seem to belong Adobe with Flash and Acrobat Reader.
> Their two products along seem to account for more zombied PCs than
> all of the Microsoft software combined.
>
>> FWIW, Google is also working diligently on software security but is taking
>> a different tack (with more focus on unit testing and much less on static
>> analysis, for example).  Google seems to have been blindsided by sticking
>> their software out in attackerland (on desktops or running phones) after
>> relying on their "slit" interface for so many years.
>
> Odd how you mention Google and being blindsided. I think that's going
> to get a lot worse and happen soon. Shameless plug: I recently blogged
> about how Google and Apple are making the same mistakes with mobile devices
> that the personal computing industry made in the 80s and 90s. You can read
> about it here if you are interested:
>
>
> 
>
> I'd be interested in this crowd's (and especially Ben's, since he's now
> at Google) thoughts about it...am I just crying wolf here or do you think
> this is a real problem in the making?

Long delay, but...

I think the assumption that a phone is a single user device is largely
correct and so I can't really agree that it is a design error to
design for that.

However, I think you are completely right that tablets are not single
user machines and that treating them as such is a disaster. Indeed, my
own iPad gets rather less use than it might because I can't leave my
account logged in on it...

However, both of these pale in comparison with the elephant in the
room: namely that all our widely used OSes are designed around a
system intended to protect the machine from its users, and the users
from each other. It is no longer generally the case that machines need
protecting from their users (also known as "owners"). The primary
threat now is software the user runs (which is assumed to be trusted
in the prevailing model, how crazy is that?).

Which is why I am interested in and devoting most of my time now to
capability systems.

>
> Regards,
> -kevin
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
>

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Andy Steingruebl]

On Fri, Apr 15, 2011 at 7:33 AM, Ben Laurie  wrote:
>
> Which is why I am interested in and devoting most of my time now to
> capability systems.

Ben,

Is your work focused on the technical bits of this, or the human
interaction pieces?  Seems to me that much of the work on technical
implementations of capabilities, fine-grained permissions, MAC, etc.
have been worked out repeatedly over time and we've never come up with
very usable systems.  Or ones that stay usable over time

Try setting the permissions for an application when you install it, or
figure out whether it is asking for more permissions than it really
needs, etc?

Thoughts?

- Andy
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Ben Laurie]

On 18 April 2011 18:46, Andy Steingruebl  wrote:
> On Fri, Apr 15, 2011 at 7:33 AM, Ben Laurie  wrote:
>>
>> Which is why I am interested in and devoting most of my time now to
>> capability systems.
>
> Ben,
>
> Is your work focused on the technical bits of this, or the human
> interaction pieces?

In short: both.

>  Seems to me that much of the work on technical
> implementations of capabilities, fine-grained permissions, MAC, etc.
> have been worked out repeatedly over time and we've never come up with
> very usable systems.  Or ones that stay usable over time

I would contend that actually, we haven't really ever tested usability
because we've never really used these systems except in the lab.

One of the things I'm excited about in our recent work is that we've
started to make progress on hybrid models where capability stuff can
coexist with existing stuff. For example, Caja and FreeBSD Capsicum.

>
> Try setting the permissions for an application when you install it, or
> figure out whether it is asking for more permissions than it really
> needs, etc?

The underlying problem with these questions right now is that
permissions are expressed in terms of low-level system services (e.g.
file read/write), but actually we should be making decisions at higher
levels where the permission correspond to things the user understands
(e.g. "my account at Google" or "my Flickr photos" or "this album in
Picasa"). Capabilities seem well suited to this level of permission
management.

>
> Thoughts?
>
> - Andy
>

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[Gunnar Peterson]

> but actually we should be making decisions at higher
> levels where the permission correspond to things the user understands
> (e.g. "my account at Google" or "my Flickr photos" or "this album in
> Picasa"). 

Salesforce.com oauth client for Android is a good example of this

http://wiki.developerforce.com/index.php/Building_Android_Applications_with_the_Force.com_REST_API

Its a gap in all Mobile OS as far as I can tell, which makes it doubly nice 
that Salesforce open sourced their work

-gunnar
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Microsoft SDL report card

[iarce]

On 5/3/11 11:16 AM, Ben Laurie wrote:
> On 18 April 2011 18:46, Andy Steingruebl  wrote:

>>
>> Try setting the permissions for an application when you install it, or
>> figure out whether it is asking for more permissions than it really
>> needs, etc?
> 
> The underlying problem with these questions right now is that
> permissions are expressed in terms of low-level system services (e.g.
> file read/write), but actually we should be making decisions at higher
> levels where the permission correspond to things the user understands
> (e.g. "my account at Google" or "my Flickr photos" or "this album in
> Picasa"). Capabilities seem well suited to this level of permission
> management.
> 
>>
>> Thoughts?

Yes, read below a VERY LOOONG REPLY (you've been warned) with both a
summary and an historical account of how those thoughts were evolved.



Eduardo Arias and I wrote some of our thoughts about this topic in 2005
[See http://bit.ly/knwV81].
Our views derived from work done at Corelabs - Core's research
groups- during the late 90s and early 2000 on enterprise security
software and later on as part of the Core Force project, a free
standalone endpoint security software for Windows [See
http://force.coresecurity.com].

The main idea behind that project was to explore innovative ways (or so
we thought at the time) to address the security vs. usability dichotomy
in endpoint security software.

Here are some of our guiding principles, I think many of them might
apply to the mobile apps of today's smartphone marketplaces:

1. Effective security *requires* fine grained access control of
low-level system services enforced at the kernel layer. Anything short
of that would be easily circumvented.

2. Configuring low-level access permissions for a typical real-world
endpoint system is error-prone and plagued by usability and operational
challenges. Determining appropriate permissions for a Windows operating
system full of legacy code, deprecated, overlapping APIs and
undocumented features is already cumbersome. Doing so for an endpoint
system with tenths of installed applications that must run unaffected by
the security software yet remain hardened to resits attack is nearly
intractable.

3. To cope with the configuration challenge and usability problems that
arise from #1 and #2 multiple higher-level abstractions should be
defined and used as reusable components throughout the endpoint's
security configuration.  In our case, the top level abstraction was the
"Security Profile", a complete set of "security policies" that dictate
what the entire system or a specific application is allowed to do. The
overall security configuration of an endpoint is then composed of a
"System Profile" plus a number of "Application Profiles", one for each
application that needs to be controlled. Access control permissions
specified in these "Security Profiles" are enforced by the kernel.
In turn, a "Security Profile" is just a set of named "Security Policies"
associated to the entry point executable of the application. Security
policies can be nested thus building a hierarchy with multiple levels of
abstraction. At the lowest level a security policy is a named set of
low-level access control RWX permissions over local file, registry and
network resources.

4. Even with the use of higher level abstractions such as
"capabilities", "traits" (or "profiles" and "policies" as we called
them) an exhaustive definition of permissions for any given Windows
application isn't easy to determine -if you doubt this, try defining the
exhaustive minimal list of permissions that lets notepad.exe run
normally yet prevents overall system abuse if the process is
compromised-. Static or dynamic analysis tools that automatically
collect information about a program and generate the corresponding low
level security configuration are useful or even necessary (but not
sufficient) to deploy endpoint security software in real world
organizations with thousands of endpoints that may eventually run a
small subset of several hundred authorized  and many legitimate but not
explicitly authorized applications.

5. Use of an endpoint security solution that provides MAC through
low-level sandboxing to a large user base for the consumer market or
deployed at thousands of different organizations would require the
development and maintenance of "application profiles" for several
thousands closed-source COTS and proprietary applications. Even with
automated tools this is unfeasible to do for a single vendor or security
team thus the problem should be addressed with additional means. In our
case we decided that a divide&conquer strategy might work: we let
technically savvy end users define, review and share the security
configuration ("application profile") of their application. Less savvy
users could secure their endpoints by picking or automatically receiving
configuration files that were developed by others. This brought in
several interesting thoughts and challenges.

6. One u

Re: [SC-L] Microsoft SDL report card

[Steven M. Christey]

Ivan rocks.  This we already know.  Fascinating post!

I believe that for software to be truly secured operationally, it needs to 
change so that it makes itself more easily controllable.  (In general, we 
are seeing this at MITRE with SCAP-related efforts like OVAL and CVE). 
Maybe the app-whitelisting crowd technologies are moving in this 
direction. What we have seen with SELinux is the kind of complexity 
required for doing this kind of configuration, if you're not the software 
owner.


Skipping plugin architectures where everything goes, and I'm sure a ton of 
other complexities, what if software basically told its users where it 
would add/remove files, what ports it listened on, etc.?  Or alternately, 
was configurable in this fashion?  From an operational software-control 
perspective, it would be easier to detect variations from such a 
"profile," and for operating systems to build capabilities that could 
enforce this more abstract level.


And from a software analysis perspective, these "policies" or "profiles" 
or whatever you have, could be fed into automated analysis tools in order 
to reduce false positives, and (perhaps) catch some design-level issues, 
too.  Even apparently "simple" problems like path traversal require some 
knowledge of the business logic of the application in order to determine 
if an issue is a feature or a bug.


The usability problems in app-profiles may be a big hurdle, since apps 
would want to transfer data back and forth... and if I'm editing a 
document, I might want to save it outside of a restricted directory. 
Ivan, did your solutions have any impact on usability?


This sounds awfully familiar to a brief conversation on this list about 
2.5 years ago [1] where Gary pointed out that managed code has such 
capabilities built in, but for the foreseeable future we will be stuck 
with unmanaged code.  And this issue skirts the edges of formal methods, 
too.  But if sandboxing really starts to catch on, maybe there will be 
some hope.


What little I know of the mobile space seems to be attempting to take this 
into account.  In general, it seems to me that "application separation" is 
more built-in to mobile OSes than regular, general-purpose OSes (though 
clearly there are limitations, and some of the same old problems are 
affecting those apps, too.)  On the other hand, I don't exactly feel 
clueful when a mobile app gives a long list of permissions that it needs 
on install, and I have no control after then.


Like Ivan, I'd be very interested in knowing what others have been 
thinking on the problem, and what kind of research or development is 
underway.


- Steve

[1] http://www.securecoding.org/pipermail/sc-l/2008/001591.html
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___