Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-27 Thread Stephen Craig Evans
Whenever I speak with a customer or any software decision makers, I
implore them, before buying another vendor's software, or
hiring/contracting a 3rd party development firm, to ask a couple of
simple questions: What do you do for software security?, and Can
you send me some documents about your software security practices?.

From my experience, that will stop at least 95% of them in their tracks.

There are lots of country-specific 5 to 30 person software shops
located in the major Asian business centers. But even if, say, IBM is
the main contractor to a client of mine, those questions can still be
asked of IBM, and it's their responsibility to get the answers from
the small software shop (and my client will have the documentation as
a trust but verify check for later use).

Stephen

On 11/27/08, Jerry Leichter [EMAIL PROTECTED] wrote:

 On Nov 26, 2008, at 3:05 AM, Stephen Craig Evans wrote:



 Hi Gunnar,

  I apologize to everybody if I have come across as being harsh.

  From my 8 years of experience of living in Asia and being actively
  involved as a developer and working with developers (at Microsoft as
  its first .NET Regional Developer Evangelist in 2001 to recently at
  Symantec as the first Secure Application Services consultant for
  APAC), IMO there's a big gap between the maturity of software security
  here vs. Europe vs. West Coast USA vs. East Coast USA.

  The culture is different and even in the situation that a software
  developer cared and wanted to implement software security, in many
  countries they could get in a lot of trouble for upstaging their boss
  and making him or her lose face.

  The responsibility of secure software is not at the developer level in
  most casesThis has really important implications, and is worthy of
 thought and discussion.

 On the one hand, *right now*, it justifies the complaints about outsourcing:
  That you really can't trust software produced in Asia.  On the other hand,
 the (relative) command-and-control nature of development in Asia means that,
 should management there decide that security is an important issue - and
 since given the nature of their business, they are very sensitive to
 customer demand, that would mean that their customers tell them
 unambiguously that it's what they'll be judged on *and actually act that
 way* - Asian outsourcers are likely to be much more effective at getting
 their organizations to focus on secure practices than we are here in the
 more free-wheeling West.


 -- Jerry



___
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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-26 Thread Stephen Craig Evans
Hi Gunnar,

I apologize to everybody if I have come across as being harsh.

From my 8 years of experience of living in Asia and being actively
involved as a developer and working with developers (at Microsoft as
its first .NET Regional Developer Evangelist in 2001 to recently at
Symantec as the first Secure Application Services consultant for
APAC), IMO there's a big gap between the maturity of software security
here vs. Europe vs. West Coast USA vs. East Coast USA.

The culture is different and even in the situation that a software
developer cared and wanted to implement software security, in many
countries they could get in a lot of trouble for upstaging their boss
and making him or her lose face.

The responsibility of secure software is not at the developer level in
most cases, which is why I've spoken at regional IASA events
(www.iasahome.org), with overwhelming positive responses, and will
continue to try to reach the decision makers (as an OWASP
representative) because trying to engage developers directly at this
point in time at the maturity level of software security in APAC is
not the most effective way to go about it. I'm sure, though, that at
financial institutions they get it, but almost all of my clients are
government and media/communications companies.

Also, sorry to everybody for taking this thread off-topic.

Stephen

On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson [EMAIL PROTECTED] wrote:
 stephen

 i spend at least half my time working directly with developers.

 for some reason i have not communicated as well as i should to you, what i
 am saying is that the job is too hard for developers *because* the security
 industry has let them down by sending them on a fool's errand of least
 privilege.

 the problem or target in your words IS with security people NOT developers.
 they have other problems just not an endless quixotic quest for least
 privilege. i am not repeat not throwing developers under the bus in this
 argument.

 i am ready, willing and possibly able to be proven wrong on this point and
 maybe there is a cost effective way to deploy least privilege in the real
 world just want to make sure that i communicate my argument.

 -gunnar
 (who is now letting go)

 On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote:

 I can't let this go.

 Gary, you are self-professed working with financial institutions and
 high-end customers.

 Gunnar, you are the same, at least what I gather from your Silver
 Bullet podcast when talking about the difference between SOA (top
 down) and Web 2.0 (bottom up).

 No flame war intended, but a healthy discussion should be in order.

 So please don't talk about developers as targets. They/we are the
 lowest on the totem pole. Direct your arrows at the people that you
 deal with. Plain and simple.

 Cheers,
 Stephen

 On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson [EMAIL PROTECTED]
 wrote:

 look, i am a consultant. i work in lots of different companies. lots of
 different projects. i don't see these distinctions in black and white.
 sometimes the cto and managers are best positioned to help companies
 develop
 more secure software, sometimes architects, sometimes auditors, and many
 many times in my experience developers are best positioned.

 but i really, truly do not care who does it. my only goal is more
 effective
 security mechanisms and some pragmatic roadmap to get there. we are in
 the
 infancy of this industry (think automotive safety circa 1942, all seat
 belts
 and brakes), we are in no position to turn away help from anyone who can
 help. every company and every project is different, if your organization
 is
 set up so that developers are not empowered, but managers and CTOs are
 then
 by all means work with them.

 but actually the main point of my post and the one i would like to hear
 people's thoughts on - is to say that attempting to apply principle of
 least
 privilege in the real world often leads to drilling dry wells. i am not
 blaming any group in particular i am saying i think it is in the too
 hard
 pile for now and we as software security people should not be advocating
 for
 it until or unless we can find cost effective ways to implement it.

 -gunnar

 On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote:

 It's a real cop-out for you guys, as titans in the industry, to go
 after developers. I'm disappointed in both of you. And Gary, you said
 One of the main challenges is that developers have a hard time
 thinking about the principle of least privilege .

 Developers are NEVER asked to think about the principle of least
 privilege. Or your world of software security must be very very very
 different from mine (and I think my world at least equals   yours but
 by about 2 billion people more, which might be irrelevant now but a
 little more relevant in the future :-)

 With the greatest, deepest respect to both of you,
 Stephen

 On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans
 [EMAIL PROTECTED] wrote:

 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-26 Thread Dana Epp
With all due respect, I think this is where the process of secure coding
fails. I think it stems from poor education, but its compounded by an
arrogant cop out that developers have no power. Your view is not alone. I
hear it a lot. And I think its an easy out.

I agree with you that buy in for designing secure code must come from the
top down. It has to start at the senior management level and work its way
down the line. However, there are certain day-to-day actions that a
developer completely has control over.

