Secure Coding mailing list archives

Unclassified NSA document on .NET 2.0 Framework Security


From: Brian.A.Shea at bankofamerica.com (Shea, Brian A)
Date: Tue, 25 Nov 2008 11:07:07 -0800

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
10000 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: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] 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
<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.htm
l

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
)
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
)
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)
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)
as a free, non-commercial service to the software security community.
_______________________________________________


Current thread: