Unclassified NSA document on .NET 2.0 Framework Security

[dana at vulscan.com (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 <
stephencraig.evans at gmail.com> 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
>  <gunnar at arctecgroup.net> 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
> > > <gunnar at arctecgroup.net> 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" <mlyman-cissp at comcast.net> 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
> > > > > mlyman at west-point.org
> > > > >
> > > > > _______________________________________________
> > > > > Secure Coding mailing list (SC-L) SC-L at 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 <http://www.krvw.com/>
> > > > > )
> > > > > as a free, non-commercial service to the software security community.
> > > > > _______________________________________________
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Secure Coding mailing list (SC-L) SC-L at 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 <http://www.krvw.com/>
> > > > > )
> > > > > as a free, non-commercial service to the software security community.
> > > > > _______________________________________________
> > > >
> > > >
> > > > _______________________________________________
> > > > Secure Coding mailing list (SC-L) SC-L at 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 <http://www.krvw.com/>)
> > > > as a free, non-commercial service to the software security community.
> > > > _______________________________________________
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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<http://www.krvw.com/>
> )
> as a free, non-commercial service to the software security community.
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20081125/59cc4719/attachment-0001.html