With tight deadlines and lack of resources its easy to sacrifice good
principles and practices to get code out. No one denies that. But there are
certain things developers CAN and SHOULD be doing. They should be thinking
more defensively about their code. If you consider the criticality of many
design flaws of today, a lot of it can be controlled by better understanding
how the data traverses the systems, and more importantly how to address it
as it crosses trust boundaries. By understanding this, its easier to see the
entry points that matter most that an adversary may use, and allows the
developer to decide how to deal with the code as it fails. This has very
little to do with management. This is the difference between strategic and
tactical decisions on project development. A developer doesn't need to ask
his boss if he can or should use exception handling correctly. To validate
all untrusted user input. To check return codes when calling functions.
Sadly... in this day and age... most developers don't even do that
correctly. And thats a simple example of this entire problem.

Until we stop blaming others and take responsibility in the code we write,
things won't change. As Gary mentioned... there is an attitude from many
developers that they can abdocate responsibility in what they are doing. Its
hard to get them to even SAY security. Never mind actually making an effort
to do something about it.

I appreciate your opinion that you need to approach and work with the
decision makes. You are absolutely correct. That's a strategic component of
writing secure code. However the tactical approach to actually DO IT fall on
developers. It shouldn't BE a special process. It should be part of their
day-to-day thinking, attitude and function in their field of work.

Guess where this all starts? By educating the developer. Which is why we
squarely need to reflect on them to tactically do it.

-- 
Regards,
Dana Epp
Microsoft Security MVP

On Tue, Nov 25, 2008 at 9:01 AM, Stephen Craig Evans 
[EMAIL PROTECTED] wrote:

 Gunnar,

 Developers have no power. You should be talking to the decision makers.

 As an example, to instill the importance of software security, I talk
 to decision makers: project managers, architects, CTOs (admittedly,
 this is a blurred line - lots of folks call themselves architects). If
 I go to talk about software security to developers, I know from
 experience that I am probably wasting my time. Even if they do care,
 they have no effect overall.

 Your target and blame is wrong; that's all that I am saying.

 Stephen

 On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson
  [EMAIL PROTECTED] wrote:
  Sorry I didn't realize developers is an offensive ivory tower in other
  parts of the world, in my world its a compliment.
 
  -gunnar
 
  On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote:
 
  HI,
 
  maybe the problem with least privilege is that it requires that
  developers:...
 
  IMHO, your US/UK ivory towers don't exist in other parts of the world.
  Developers have no say in what they do. Nor, do they care about
  software security and why should they care?
 
  So, at least, change your nomenclature and not say developers. It
  offends me because you are putting the onus of knowing about software
  security on the wrong people.
 
  Cheers,
  Stephen
 
  On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
  [EMAIL PROTECTED] wrote:
 
  maybe the problem with least privilege is that it requires that
  developers:
 
  1. define the entire universe of subjects and objects
  2. define all possible access rights
  3. define all possible relationships
  4. apply all settings
  5. figure out how to keep 1-4 in synch all the time
 
  do all of this before you start writing code and oh and there are
  basically no tools that smooth the adoption of the above.
 
  i don't think us software security people are helping anybody out in
  2008 by doing ritual incantations of a paper from the mid 70s that may
  or may not apply to modern computing and anyhow is riddled with ideas
  that have never been implemented in any large scale systems
 
  compare these two statements
 
  Statement 1. Saltzer and Schroeder:
  f) Least privilege: Every program and every user of the system should
  operate using the least set of privileges necessary to complete the
  job. Primarily, this principle limits the damage that can result from
  an accident or error. It also reduces the number of potential
  

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-26 Thread ljknews
At 9:32 PM -0800 11/25/08, Brian Chess wrote:

 Larry, I'm not sure I get your meaning.  You say you don't think it's a
dry well, but then you say programmers ignore the privilege management
facilities at their disposal.

I mean they ignore it until security overseers (800.53a, PCI DSS,
8500.2 evaluators) come by and force them to fix it.

 At 10:57 AM -0800 11/25/08, Andy Steingruebl wrote:
 On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson
mailto:[EMAIL PROTECTED][EMAIL PROTECTED]mailto:[EMAIL PROTECTED][EMAIL 
PROTECTED]
wrote:


 but actually the main point of my post and the one i would like to
 hear people's thoughts on - is to say that attempting to apply
 principle of least privilege in the real world often leads to drilling
 dry wells. i am not blaming any group in particular i am saying i
 think it is in the too hard pile for now and we as software security
 people should not be advocating for it until or unless we can find
 cost effective ways to implement it.

 Certainly it is not a dry well.  For the operating system I deal
 with, application programmers _consistently_ ignore the facility
 provided for fine-grained access to files and leave users with
 coarse-grained access as their only recourse.

So attempting to apply it is not a dry well and not too hard -
just typically done as a retrofit due to political rather than
techical circumstance.

I had a friend who was working on software where multi-million
dollar accounts failed to balance correctly.  That defect got
considerable management attention.  The same _could_ be done
for security.
-- 
Larry Kilgallen
___
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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-26 Thread Susan Bradley
There is a lot of USA firm coding done outside our shores.  Thus the 
attitude you are reporting impacts the software I am buying both for my 
desktop as well as the upcoming cloud applications.

This is the part that concerns me.  As a consumer of code when it's in 
my possession I am then able to do what I can to augment the security of 
it.  When it's in the cloud, I'm depending on the vendor of the cloud to 
have thought about security .

We need to get to the place where you can come back in a few years and 
say that the culture has changed.

IMHO don't apologize.  It shows that we still need to get 
consumers/buyers of code to care that Developers are taught to care.

We have work to do.

