Secure Coding mailing list archives

Previous By Date Next
Previous By Thread Next

Unclassified NSA document on .NET 2.0 Framework Security

From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 25 Nov 2008 12:24:22 -0600
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 <gunnar at arctecgroup.net 

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
<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
)
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.
_______________________________________________
Previous By Date Next
Previous By Thread Next

Current thread: