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