Stephen Craig Evans wrote:
 Hi Gunnar,

 I apologize to everybody if I have come across as being harsh.

 From my 8 years of experience of living in Asia and being actively
 involved as a developer and working with developers (at Microsoft as
 its first .NET Regional Developer Evangelist in 2001 to recently at
 Symantec as the first Secure Application Services consultant for
 APAC), IMO there's a big gap between the maturity of software security
 here vs. Europe vs. West Coast USA vs. East Coast USA.

 The culture is different and even in the situation that a software
 developer cared and wanted to implement software security, in many
 countries they could get in a lot of trouble for upstaging their boss
 and making him or her lose face.

 The responsibility of secure software is not at the developer level in
 most cases, which is why I've spoken at regional IASA events
 (www.iasahome.org), with overwhelming positive responses, and will
 continue to try to reach the decision makers (as an OWASP
 representative) because trying to engage developers directly at this
 point in time at the maturity level of software security in APAC is
 not the most effective way to go about it. I'm sure, though, that at
 financial institutions they get it, but almost all of my clients are
 government and media/communications companies.

 Also, sorry to everybody for taking this thread off-topic.

 Stephen

 On Wed, Nov 26, 2008 at 2:24 AM, Gunnar Peterson [EMAIL PROTECTED] wrote:
   
 stephen

 i spend at least half my time working directly with developers.

 for some reason i have not communicated as well as i should to you, what i
 am saying is that the job is too hard for developers *because* the security
 industry has let them down by sending them on a fool's errand of least
 privilege.

 the problem or target in your words IS with security people NOT developers.
 they have other problems just not an endless quixotic quest for least
 privilege. i am not repeat not throwing developers under the bus in this
 argument.

 i am ready, willing and possibly able to be proven wrong on this point and
 maybe there is a cost effective way to deploy least privilege in the real
 world just want to make sure that i communicate my argument.

 -gunnar
 (who is now letting go)

 On Nov 25, 2008, at 12:07 PM, Stephen Craig Evans wrote:

 
 I can't let this go.

 Gary, you are self-professed working with financial institutions and
 high-end customers.

 Gunnar, you are the same, at least what I gather from your Silver
 Bullet podcast when talking about the difference between SOA (top
 down) and Web 2.0 (bottom up).

 No flame war intended, but a healthy discussion should be in order.

 So please don't talk about developers as targets. They/we are the
 lowest on the totem pole. Direct your arrows at the people that you
 deal with. Plain and simple.

 Cheers,
 Stephen

 On Wed, Nov 26, 2008 at 1:48 AM, Gunnar Peterson [EMAIL PROTECTED]
 wrote:
   
 look, i am a consultant. i work in lots of different companies. lots of
 different projects. i don't see these distinctions in black and white.
 sometimes the cto and managers are best positioned to help companies
 develop
 more secure software, sometimes architects, sometimes auditors, and many
 many times in my experience developers are best positioned.

 but i really, truly do not care who does it. my only goal is more
 effective
 security mechanisms and some pragmatic roadmap to get there. we are in
 the
 infancy of this industry (think automotive safety circa 1942, all seat
 belts
 and brakes), we are in no position to turn away help from anyone who can
 help. every company and every project is different, if your organization
 is
 set up so that developers are not empowered, but managers and CTOs are
 then
 by all means work with them.

 but actually the main point of my post and the one i would like to hear
 people's thoughts on - is to say that attempting to apply principle of
 least
 privilege in the real world often leads to drilling dry wells. i am not
 blaming any group in particular i am saying i think it is in the too
 hard
 pile for now and we as software security people should not be advocating
 for
 it until or unless we can find cost effective ways to implement it.

 -gunnar

 On Nov 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-26 Thread Jerry Leichter

On Nov 26, 2008, at 3:05 AM, Stephen Craig Evans wrote:


Hi Gunnar,

I apologize to everybody if I have come across as being harsh.

From my 8 years of experience of living in Asia and being actively
involved as a developer and working with developers (at Microsoft as
its first .NET Regional Developer Evangelist in 2001 to recently at
Symantec as the first Secure Application Services consultant for
APAC), IMO there's a big gap between the maturity of software security
here vs. Europe vs. West Coast USA vs. East Coast USA.

The culture is different and even in the situation that a software
developer cared and wanted to implement software security, in many
countries they could get in a lot of trouble for upstaging their boss
and making him or her lose face.

The responsibility of secure software is not at the developer level in
most cases

This has really important implications, and is worthy of thought and  
discussion.


On the one hand, *right now*, it justifies the complaints about  
outsourcing:  That you really can't trust software produced in Asia.   
On the other hand, the (relative) command-and-control nature of  
development in Asia means that, should management there decide that  
security is an important issue - and since given the nature of their  
business, they are very sensitive to customer demand, that would mean  
that their customers tell them unambiguously that it's what they'll be  
judged on *and actually act that way* - Asian outsourcers are likely  
to be much more effective at getting their organizations to focus on  
secure practices than we are here in the more free-wheeling West.


-- Jerry


___
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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Gary McGraw
Sadly this non-adoption of privileged/managed code (filled with blank stares) 
has been the case ever since the Java security days a decade ago.  One of the 
main challenges is that developers have a hard time thinking about the 
principle of least privilege and its implications regarding the capabilities 
they should request.  Dinis is brave to set such thinking as a target.  I've 
settled (after ten years) with getting developers just to utter the word 
security.

All together now...security.

gem

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


On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote:

Dinis Cruz wrote:
 Don't get me wrong, this is a great document if one is interested in
 writing applications that use CAS (Code Access Security), I would love
 for this to be widely used.

When we recommended recommending CAS during a review of the U.S. Defense
Information System Agency's new Application Security and Development
Security Technical Implementation Guide earlier this year we were met
with what amounted to blank stares. (At least it seemed like that since
it was a phone conference.) Some on the call understood it and agreed
with the recommendation but those hosting the call and doing the writing
didn't seem to grasp it. It may be a while before we see too many
adopting this or requiring it for a while.
--

Mike Lyman
[EMAIL PROTECTED]

___
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.
___


___
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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Gunnar Peterson
maybe the problem with least privilege is that it requires that  
developers:

1. define the entire universe of subjects and objects
2. define all possible access rights
3. define all possible relationships
4. apply all settings
5. figure out how to keep 1-4 in synch all the time

do all of this before you start writing code and oh and there are  
basically no tools that smooth the adoption of the above.

i don't think us software security people are helping anybody out in  
2008 by doing ritual incantations of a paper from the mid 70s that may  
or may not apply to modern computing and anyhow is riddled with ideas  
that have never been implemented in any large scale systems

compare these two statements

Statement 1. Saltzer and Schroeder:
f) Least privilege: Every program and every user of the system should  
operate using the least set of privileges necessary to complete the  
job. Primarily, this principle limits the damage that can result from  
an accident or error. It also reduces the number of potential  
interactions among privileged programs to the minimum for correct  
operation, so that unintentional, unwanted, or improper uses of  
privilege are less likely to occur. Thus, if a question arises related  
to misuse of a privilege, the number of programs that must be audited  
is minimized. Put another way, if a mechanism can provide firewalls,  
the principle of least privilege provides a rationale for where to  
install the firewalls. The military security rule of need-to-know is  
an example of this principle.

Statement 2. David Gelernter's Manifesto:
28. Metaphors have a profound effect on computing: the file-cabinet  
metaphor traps us in a passive instead of active view of  
information management that is fundamentally wrong for computers.

29. The rigid file and directory system you are stuck with on your Mac  
or PC was designed by programmers for programmers — and is still a  
good system for programmers. It is no good for non-programmers. It  
never was, and was never intended to be.

30. If you have three pet dogs, give them names. If you have 10,000  
head of cattle, don't bother. Nowadays the idea of giving a name to  
every file on your computer is ridiculous.

Conclusion(gp): Least Privilege is the point where the practical  
matter of applying Saltzer and Schroeder's principles breaks down in  
modern systems. Its a deployment issue, and a matter of insufficient  
models and modes.

http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html

Remember the 1990s when there were all these search engines that  
required you tag up all the content and put it in hierarchical  
directories and so on? Well what happened? Google came along and ate  
their lunch. When the problem is information overload, telling  
everyone to go out and label everything is not gonna work.

-gunnar



On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote:

 Sadly this non-adoption of privileged/managed code (filled with  
 blank stares) has been the case ever since the Java security days a  
 decade ago.  One of the main challenges is that developers have a  
 hard time thinking about the principle of least privilege and its  
 implications regarding the capabilities they should request.  Dinis  
 is brave to set such thinking as a target.  I've settled (after ten  
 years) with getting developers just to utter the word security.

 All together now...security.

 gem

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


 On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote:

 Dinis Cruz wrote:
 Don't get me wrong, this is a great document if one is interested in
 writing applications that use CAS (Code Access Security), I would  
 love
 for this to be widely used.

 When we recommended recommending CAS during a review of the U.S.  
 Defense
 Information System Agency's new Application Security and Development
 Security Technical Implementation Guide earlier this year we were met
 with what amounted to blank stares. (At least it seemed like that  
 since
 it was a phone conference.) Some on the call understood it and agreed
 with the recommendation but those hosting the call and doing the  
 writing
 didn't seem to grasp it. It may be a while before we see too many
 adopting this or requiring it for a while.
 --

 Mike Lyman
 [EMAIL PROTECTED]

 ___
 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.
 ___


 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Gunnar Peterson
Sorry I didn't realize developers is an offensive ivory tower in  
other parts of the world, in my world its a compliment.

-gunnar

On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote:

 HI,

 maybe the problem with least privilege is that it requires that  
 developers:...

 IMHO, your US/UK ivory towers don't exist in other parts of the world.
 Developers have no say in what they do. Nor, do they care about
 software security and why should they care?

 So, at least, change your nomenclature and not say developers. It
 offends me because you are putting the onus of knowing about software
 security on the wrong people.

 Cheers,
 Stephen

 On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:
 maybe the problem with least privilege is that it requires that
 developers:

 1. define the entire universe of subjects and objects
 2. define all possible access rights
 3. define all possible relationships
 4. apply all settings
 5. figure out how to keep 1-4 in synch all the time

 do all of this before you start writing code and oh and there are
 basically no tools that smooth the adoption of the above.

 i don't think us software security people are helping anybody out in
 2008 by doing ritual incantations of a paper from the mid 70s that  
 may
 or may not apply to modern computing and anyhow is riddled with ideas
 that have never been implemented in any large scale systems

 compare these two statements

 Statement 1. Saltzer and Schroeder:
 f) Least privilege: Every program and every user of the system  
 should
 operate using the least set of privileges necessary to complete the
 job. Primarily, this principle limits the damage that can result from
 an accident or error. It also reduces the number of potential
 interactions among privileged programs to the minimum for correct
 operation, so that unintentional, unwanted, or improper uses of
 privilege are less likely to occur. Thus, if a question arises  
 related
 to misuse of a privilege, the number of programs that must be audited
 is minimized. Put another way, if a mechanism can provide  
 firewalls,
 the principle of least privilege provides a rationale for where to
 install the firewalls. The military security rule of need-to-know  
 is
 an example of this principle.

 Statement 2. David Gelernter's Manifesto:
 28. Metaphors have a profound effect on computing: the file-cabinet
 metaphor traps us in a passive instead of active view of
 information management that is fundamentally wrong for computers.

 29. The rigid file and directory system you are stuck with on your  
 Mac
 or PC was designed by programmers for programmers — and is still a
 good system for programmers. It is no good for non-programmers. It
 never was, and was never intended to be.

 30. If you have three pet dogs, give them names. If you have 10,000
 head of cattle, don't bother. Nowadays the idea of giving a name to
 every file on your computer is ridiculous.

 Conclusion(gp): Least Privilege is the point where the practical
 matter of applying Saltzer and Schroeder's principles breaks down in
 modern systems. Its a deployment issue, and a matter of insufficient
 models and modes.

 http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html

 Remember the 1990s when there were all these search engines that
 required you tag up all the content and put it in hierarchical
 directories and so on? Well what happened? Google came along and ate
 their lunch. When the problem is information overload, telling
 everyone to go out and label everything is not gonna work.

 -gunnar



 On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote:

 Sadly this non-adoption of privileged/managed code (filled with
 blank stares) has been the case ever since the Java security days a
 decade ago.  One of the main challenges is that developers have a
 hard time thinking about the principle of least privilege and its
 implications regarding the capabilities they should request.  Dinis
 is brave to set such thinking as a target.  I've settled (after ten
 years) with getting developers just to utter the word security.

 All together now...security.

 gem

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


 On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote:

 Dinis Cruz wrote:
 Don't get me wrong, this is a great document if one is interested  
 in
 writing applications that use CAS (Code Access Security), I would
 love
 for this to be widely used.

 When we recommended recommending CAS during a review of the U.S.
 Defense
 Information System Agency's new Application Security and Development
 Security Technical Implementation Guide earlier this year we were  
 met
 with what amounted to blank stares. (At least it seemed like that
 since
 it was a phone conference.) Some on the call understood it and  
 agreed
 with the recommendation but those hosting the call and doing the
 writing
 didn't seem to 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Stephen Craig Evans
HI,

maybe the problem with least privilege is that it requires that developers:...

IMHO, your US/UK ivory towers don't exist in other parts of the world.
Developers have no say in what they do. Nor, do they care about
software security and why should they care?

So, at least, change your nomenclature and not say developers. It
offends me because you are putting the onus of knowing about software
security on the wrong people.

Cheers,
Stephen

