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: >>>> >>>> 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 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. >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. _______________________________________________