On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
[EMAIL PROTECTED] wrote:
 maybe the problem with least privilege is that it requires that
 developers:

 1. define the entire universe of subjects and objects
 2. define all possible access rights
 3. define all possible relationships
 4. apply all settings
 5. figure out how to keep 1-4 in synch all the time

 do all of this before you start writing code and oh and there are
 basically no tools that smooth the adoption of the above.

 i don't think us software security people are helping anybody out in
 2008 by doing ritual incantations of a paper from the mid 70s that may
 or may not apply to modern computing and anyhow is riddled with ideas
 that have never been implemented in any large scale systems

 compare these two statements

 Statement 1. Saltzer and Schroeder:
 f) Least privilege: Every program and every user of the system should
 operate using the least set of privileges necessary to complete the
 job. Primarily, this principle limits the damage that can result from
 an accident or error. It also reduces the number of potential
 interactions among privileged programs to the minimum for correct
 operation, so that unintentional, unwanted, or improper uses of
 privilege are less likely to occur. Thus, if a question arises related
 to misuse of a privilege, the number of programs that must be audited
 is minimized. Put another way, if a mechanism can provide firewalls,
 the principle of least privilege provides a rationale for where to
 install the firewalls. The military security rule of need-to-know is
 an example of this principle.

 Statement 2. David Gelernter's Manifesto:
 28. Metaphors have a profound effect on computing: the file-cabinet
 metaphor traps us in a passive instead of active view of
 information management that is fundamentally wrong for computers.

 29. The rigid file and directory system you are stuck with on your Mac
 or PC was designed by programmers for programmers — and is still a
 good system for programmers. It is no good for non-programmers. It
 never was, and was never intended to be.

 30. If you have three pet dogs, give them names. If you have 10,000
 head of cattle, don't bother. Nowadays the idea of giving a name to
 every file on your computer is ridiculous.

 Conclusion(gp): Least Privilege is the point where the practical
 matter of applying Saltzer and Schroeder's principles breaks down in
 modern systems. Its a deployment issue, and a matter of insufficient
 models and modes.

 http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html

 Remember the 1990s when there were all these search engines that
 required you tag up all the content and put it in hierarchical
 directories and so on? Well what happened? Google came along and ate
 their lunch. When the problem is information overload, telling
 everyone to go out and label everything is not gonna work.

 -gunnar



 On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote:

 Sadly this non-adoption of privileged/managed code (filled with
 blank stares) has been the case ever since the Java security days a
 decade ago.  One of the main challenges is that developers have a
 hard time thinking about the principle of least privilege and its
 implications regarding the capabilities they should request.  Dinis
 is brave to set such thinking as a target.  I've settled (after ten
 years) with getting developers just to utter the word security.

 All together now...security.

 gem

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


 On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote:

 Dinis Cruz wrote:
 Don't get me wrong, this is a great document if one is interested in
 writing applications that use CAS (Code Access Security), I would
 love
 for this to be widely used.

 When we recommended recommending CAS during a review of the U.S.
 Defense
 Information System Agency's new Application Security and Development
 Security Technical Implementation Guide earlier this year we were met
 with what amounted to blank stares. (At least it seemed like that
 since
 it was a phone conference.) Some on the call understood it and agreed
 with the recommendation but those hosting the call and doing the
 writing
 didn't seem to grasp it. It may be a while before we see too many
 adopting this or requiring it for a while.
 --

 Mike Lyman
 [EMAIL PROTECTED]

 ___
 Secure Coding mailing list (SC-L) 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Stephen Craig Evans
Gunnar,

Developers have no power. You should be talking to the decision makers.

As an example, to instill the importance of software security, I talk
to decision makers: project managers, architects, CTOs (admittedly,
this is a blurred line - lots of folks call themselves architects). If
I go to talk about software security to developers, I know from
experience that I am probably wasting my time. Even if they do care,
they have no effect overall.

Your target and blame is wrong; that's all that I am saying.

Stephen

On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson
[EMAIL PROTECTED] wrote:
 Sorry I didn't realize developers is an offensive ivory tower in other
 parts of the world, in my world its a compliment.

 -gunnar

 On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote:

 HI,

 maybe the problem with least privilege is that it requires that
 developers:...

 IMHO, your US/UK ivory towers don't exist in other parts of the world.
 Developers have no say in what they do. Nor, do they care about
 software security and why should they care?

 So, at least, change your nomenclature and not say developers. It
 offends me because you are putting the onus of knowing about software
 security on the wrong people.

 Cheers,
 Stephen

 On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:

 maybe the problem with least privilege is that it requires that
 developers:

 1. define the entire universe of subjects and objects
 2. define all possible access rights
 3. define all possible relationships
 4. apply all settings
 5. figure out how to keep 1-4 in synch all the time

 do all of this before you start writing code and oh and there are
 basically no tools that smooth the adoption of the above.

 i don't think us software security people are helping anybody out in
 2008 by doing ritual incantations of a paper from the mid 70s that may
 or may not apply to modern computing and anyhow is riddled with ideas
 that have never been implemented in any large scale systems

 compare these two statements

 Statement 1. Saltzer and Schroeder:
 f) Least privilege: Every program and every user of the system should
 operate using the least set of privileges necessary to complete the
 job. Primarily, this principle limits the damage that can result from
 an accident or error. It also reduces the number of potential
 interactions among privileged programs to the minimum for correct
 operation, so that unintentional, unwanted, or improper uses of
 privilege are less likely to occur. Thus, if a question arises related
 to misuse of a privilege, the number of programs that must be audited
 is minimized. Put another way, if a mechanism can provide firewalls,
 the principle of least privilege provides a rationale for where to
 install the firewalls. The military security rule of need-to-know is
 an example of this principle.

 Statement 2. David Gelernter's Manifesto:
 28. Metaphors have a profound effect on computing: the file-cabinet
 metaphor traps us in a passive instead of active view of
 information management that is fundamentally wrong for computers.

 29. The rigid file and directory system you are stuck with on your Mac
 or PC was designed by programmers for programmers — and is still a
 good system for programmers. It is no good for non-programmers. It
 never was, and was never intended to be.

 30. If you have three pet dogs, give them names. If you have 10,000
 head of cattle, don't bother. Nowadays the idea of giving a name to
 every file on your computer is ridiculous.

 Conclusion(gp): Least Privilege is the point where the practical
 matter of applying Saltzer and Schroeder's principles breaks down in
 modern systems. Its a deployment issue, and a matter of insufficient
 models and modes.

 http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html

 Remember the 1990s when there were all these search engines that
 required you tag up all the content and put it in hierarchical
 directories and so on? Well what happened? Google came along and ate
 their lunch. When the problem is information overload, telling
 everyone to go out and label everything is not gonna work.

 -gunnar



 On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote:

 Sadly this non-adoption of privileged/managed code (filled with
 blank stares) has been the case ever since the Java security days a
 decade ago.  One of the main challenges is that developers have a
 hard time thinking about the principle of least privilege and its
 implications regarding the capabilities they should request.  Dinis
 is brave to set such thinking as a target.  I've settled (after ten
 years) with getting developers just to utter the word security.

 All together now...security.

 gem

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


 On 11/24/08 12:31 PM, Mike Lyman [EMAIL PROTECTED] wrote:

 Dinis Cruz wrote:

 Don't get me wrong, this is a great document if 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Peter G. Neumann
And don't forget the Paul Karger paper from Oakland, which applies access
controls to executables and effectively provides implementations for
Saltzer-Schroeder's least privilege and more:

@InProceedings{Karger87, 
Key=Karger, Author=P.A. Karger, 
Title=Limiting the Damage Potential of Discretionary {T}rojan Horses, 
BookTitle=Proceedings of the 1987 Symposium on Security and Privacy, 
Organization=IEEE Computer Society,
Address=Oakland, California, Year=1987, Month=April, pages=32--37}

___
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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Gary McGraw
Hi Stephen,

I don't think I belong in the dog house with gunnar on this one (though if I 
have to share the dog house gunnar would be a decent compatriot).  Please 
re-read my post and you will see that I gave up on the Dinis quest though I 
have lots of respect for what Dinis wants to accomplish.

That said, I do believe in educating and training developers about software 
security.  I also strongly agree with you that a software security initiative 
must involve management and technology leaders and not degenerate into secure 
coding.  These days my writings are aimed at leadership...see 
http://www.cigital.com/~gem/writings/

Just at the moment I am working hard on a maturity model for software security 
based on 9 top initiatives.  Sammy Migues, Brian Chess, and I have uncovered 
some very amazing things in our anthropology experiment so far.  We'll 
probably be set to share them by the end of the year.

Anyway, sorry not to propagate the flame war without even donning an asbestos 
suit, but what can I say?

gem

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


On 11/25/08 12:28 PM, Stephen Craig Evans [EMAIL PROTECTED] wrote:

It's a real cop-out for you guys, as titans in the industry, to go
after developers. I'm disappointed in both of you. And Gary, you said
One of the main challenges is that developers have a hard time
thinking about the principle of least privilege .

Developers are NEVER asked to think about the principle of least
privilege. Or your world of software security must be very very very
different from mine (and I think my world at least equals   yours but
by about 2 billion people more, which might be irrelevant now but a
little more relevant in the future :-)

With the greatest, deepest respect to both of you,
Stephen

On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans
[EMAIL PROTECTED] wrote:
 Gunnar,

 Developers have no power. You should be talking to the decision makers.

 As an example, to instill the importance of software security, I talk
 to decision makers: project managers, architects, CTOs (admittedly,
 this is a blurred line - lots of folks call themselves architects). If
 I go to talk about software security to developers, I know from
 experience that I am probably wasting my time. Even if they do care,
 they have no effect overall.

 Your target and blame is wrong; that's all that I am saying.

 Stephen

 On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:
 Sorry I didn't realize developers is an offensive ivory tower in other
 parts of the world, in my world its a compliment.

 -gunnar

 On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote:

 HI,

 maybe the problem with least privilege is that it requires that
 developers:...

 IMHO, your US/UK ivory towers don't exist in other parts of the world.
 Developers have no say in what they do. Nor, do they care about
 software security and why should they care?

 So, at least, change your nomenclature and not say developers. It
 offends me because you are putting the onus of knowing about software
 security on the wrong people.

 Cheers,
 Stephen

 On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:

 maybe the problem with least privilege is that it requires that
 developers:

 1. define the entire universe of subjects and objects
 2. define all possible access rights
 3. define all possible relationships
 4. apply all settings
 5. figure out how to keep 1-4 in synch all the time

 do all of this before you start writing code and oh and there are
 basically no tools that smooth the adoption of the above.

 i don't think us software security people are helping anybody out in
 2008 by doing ritual incantations of a paper from the mid 70s that may
 or may not apply to modern computing and anyhow is riddled with ideas
 that have never been implemented in any large scale systems

 compare these two statements

 Statement 1. Saltzer and Schroeder:
 f) Least privilege: Every program and every user of the system should
 operate using the least set of privileges necessary to complete the
 job. Primarily, this principle limits the damage that can result from
 an accident or error. It also reduces the number of potential
 interactions among privileged programs to the minimum for correct
 operation, so that unintentional, unwanted, or improper uses of
 privilege are less likely to occur. Thus, if a question arises related
 to misuse of a privilege, the number of programs that must be audited
 is minimized. Put another way, if a mechanism can provide firewalls,
 the principle of least privilege provides a rationale for where to
 install the firewalls. The military security rule of need-to-know is
 an example of this principle.

 Statement 2. David Gelernter's Manifesto:
 28. Metaphors have a profound effect on computing: the file-cabinet
 metaphor traps us in a passive instead of active view of
 information 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Stephen Craig Evans
It's a real cop-out for you guys, as titans in the industry, to go
after developers. I'm disappointed in both of you. And Gary, you said
One of the main challenges is that developers have a hard time
thinking about the principle of least privilege .

Developers are NEVER asked to think about the principle of least
privilege. Or your world of software security must be very very very
different from mine (and I think my world at least equals   yours but
by about 2 billion people more, which might be irrelevant now but a
little more relevant in the future :-)

With the greatest, deepest respect to both of you,
Stephen

On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans
[EMAIL PROTECTED] wrote:
 Gunnar,

 Developers have no power. You should be talking to the decision makers.

 As an example, to instill the importance of software security, I talk
 to decision makers: project managers, architects, CTOs (admittedly,
 this is a blurred line - lots of folks call themselves architects). If
 I go to talk about software security to developers, I know from
 experience that I am probably wasting my time. Even if they do care,
 they have no effect overall.

 Your target and blame is wrong; that's all that I am saying.

 Stephen

 On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:
 Sorry I didn't realize developers is an offensive ivory tower in other
 parts of the world, in my world its a compliment.

 -gunnar

 On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote:

 HI,

 maybe the problem with least privilege is that it requires that
 developers:...

 IMHO, your US/UK ivory towers don't exist in other parts of the world.
 Developers have no say in what they do. Nor, do they care about
 software security and why should they care?

 So, at least, change your nomenclature and not say developers. It
 offends me because you are putting the onus of knowing about software
 security on the wrong people.

 Cheers,
 Stephen

 On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:

 maybe the problem with least privilege is that it requires that
 developers:

 1. define the entire universe of subjects and objects
 2. define all possible access rights
 3. define all possible relationships
 4. apply all settings
 5. figure out how to keep 1-4 in synch all the time

 do all of this before you start writing code and oh and there are
 basically no tools that smooth the adoption of the above.

 i don't think us software security people are helping anybody out in
 2008 by doing ritual incantations of a paper from the mid 70s that may
 or may not apply to modern computing and anyhow is riddled with ideas
 that have never been implemented in any large scale systems

 compare these two statements

 Statement 1. Saltzer and Schroeder:
 f) Least privilege: Every program and every user of the system should
 operate using the least set of privileges necessary to complete the
 job. Primarily, this principle limits the damage that can result from
 an accident or error. It also reduces the number of potential
 interactions among privileged programs to the minimum for correct
 operation, so that unintentional, unwanted, or improper uses of
 privilege are less likely to occur. Thus, if a question arises related
 to misuse of a privilege, the number of programs that must be audited
 is minimized. Put another way, if a mechanism can provide firewalls,
 the principle of least privilege provides a rationale for where to
 install the firewalls. The military security rule of need-to-know is
 an example of this principle.

 Statement 2. David Gelernter's Manifesto:
 28. Metaphors have a profound effect on computing: the file-cabinet
 metaphor traps us in a passive instead of active view of
 information management that is fundamentally wrong for computers.

 29. The rigid file and directory system you are stuck with on your Mac
 or PC was designed by programmers for programmers — and is still a
 good system for programmers. It is no good for non-programmers. It
 never was, and was never intended to be.

 30. If you have three pet dogs, give them names. If you have 10,000
 head of cattle, don't bother. Nowadays the idea of giving a name to
 every file on your computer is ridiculous.

 Conclusion(gp): Least Privilege is the point where the practical
 matter of applying Saltzer and Schroeder's principles breaks down in
 modern systems. Its a deployment issue, and a matter of insufficient
 models and modes.

 http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html

 Remember the 1990s when there were all these search engines that
 required you tag up all the content and put it in hierarchical
 directories and so on? Well what happened? Google came along and ate
 their lunch. When the problem is information overload, telling
 everyone to go out and label everything is not gonna work.

 -gunnar



 On Nov 24, 2008, at 4:34 PM, Gary McGraw wrote:

 Sadly this non-adoption of privileged/managed 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Susan Bradley, CPA
Why shouldn't they be asked to think about it?  Especially now.

I do.  I install Vista and find out how many of my apps don't like it.  
Go grab a copy of Luabuglight and watch Aaron Margosis' stuff.  Why 
should I as an Admin have to care about this stuff  after Developers 
that don't care about it code software?

Okay yeah so the management has to have the religion of it but if 
developers at their core do not care then IMHO I as a consumer of code 
need to ensure that they do.  You can't add it on afterwards, so if the 
developers doing the coding do not care because ultimately management 
does not, we still have a fundamental problem in the software industry.

Dana Epp's ramblings at the Sanctuary: Introduction to Microsoft's SDL 
Threat Modeling Tool:
http://silverstr.ufies.org/blog/archives/001060.html

He's a developer and he cares.  And he definitely cares about least priv 
and ensure that his code doesn't ask anything that it shouldn't.

Stephen Craig Evans wrote:
 It's a real cop-out for you guys, as titans in the industry, to go
 after developers. I'm disappointed in both of you. And Gary, you said
 One of the main challenges is that developers have a hard time
 thinking about the principle of least privilege .

 Developers are NEVER asked to think about the principle of least
 privilege. Or your world of software security must be very very very
 different from mine (and I think my world at least equals   yours but
 by about 2 billion people more, which might be irrelevant now but a
 little more relevant in the future :-)

 With the greatest, deepest respect to both of you,
 Stephen

 On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans
 [EMAIL PROTECTED] wrote:
   
 Gunnar,

 Developers have no power. You should be talking to the decision makers.

 As an example, to instill the importance of software security, I talk
 to decision makers: project managers, architects, CTOs (admittedly,
 this is a blurred line - lots of folks call themselves architects). If
 I go to talk about software security to developers, I know from
 experience that I am probably wasting my time. Even if they do care,
 they have no effect overall.

 Your target and blame is wrong; that's all that I am saying.

 Stephen

 On Wed, Nov 26, 2008 at 12:48 AM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:
 
 Sorry I didn't realize developers is an offensive ivory tower in other
 parts of the world, in my world its a compliment.

 -gunnar

 On Nov 25, 2008, at 10:30 AM, Stephen Craig Evans wrote:

   
 HI,

 maybe the problem with least privilege is that it requires that
 developers:...

 IMHO, your US/UK ivory towers don't exist in other parts of the world.
 Developers have no say in what they do. Nor, do they care about
 software security and why should they care?

 So, at least, change your nomenclature and not say developers. It
 offends me because you are putting the onus of knowing about software
 security on the wrong people.

 Cheers,
 Stephen

 On Tue, Nov 25, 2008 at 10:18 PM, Gunnar Peterson
 [EMAIL PROTECTED] wrote:
 
 maybe the problem with least privilege is that it requires that
 developers:

 1. define the entire universe of subjects and objects
 2. define all possible access rights
 3. define all possible relationships
 4. apply all settings
 5. figure out how to keep 1-4 in synch all the time

 do all of this before you start writing code and oh and there are
 basically no tools that smooth the adoption of the above.

 i don't think us software security people are helping anybody out in
 2008 by doing ritual incantations of a paper from the mid 70s that may
 or may not apply to modern computing and anyhow is riddled with ideas
 that have never been implemented in any large scale systems

 compare these two statements

 Statement 1. Saltzer and Schroeder:
 f) Least privilege: Every program and every user of the system should
 operate using the least set of privileges necessary to complete the
 job. Primarily, this principle limits the damage that can result from
 an accident or error. It also reduces the number of potential
 interactions among privileged programs to the minimum for correct
 operation, so that unintentional, unwanted, or improper uses of
 privilege are less likely to occur. Thus, if a question arises related
 to misuse of a privilege, the number of programs that must be audited
 is minimized. Put another way, if a mechanism can provide firewalls,
 the principle of least privilege provides a rationale for where to
 install the firewalls. The military security rule of need-to-know is
 an example of this principle.

 Statement 2. David Gelernter's Manifesto:
 28. Metaphors have a profound effect on computing: the file-cabinet
 metaphor traps us in a passive instead of active view of
 information management that is fundamentally wrong for computers.

 29. The rigid file and directory system you are stuck with on your Mac
 or PC was designed by programmers for programmers — and is still a
 

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Andy Steingruebl
On Tue, Nov 25, 2008 at 9:48 AM, Gunnar Peterson [EMAIL PROTECTED]wrote:


 but actually the main point of my post and the one i would like to
 hear people's thoughts on - is to say that attempting to apply
 principle of least privilege in the real world often leads to drilling
 dry wells. i am not blaming any group in particular i am saying i
 think it is in the too hard pile for now and we as software security
 people should not be advocating for it until or unless we can find
 cost effective ways to implement it.


I'd love to hear someone from Microsoft talk about the creation of default
ready for shipping service security profiles for Server-2008.   Windows has
lots of services and lots of privileges that can be configured.

Every paper I've generally seen on the subject is about reverse engineering
least privileges by reducing them, checking whether the software still
functions, looking for access violations, and then increasing the privileges
until things start working.  A lot like this Calvin and Hobbes comic:

CALVIN: How do they know the load limit on bridges, Dad?
DAD: They drive bigger and bigger trucks over the bridge until it breaks.
Then they weigh the last truck and rebuild the bridge.

This is what we do with least privilege, but without ever knowing whether
we've really gotten the least privileges, or not.  Hell, in a modern
operating system how the hell do you figure this out anyway?

- 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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-25 Thread Shea, Brian A
Security is a tradeoff game between risk and cost in my experience.  So
the least privilege question comes down to practical matters like
knowing the execution environment, knowing the requirements of the tasks
being executed, and knowing where those intersect with the ability of
the user or application security context to provide or request those
rights.

If I'm executing with high privilege on only one box vs being run on
1 am I providing least privilege?
If I am running at scale with limited rights covering all use cases vs
with minimum rights and require user prompts or action to gain elevation
when a rare use case requires it am I least privilege?

The answer in my experience has not been a black and white, binary
decision, but rather a trade off where the risk to the environment /
data is evaluated against the cost to provide higher security, or the
cost of added user interaction / inconvenience.

In this way the definition of least privilege is comparable to one a
judge once gave for pornography; I'll know it when I see it.  Put a
different way, least privilege can ONLY be applied when you know all of
the details of a specific instance of a system, and not across all
instances of a system.  Sort of like the Heisenberg Uncertainly
Principle for Computer Security.

I can either know exactly what least privilege is for a specific
system/use case or I can talk about least privilege abstractly about
all systems, but not both with appreciable accuracy.

Re: devs vs CTOs vs Program / project managers
The power is shared across these areas, and sometimes poorly.  The dev
can't be solely responsible since they would need a very complete
requirement set to hold that bag, yet we rarely get those requirements
in the degree of detail we'd need.  However the dev SHOULD also know
about common security issues and techniques, and ensure they avoid them,
even if it means pushing back on some requirements to achieve the
security needed or if they are not specified in the requirements.  The
QA / Testing team should be able to test for requirements and security
issues enough to verify that the target state for functionality and
security are both met to acceptable levels.  Application security is a
team sport.  If we try to pin the responsibility on any one group or
person we leave out aspects that they don't typically control (some
small apps or process might be exceptions, but large apps I'd guess this
to be true).


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gunnar Peterson
Sent: Tuesday, November 25, 2008 9:49 AM
To: Stephen Craig Evans
Cc: Secure Mailing List
Subject: Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework
Security

look, i am a consultant. i work in lots of different companies. lots  
of different projects. i don't see these distinctions in black and  
white. sometimes the cto and managers are best positioned to help  
companies develop more secure software, sometimes architects,  
sometimes auditors, and many many times in my experience developers  
are best positioned.

but i really, truly do not care who does it. my only goal is more  
effective security mechanisms and some pragmatic roadmap to get there.  
we are in the infancy of this industry (think automotive safety circa  
1942, all seat belts and brakes), we are in no position to turn away  
help from anyone who can help. every company and every project is  
different, if your organization is set up so that developers are not  
empowered, but managers and CTOs are then by all means work with them.

but actually the main point of my post and the one i would like to  
hear people's thoughts on - is to say that attempting to apply  
principle of least privilege in the real world often leads to drilling  
dry wells. i am not blaming any group in particular i am saying i  
think it is in the too hard pile for now and we as software security  
people should not be advocating for it until or unless we can find  
cost effective ways to implement it.

-gunnar

On Nov 25, 2008, at 11:28 AM, Stephen Craig Evans wrote:

 It's a real cop-out for you guys, as titans in the industry, to go
 after developers. I'm disappointed in both of you. And Gary, you said
 One of the main challenges is that developers have a hard time
 thinking about the principle of least privilege .

 Developers are NEVER asked to think about the principle of least
 privilege. Or your world of software security must be very very very
 different from mine (and I think my world at least equals   yours but
 by about 2 billion people more, which might be irrelevant now but a
 little more relevant in the future :-)

 With the greatest, deepest respect to both of you,
 Stephen

 On Wed, Nov 26, 2008 at 1:01 AM, Stephen Craig Evans
 [EMAIL PROTECTED] wrote:
 Gunnar,

 Developers have no power. You should be talking to the decision  
 makers.

 As an example, to instill the importance of software security, I talk
 to decision makers

Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-24 Thread Dinis Cruz
So does this mean that the NSA is recommending .NET applications to be
develop so that they can be executed in partially trusted environments?
(i.e. not in full trust?)

Last time I check just about everybody was developing Full Trust .NET
applications (did this change in the last year?)

Don't get me wrong, this is a great document if one is interested in writing
applications that use CAS (Code Access Security), I would love for this to
be widely used.

But all great recommendations, like for example:

... Recommendation: Only grant the File IO access permissions Read, Write,
or Append to code that is trusted not to allow unauthorized access to file
system resources.  Grant File IO access to the most restrictive set of files
and folders possible.  Do not grant File IO access to file system roots or
other broadly specified resources simply because they contain a few
scattered files of interest. ..., page 17

... Recommendation: In following with least privilege, grant the Data
Protection permission to the most restrictive set of permissions
possible, page 26

... Recommendation: The Socket Access permission should only be granted to
highly trusted code or code that originates from the local network
(evidenced by a strong name withservices, page 28

... Recommendation: The Allow Calls to Unmanaged Assemblies permission
should be granted only to code that is trusted to execute with the same
privileges as the user's account under which the code is running. ..., page
48

only mean anything on partially-trusted environment (i.e. non-full trust
applications).

Dinis Cruz


On Sat, Nov 22, 2008 at 10:24 PM, Romain Gaucher [EMAIL PROTECTED]wrote:

 All,
 The NSA has just unclassified a 300 pages document about .NET 2.0 security
 http://www.nsa.gov/snac/app/I731-008R-2006.pdf

 I think it can be interesting resource,

 --Romain

 Romain Gaucher
 Security Consultant
 Cigital, http://www.cigital.com
 Software Confidence. Achieved.



 ___
 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.
 ___

___
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.
___


Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-24 Thread Mike Lyman
Dinis Cruz wrote:
 Don't get me wrong, this is a great document if one is interested in
 writing applications that use CAS (Code Access Security), I would love
 for this to be widely used.

When we recommended recommending CAS during a review of the U.S. Defense
Information System Agency's new Application Security and Development
Security Technical Implementation Guide earlier this year we were met
with what amounted to blank stares. (At least it seemed like that since
it was a phone conference.) Some on the call understood it and agreed
with the recommendation but those hosting the call and doing the writing
didn't seem to grasp it. It may be a while before we see too many
adopting this or requiring it for a while.
-- 

Mike Lyman
[EMAIL PROTECTED]

___
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.
___


[SC-L] Unclassified NSA document on .NET 2.0 Framework Security

2008-11-22 Thread Romain Gaucher
All,
The NSA has just unclassified a 300 pages document about .NET 2.0 security 
http://www.nsa.gov/snac/app/I731-008R-2006.pdf

I think it can be interesting resource,

--Romain

Romain Gaucher
Security Consultant
Cigital, http://www.cigital.com
Software Confidence. Achieved.



___
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.
___