[SC-L] MQ Series and Middleware security
As the saying goes, a Unix server goes down and you have a bad weekend. A Mainframe goes down and the earth stops rotating on its axis. To the latter point, MQ Series and other messaging systems that communicate with Mainframes and heritage(*) systems get next to no attention from the security community, however they are critical. Here is a chat with T. Rob Wyatt on that subject http://1raindrop.typepad.com/1_raindrop/2015/10/security-140-chat-with-t-rob-wyatt-on-mq-and-middleware-security.html -gunnar http://1raindrop.typepad.com @oneraindrop * Heritage is what most people call legacy, but legacy is pejorative and heritage more accurately reflects the role of the systems that basically runs many businesses ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Silver Bullet 111: Marcus Ranum
In case anyone needs a summer project, I wonder what percentage of issues discussed in the 111 shows are still issues today? -gunnar On Jul 7, 2015, at 11:45 AM, Kevin W. Wall kevin.w.w...@gmail.com wrote: Ah, I see...so the dirty trick is that you are finally doing reruns. Syndication can't be far behind. ;-) -kevin Sent from my Droid; please excuse typos. On Jul 7, 2015 12:07 PM, Gary McGraw g...@cigital.com wrote: hi sc-l, Silver Bullet episode 111 is a sneaky one based around a “dirty brilliant trick. The episode features Marcus Ranum, inventor of the proxy firewall and all around security guru. We talk about perimeter security, software security, security progress (or lack of such) and whether hackers are necessary for security. http://bit.ly/sb111-mjr (or for purists http://www.cigital.com/silver-bullet/show-111/) So what was the trick? At the end of the episode I revealed that during episode 3 (recorded exactly 9 years before episode 111), I asked Marcus exactly the same set of questions. Wonder how consistent Marcus is over nine years? Compare and contrast http://www.cigital.com/silver-bullet/show-003/ gem ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] SearchSecurity: 13 Design Principles for 2013
Good piece. Saltzer and Schroeder's work is the deus ex machina in so much of security. On the software side, esp in the case of Twitter, Facebook et al, the equivalent is David Gelernter. I did a mashup of these titans and I must say I think there is a fair(and increasing) amount of impedance mismatch. Meaning many of S S's fundamental assumptions do not apply in Gelernter's universe. For example how do I completely mediate in a federation? Answer: you dont you have partial control at best. http://1raindrop.typepad.com/1_raindrop/2008/06/mashup-of-the-titans.html Gunnar Sent from my mobile Original message From: Gary McGraw g...@cigital.com Date: To: Secure Code Mailing List SC-L@securecoding.org Cc: Parizo, Eric epar...@techtarget.com Subject: [SC-L] SearchSecurity: 13 Design Principles for 2013 hi sc-l, Merry new year to you all. About the hardest part of software security is design. Everything about it is hard: secure design, threat modeling, architectural risk analysis, etc. Even convincing slow pokes that there is a difference between bugs and flaws is hard (you should see the reviews my talk got from the expert RSA program committee this year…hah!). For many years I have struggled with how to teach people ARA and security design. The only technique that really works is apprenticeship. Short of that, a deep understanding of security design principles can help. in 1975 Salzer and Schroeder wrote one of the most important papers in computer security. In it, they introduced the concept of security principles. I riffed on that this month in my SearchSecurity column. Please read it and pass it on. Give a copy to all of the software architects you know. http://searchsecurity.techtarget.com/opinion/Thirteen-principles-to-ensure-enterprise-system-security gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] informIT: Modern Malware
Advanced = goes through firewall Persistent = tried more than once Threat = people trying to get into valuable stuff Nothing new to sc-l readers, but a Reasonably good marketing term esp by infosec standards (yay we get to scare business people with something other than an auditor's clipboard!); really its all just the collective sound of infrastructure security people coming to grips with the fact that their firewall isn't a wall at all, but rather a series of holes. -gunnar ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] Colin Angle interview
from interview with iRobot CEO and founder Colin Angle: Are you planning on developing apps for robots like Roomba and Scooba? The robot operating system architecture will divide in half. The mobile industry is moving far faster and is far larger than the robot industry. You’ve got a couple of wonderful front runners, Google and Apple, which have developed software platforms that are optimised around communication, voice recognition, graphics and touch screen interfaces. That’s enabling for the robot industry but it’s not sufficient. If your phone dies nothing that serious happens. But if you’re robot dies and it’s bigger than a Roomba, you don’t want it to topple down the stairs. There’s a need for reliable, safe, secure software at the core of the robot. But there will be a division between the core robot OS which is carefully designed and has fail safes and the cool, sexy UI for the consumer. Things like iPhone control first evolve in the informal hacking communities but over time the robots will have much more sophisticated operating systems and be able to link in to other systems. Ultimately though if the robot’s function is to be vacuum cleaner, it needs to do that well first. One day I see lots of robots managed by a butler robot. I talk to it and it talks to the other robots. At that point you’ll see a lot of human interaction features on the main robot. You could have Android OS running on part of that robot alongside a safe and secure robot OS. There’s a place for co-operation. http://m.wired.com/epicenter/2010/10/colin-angle-irobot-ceo/all/1 -gunnar ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Computerworld: Opinion - Making apps secure is hard work
Hi Ken, You raise some important points. Most infosec is approached as a set of controls, but access control only takes you so far in the face of malice. I like this quote from G.K. Chesterton The real trouble with this world of ours is not that it is an unreasonable world, nor even that it is a reasonable one. The commonest kind of trouble is that it is nearly reasonable, but not quite. Life is not an illogicality; yet it is a trap for logicians. It looks just a little more mathematical and regular than it is; its exactitude is obvious, but its inexactitude is hidden; its wildness lies in wait. Notice the distinction, the first part gets to why access control matters - we can use crypto and such to impose our policies on the logic that we know and understand, but it does not help us all with inexactitude. There's no margin of safety, the control either works or its doesn't. -gunnar On Aug 12, 2010, at 7:17 AM, Kenneth Van Wyk wrote: I figured this was relevant here, so here's a link to my August column for Computerworld. Excerpt: 'What's that you say? All the app vetting you've been doing to date consists only of verifying that the apps play by the rules? That is, that they use only published APIs and such? Well, then, you really have your work cut out for you, because that's not all that your customers expect.' To read the complete article see: http://www.computerworld.com/s/article/9180579/Making_apps_safe_is_hard_work?taxonomyId=17 Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com Follow us on Twitter at: http://twitter.com/KRvW_Associates ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___ ___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] Bring your Cloud to Work Day
Flip side of Lifestyle Hacking aptly described by Messrs McGraw and Routh is when your organization cannot deliver the functionality/data/ usability that the consumers need. http://1raindrop.typepad.com/1_raindrop/2010/03/bring-your-cloud-to-work-in-iraq.html -gunnar ___ 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. ___
[SC-L] Genotypes and Phenotypes
Its been awhile since there was a bugs vs flaws debate, so here is a snippet from Jaron Lanier Q: What's wrong with the way we create software today? A: I think the whole way we write and think about software is wrong. If you look at how things work right now, it's strange -- nobody -- and I mean nobody -- can really create big programs in a reliable way. If we don't find a different way of thinking about and creating software, we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become. [After publication of this interview, Jaron Lanier realized that his sentence should read: bigger than about 20 to 30 million lines of code] This current lack of scalability is a universal burden. There are monopolies in our industry because it's so difficult for anyone to even enter the competition; it's so hard to write large software applications. And that's strange to me. If you look at other things that people build, like oil refineries, or commercial aircraft, we can deal with complexity much more effectively than we can with software. The problem with software is that we've never learned how to control the side effects of choices, which we call bugs. We shouldn't be complacent about that. I still believe that there are ideas waiting to be created, and that someday we will have new ways of writing software that will overcome these problems. And that's my principal professional interest. I want to make a contribution to making bugs go away. Q:Aren't bugs just a limitation of human minds? A: No, no, they're not. What's the difference between a bug and a variation or an imperfection? If you think about it, if you make a small change to a program, it can result in an enormous change in what the program does. If nature worked that way, the universe would crash all the time. Certainly there wouldn't be any evolution or life. There's something about the way complexity builds up in nature so that if you have a small change, it results in sufficiently small results; it's possible to have incremental evolution. Right now, we have a little bit -- not total -- but a little bit of linearity in the connection between genotype and phenotype, if you want to speak in those terms. But in software, there's a chaotic relationship between the source code (the genotype) and the observed effects of programs -- what you might call the phenotype of a program. And that chaos is really what gets us. I don't know if I'll ever have a good idea about how to fix that. I'm working on some things, but you know, what most concerns me is what amounts to a lack of faith among programmers that the problem can even be addressed. There's been a sort of slumping into complacency over the last couple of decades. More and more, as new generations of programmers come up, there's an acceptance that this is the way things are and will always be. Perhaps that's true. Perhaps there's no avoiding it, but that's not a given. To me, this complacency about bugs is a dark cloud over all programming work. -gunnar ___ 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. ___
Re: [SC-L] Provably correct microkernel (seL4)
design flaws. So we have only removed 50% of the problem. for my part there have been many, many days when I would settle for solving 50% of a problem -gunnar ___ 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. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
I think we need to start indoctrinating kids in the womb. Start selling Baby Schneier CDs alongside Baby Mozart. :) I can recommend this book, it was given to me by a client. Enigma: A Magical Mystery Grade 3–6—Someone has stolen the props belonging to the residents of a retirement home for magicians, and Bertie Badger, the grandson of one of the illusionists, vows to find them. As he meets the performers, they each tell him a little about their specialty and what's missing. My top hat, cape, and wand have gone, but there is worse to tell:/My precious magic bunny rabbit's disappeared as well! Bertie discovers the thief, but it is left to readers to find the lost items hidden in the illustrations. Base's visual mystery books have delighted children for years, but this one has the added feature of a moving panel in the back cover that reveals a secret code. Children must turn dials to proper settings before it can be moved. The clues for setting them appear in the illustrations but are not at all obvious. With a little persistence, however, the target audience should be able to solve the puzzle. After readers crack the code, they can search for the missing items hidden in the art and decipher other messages found in the end matter. http://www.amazon.com/Enigma-Magical-Mystery-Graeme-Base/dp/081097245X -gunnar ___ 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. ___
Re: [SC-L] Silver Bullet 40: Bob Blakley
+1 great interview -gunnar On Jul 17, 2009, at 11:25 AM, Gary McGraw wrote: hi sc-l, One of our sc-l listeners (gunnar) suggested Bob Blakley as an interview target. Bob is a particularly interesting guy because he both a well-respected scientist very active in the security research community and a real practitioner who among other things designed the CORBA security model. These days, Bob is an analyst for the Burton Group. http://www.cigital.com/silverbullet/show-040/ Thanks to Gunnar for the suggestion. As always, your feedback on the podcast is welcome. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___
Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
Two areas that don't seem to immediately lend themselves to design/ spec level solutions are (1) transitive trust and (2) interaction errors between multiple components that are all working correctly. I'd love to hear from people who've had to solve these problems in the real world. Based on what I see in CVE, it seems that the answer for item 2 is usually for one component to choose to conform to another's expectations, and that conforming component isn't always the one that should be changed. Those are both definitely apparent at design time. Paraphrasing Bob Blakley, applications are built on composition, but most security protocols are point to point and don't compose. So anyone who bothers to look at the end to end application will see massive gaps in the security protocols. The fix is likely a decision between a sts/federation/proxy pattern, and a way to link policy to mechanism. WS-SecurityPolicy provides one such way to do specify the policy side. -gunnar ___ 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. ___
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
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,
Re: [SC-L] Unclassified NSA document on .NET 2.0 Framework Security
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
Re: [SC-L] Cat out of the bag?
http://validator.w3.org shows that page has 25 HTML errors. fwiw, mac.com has 28 errors and 1 warning -gunnar p.s. my domain has 42 otoh i wrote the whole design from scratch in vi ___ 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. ___
Re: [SC-L] Silver Bullet
I strongly agree with James' ask. Its nice to hear from gurus, but we need to hear about real world tradeoffs too. Sausage making aint pretty (ask Hank and Ben), but its the real world and I for one am always fascinated with what choices organizations make and why. I am also very excited to hear from Matt Bishop who is at or near the top of the guru heap for my money. Keep up the good work -gp Gary McGraw wrote: Good idea James. If you take a look at the list of victims, you'll see a mix of academics, gurus, and CSOs. My next victim (Matt Bishop) is already slated. After that I will see what I can do to get a CIO for November. BTW, if anyone has suggestions along those lines, I'm all ears. I would particularly like to get more women on the podcast. gem On 9/29/08 10:09 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Wouldn't it be interesting if upcoming Silver Bullets featured CIOs and Enterprise Architects of Fortune enterprises? The perspectives regarding secure coding are complimentary yet different... * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___
[SC-L] Building Secure Web Applications Training in Minneapolis
Ken van Wyk and I are teaching Building Secure Web Applications in Java/J2EE in Minneapolis, September 30 - October 2. The summary is below, if you would like more info please let me know. More details to follow. Building Secure Web Applications in Java/J2EE Course Description This course teaches the students how to develop secure applications from the web front end through the middle tier and data and integration layers for today’s complex internetworked environment. Students will receive a deep and thorough understanding of the most prevalent and dangerous security defects in today’s applications, and what to do about them. Additionally, they will learn practical and actionable guidelines on how to remediate against these common defects in Java/J2EE and Web Services frameworks and how to test for them in their own applications. This class starts with a description of the security problems faced by today's software developer, as well as a detailed description of the Open Web Application Security Project’s (OWASP) “Top 10” security defects. These defects are studied in instructor-lead sessions as well as in hands-on lab exercises in which each student learns how to actually exploit the defects to “break into” a real web application. (The labs are performed in safe test environments.) Remediation techniques and strategies are then studied for each defect. Practical guidelines on how to integrate secure development practices into the software development process are then presented and discussed. Bring the concepts and hands on learning together, the class uses a case study to show how to design and architect security services for a real world application. Intended Audience The ideal student for this tutorial is a hands-on web application developer or architect who is looking for a fundamental understanding of today's best practices in secure software development. ___ 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. ___
Re: [SC-L] No general-purpose computer, or everything under surveillance?
But the difference is who is in final control. In the end, the users of computers should be in final control, not their makers, or we have given up essential liberty. We can develop systems which provide suites of more specialized privileges to particular functions, without giving up essential liberty. We have a long way to go in actually DOING this, but the opportunity is there. I believe the point of Dan Geer's paper is not that these are desired outcomes so much as realistic outcomes. If you cannot provide effective security (and we're not) and people are relying more and more on computers for real world things (and they are), then someone else (who is not a geek) is going to come in and more or less arbitrarily assign risk and responsibility to parties. For example (quoting Dan Geer's paper): We've done this before—Regulation Z of the Truth in Lending Act of 1968 says that the most a consumer can lose from misuse of a credit card is $50. The consumer can be an idiot, but can't lose more than $50. Consumers are, in fact, not encouraged to self-protect by such a limit—quite the opposite (and $50 in 1968 would be $275 today). No, if there is to be a preemption, the intelligence it requires will be based on a duty of surveillance that is assigned to various “deep pockets.” The countermeasures, in other words, are not risk-sensitive to where the risk naturally lies but risk-sensitive to where it is assigned. Look out side effects, here we come. Something like Regulation Z may not come to pass in information security, but if I were a betting man, I think its a more likely outcome in the real world than a combination of principle of least privilege + perfect code + 4 billion highly trained users; none of which I have seen. -gp ___ 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. ___
Re: [SC-L] Microsoft's message at RSA
Hi Andy, Great post. I especially like the part about making choices. Having users type passwords into websites that protect all their assets pretty clearly isn't working. Cardspace is pretty clearly a massive improvement. That said, I don't think the choice is between perfect liberty and perfect security, but more what Dan Geer suggested: We digerati have given the world fast, free, open transmission to anyone from anyone, and we've handed them a general-purpose device with so many layers of complexity that there is no one who understands it all. Because “you're on your own” won't fly politically, something has to change. Since you don't have to block transmission in order to surveil it, and since general-purpose capabilities in computers are lost on the vast majority of those who use them, the beneficiaries of protection will likely consider surveillance and appliances to be an improvement over risk and complexity. From where they sit, this is true and normal. While the readers of Queue may well appreciate that driving is much more real with a centrifugal advance and a stick shift, try and sell that to the mass market. The general-purpose computer must die or we must put everything under surveillance. Either option is ugly, but “all of the above” would be lights-out for people like me, people like you, people like us. We're playing for keeps now. http://www.acmqueue.org/modules.php?name=Contentpa=showpagepid=436 I hope that cheers everyone up. -gp Andy Steingruebl wrote: On Fri, May 9, 2008 at 3:42 PM, Gary McGraw [EMAIL PROTECTED] wrote: Hi andy (and everybody), Indeed. I vote for personal computer liberty over guaranteed iron clad security any day. For amusing and shocking rants on this subject google up some classic Ross Anderson. Or heck, I'll do it for you: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html I've heard this point for years, and yet when we actually look at ways of solving the consistent problems of software security, we always come back to tamper-proof/restricted-rights as a pretty reasonable starting point. I don't know whether this mailing list is really the place for me to advocate about this, but every time we get into a situation where we talk about high reliability (electronic voting for example) people are all up in arms that we haven't followed pretty strict practices to make sure the machines don't get hacked, aren't hackable by even experts, etc. hardened hardware, trusted computing bases, etc. But, if you want to try and apply the same engineering principles to protecting an individual's assets such as their home computer, bank account credentials, etc. then you're trampling on their freedom. I don't really see how we can viably have both. Sure we're looking at all sorts of things like sandboxing and whatnot, but given multi-purpose computing and the conflicting goals of absolute freedom and defense against highly motivated attackers, we're going to have to make some choices aren't we? I don't disagree that all of these technologies can be misused. Most can. We've all read the Risks columns for years about ways to screw things up. At the same time individual computers don't exist in isolation. They are generally part of an ecosystem (the internet) and as such your polluting car causes my acid rain and lung cancer. Strict liability isn't the right solution to this sort of public policy problem, regulation is. That regulation and control can take many forms, some good, some bad. I don't see the problem getting fixed though without some substantial reworking of the ecosystem. Some degree of freedom may well be a casualty. Please don't think I'm actually supporting the general decrease in liberty overall. At the same time I'm pretty sure that traffic laws are a good idea, speed limits are a good idea, even though they restrict individual freedoms.In the computing space I'm ok allowing people to opt-out but only if in doing to they don't pose a manifest danger to others. Balancing the freedom vs. the restriction isn't easy of course, and I'm not suggesting it is. I'm merely suggesting that all of the research we've ever done in the area doesn't point to our current model (relying on users to make choices about what software to use) promising. How to make this happen without it turning into a debacle is of course the tricky part. ___ 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. ___
Re: [SC-L] Microsoft's message at RSA
Hi Gary, I think they are doing it, Cardspace is the key enabling technology to making it happen. Given how many enterprises are federation-enabled (and how simply the rest can be), the biggest missing piece right now is that we need an Identity Provider for the Internets. Of course this only helps to solve the access control problem, not the defensive programming problem, you can still shoot yourself in the foot with SAML and WS-* (Brian Chess and I gave a talk on this at RSA). But at least it will be nice to have the banks and brokerage houses stop having people type their username and passwords into web browsers, and then blaming the consumer when things go amiss. -gp Gary McGraw wrote: hi sc-l, Here's an article about Mundie's keynote at RSA. It's worth a read from a software security perspective. Somehow I ended up playing the foil in this article...go figure. http://reddevnews.com/features/article.aspx?editorialsid=2470 So what do you guys think? Is this end-to-end trusted computing stuff going to fly with developers? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___
Re: [SC-L] quick question - SXSW
I agree this is a big issue, there is no cotton picking way that the security people are solving these problems, it has to come from the developers. I put together a track for QCon which included Brian Chess on Static Analysis, John Steven on Threat Modeling, and Jeff Williams on ESAPI and Web 2.0 security. The presentations were great, the audience was engaged and enthusiastic but small; it turns that it is hard to compete with the likes of Martin Fowler, Joshua Bloch, and Richard Gabriel. Even when what they are talking about is some nth level refinement and what we are talking about is all the gaping holes in the previous a-m refinements and how to close some of them. http://jaoo.dk/sanfrancisco/tracks/show_track.jsp?trackOID=73 -gp Kenneth Van Wyk wrote: Ben, Your point is a good one -- the software security community needs to be vigilant in reaching out to developers and spreading the word. FWIW, some dev conferences have done this. I spoke at SD West in 2006, and there was a significant security track there. Still, it'd be great to see that sort of thing at more dev-specific conferences. Cheers, Ken van Wyk SC-L Moderator On Mar 12, 2008, at 5:31 PM, Benjamin Tomhave wrote: First, thanks for that Bill, it exemplifies my point perfectly. A couple thoughts... one, targeting designers is just as important as reaching out to the developers themselves... if the designers can ensure that security requirements are incorporated from the outset, then we receive an added benefit... two, a re-phrasing around my original thought... somehow we need to get security thinking and considerations encoded into the DNA of everyone in the business, whether they be designers, architects, coders, analysts, PMs, sysadmins, etc, etc, etc. Every one of those topics you mention could (should!) have had implicit and explicit security attributes included... yet we're still at the point where secure coding has to be explicitly requested/demanded (often as an afterthought or bolt-on)... How do we as infosec professionals get people to the next phase of including security thoughts in everything they do... with the end-goal being that it is then integrated fully into practices and processes as a bona fide genetic mutation that is passed along to future generations? To me, this seems to be where infosec is stuck as an industry. There seems to be a need for a catalyst to spur the mutation so that it can have a life of its own. :) fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Augustine's Second Law of Socioscience: For every scientific (or engineering) action, there is an equal and opposite social reaction. http://globalnerdy.com/2007/07/18/laws-of-software-development/ William L. Anderson wrote: Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I did not see many discussions that pay attention to security, or any other software engineering oriented concerns, explicitly. There was a discussion of scalability for web services that featured the developers from digg, Flickr, WordPress, and Media Temple. I got there about half-way through but the discussion with the audience was about tools and methods to handle high traffic loads. There was a question about build and deployment strategies and I asked about unit testing (mixed answers - some love it, some think it's strong-arm micro-mgt (go figure)). There was a session on OpenID and OAuth (open authorization) standards and implementation. These discussions kind of assume the use of secure transports but since I couldn't stay the whole time I don't know if secure coding was addressed explicitly. The main developer attendees at SXSW would call themselves designers and I would guess many of them are doing web development in PHP, Ruby, etc. I think the majority of attendees would not classify themselves as software programmers. To me it seems very much like at craft culture. That doesn't mean that a track on how to develop secure web services wouldn't be popular. In fact it might be worth proposing one for next year. If you want to talk further, please get in touch. -Bill Anderson praxis101.com Benjamin Tomhave wrote: I had just a quick query for everyone out there, with an attached thought. How many security and/or secure coding professionals are prevalently involved with the SXSW conference this week? I know, I know... it's a big party for developers - particularly the Web 2.0 clique - but I'm just curious. Here's why: I'm increasingly frustrated by the disconnect between business/dev and security. I don't feel like we're being largely successful in getting the business and developers to include security as part of their standard operating
Re: [SC-L] Darkreading: Getting Started
Another approach is decentralized specialized teams, centers of excellence in current managementspeak, with a specific agenda and expertise on an area deemed strategic. This approach is probably best paired with 2,3, or 4 from your list. For example, a roving specialized threat modeling team that works with many groups to help develop threat models, attack patterns, tests, and so on. Or a roving team that focuses on build secure web apps and cuts across groups for specialized tasks for secure web app dev, say how do I use cardspace in my web app? Once you figure out what your strategic goals are for security - threat modeling, cardspace, static analysis, secure web app deve, etc. You can use #2 to focus them on the right stuff, or use #3 as roving advisers (like the cia in the cold war), or in #4 arm them with a tool or technology like XML Security gateway or static analysis tools to make a small band more effective in a large organization. -gp On 1/9/08 6:48 PM, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, One of the biggest hurdles facing software security is the problem of how to get started, especially when faced with an enterprise-level challenge. My first darkreading column for 2008 is about how to get started in software security. In the article, I describe four approaches: 1. the top-down framework; 2. portfolio risk; 3. training first; and 4. leading with a tool. We've tried them all with some success at different Cigital customers. Are there other ways to get started that have worked for you? By the way, I can use your help. Darkreading is beginning to track reaction to topics more carefully than in the past. You can help make software security more prominent by reading the article and passing the URL on to others you may find interested. Another thing that helps is posting to the message boards. Thanks in advance. Here's to even more widespread software security in 2008! gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___
Re: [SC-L] OWASP Publicity
Local boy makes good http://online.wsj.com/article/0,,SB112128453130584810,00-search.html -gp On 11/15/07 10:25 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I have observed an interesting behavior in that the vast majority of IT executives still haven't heard about the principles behind secure coding. My take says that we are publishing information in all the wrong places. IT executives don't really read ACM, IEEE or other the sporadic posting from bloggers but they do read CIO, Wall Street Journal and most importantly listen to each other. What do folks on this list think about asking the magazines and newspapers to publish? I am willing to gather contact information of news reporters and others within the media if others are willing to amplify the call to action in terms of contacting them. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___
Re: [SC-L] IT industry creates secure coding advocacy group
Hi Ken, I thought the driving force was your book, after all they named their initiative after it. Anyhow, I'll reiterate here what I blogged: It would be very interesting to see an equivalent initiative from the customer side (who are the lucky recipients who have to pay for all the security vulns created by the above). I know as a consultant there are many large companies struggling with similar secure coding issues exacerbated by outsourcing to some degree, and a lot could be gained by a shared effort. The analyst community like the vendors has more or less Fortune 500s out in the dark, so this may be an area where a half dozen or so motivated security architects and CISOs at Fortune 500s could band together to create a group to help drive change. None of the other big players (analysts, vendors, big consulting firms) seem to be doing it. Why not bootstrap a Fortune 500 Secure Coding Initiative to drive better products, services and share best practices in the software security space? -gp On 10/23/07 1:55 PM, Kenneth Van Wyk [EMAIL PROTECTED] wrote: Saw this story via Gunnar's blog (thanks!): http://www.gcn.com/online/vol1_no1/45286-1.html Any thoughts on new group, which is calling itself SAFEcode? Anyone here involved in its formation and care to share with us what's the driving force behind it? Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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. ___ On 10/23/07 1:55 PM, Kenneth Van Wyk [EMAIL PROTECTED] wrote: Saw this story via Gunnar's blog (thanks!): http://www.gcn.com/online/vol1_no1/45286-1.html Any thoughts on new group, which is calling itself SAFEcode? Anyone here involved in its formation and care to share with us what's the driving force behind it? Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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. ___ -- Gunnar Peterson, Managing Principal, Arctec Group http://www.arctecgroup.net Blog: http://1raindrop.typepad.com ___ 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. ___
Re: [SC-L] Microsoft Pushes Secure, Quality Code
That said, we should keep trying! I believe one answer is to take advantage of relative metrics over time. I agree that this can be a practical starting point for organizations. I had a client starting down the path with static analysis, they have thousands of developers and many applications. They have a small software security team and they obviously cannot scan every single app. Worse, if they find something they don't necessarily have the governance in place to make sure that a lot of what they find gets addressed. So what we did was to get the CIO to give them one silver bullet a month. They scanned 8-10 apps per month, and whichever one came up worst based on the metrics in the group had to remediate. This approach has some incremental benefits - 1) it gets security out of the its perfect or its broken business 2) at least one project per month makes measurable improvements 3) the projects are not being compared to an ivory tower but rather to their peers who have to deliver under the same constraints, making the suggested remediations more palatable to the developers. There is no way to relativity, relativity is the way. -gp ___ 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. ___
[SC-L] Metricon 2.0
SC-Lers, There are several presentations at Metricon by or of interest to SC-L denizens. -gp The agenda for Metricon 2.0 in Boston August 7th has been set. Metricon is co-located with Usenix security conference. The details, travel info, registration, and agenda are here: https://www.securitymetrics.org/content/Wiki.jsp?page=Metricon2.0 There are a limited number of openings so please REGISTER SOON if interested in attending. A summary of the presentations Keynote Debate: ³Do Metrics Matter?² Andrew Jaquith (Yankee Group) Mike Rothman (SecurityIncite) Security Meta Metrics--Measuring Agility, Learning, and Unintended Consequence Russell Cameron Thomas (Meritology) Security Metrics in Practice: Development of a Security Metric System to Rate Enterprise Software Fredrick DeQuan Lee and Brian Chess (Fortify) A Software Security Risk Classification System Eric Dalci and Robert Hines (Cigital) Web Application Security Metrics Jeremiah Grossman (WhiteHat Security) Operational Security Risk Metrics: Definitions, Calculations, and Visualizations, Brian Laing, Mike Lloyd, and Alain Mayer (Redseal Systems) Metrics for Network Security Using Attack Graphs: A Position Paper, Anoop Singhal (NIST), Lingyu Wang and Sushil Jaodia (Center for Secure Information Systems, George Mason University) Software Security Weakness Scoring Chris Wysopal (Veracode) Developing secure applications with metrics in mind Thomas Heyman Christophe Huygens, and Wouter Joosen (K.U.Leuven) Correlating Automated Static Analysis Alert Density to Reported Vulnerabilities in Sendmail Michael Gegick and Laurie Williams (North Carolina State University) Practitioner Panel moderated by Becky Bace: Three practitioners from thought leading companies describe how they use metrics to make better decisions. If you know others that would be interested this collaborative workshop, please forward them this email and let them know about this opportunity. Please contact us with any questions. Thanks, Betsy Nichols and Gunnar Peterson Metricon 2.0 Co-Chairs ___ 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. ___
Re: [SC-L] MetriCon 2.0 CFP
Book is here Security Metrics: Replacing Fear, Uncertainty, and Doubt by Andrew Jaquith http://www.amazon.com/Security-Metrics-Replacing-Uncertainty-Doubt/dp/032134 9989 I am halfway through and it is excellent so far, will post a review soon. Not sure how the security industry as we know it will get by without fud. -gp On 4/24/07 7:32 PM, Gary McGraw [EMAIL PROTECTED] wrote: Plus, check out Andrew Jaquith's excellent book: -Original Message- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Tue Apr 24 20:14:53 2007 To: Secure Mailing List Subject: [SC-L] MetriCon 2.0 CFP Last year's conference, MetriCon 1.0 featured a software security metrics track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0), including: * A Metric for Evaluating Static Analysis Tools - Chess Tsipenyuk, Fortify * An Attack Surface Metric - Manadhata Wing, Carnegie-Mellon * Good enough Metrics - Epstein, WebMethods * Software Security Patterns and Risk - Heyman Huygens, U of Leuven * Code Metrics - Chandra, Secure Software -gp Second Workshop on Security Metrics (MetriCon 2.0) Call for Papers MetriCon 2.0 CFP August 7, 2007 Boston, MA Overview Do you cringe at the subjectivity applied to security in every manner? If so, MetriCon 2.0 may be your antidote to change security from an artistic matter of opinion into an objective, quantifiable science. The time for adjectives and adverbs has gone; the time for hard facts and data has come. MetriCon 2.0 is intended as a forum for lively, practical discussion in the area of security metrics. It is a forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop. MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located with the 16th USENIX Security Symposium in Boston, MA, USA (http://www.usenix.org/events/sec07/). Beginning first thing in the morning, with meals taken in the meeting room, and extending into the evening. Attendance will be by invitation and limited to 60 participants. All participants will be expected to come with findings and be willing to address the group in some fashion, formally or not. Preference given to the authors of position papers/presentations who have actual work in progress. Each presenter will have 10-15 minutes to present his or her idea, followed by 15-20 minutes of discussion with the workshop participants. Panels and groups of related presentations may be proposed to present different approaches to selected topics, and will be steered by what sorts of proposals come in response to this Call. Goals and Topics The goal of the workshop is to stimulate discussion of and thinking about security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all. Such position papers are expected to address security metrics in one of the following categories: Benchmarking Empirical Studies Metrics Definitions Financial Planning Security/Risk Modeling Tools, Technologies, Tips, and Tricks Visualization Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas. How to Participate Submit a short position paper or description of work done/ongoing. Your submission must be no longer than five(5) paragraphs or presentation slides. Author names and affiliations should appear first in/on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to MetriCon AT securitymetrics.org. Presenters will be notified of acceptance by June 22, 2007 and expected to provide materials for distribution by July 22, 2007. All slides and position papers will be made available to participants at the workshop. No formal proceedings are intended. Plagiarism constitutes dishonesty. The organizers of this Workshop as well as USENIX prohibit these practices and will take appropriate action if dishonesty of this sort is found. Submission of recent, previously published work as well as simultaneous submissions to multiple venues is acceptable but please so indicate in your proposal. Location MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium (Security ¹07). (http://www.usenix.org/events/sec07/) Cost $200 all-inclusive of meeting space, materials preparation, and meals for the day. Important Dates Requests to participate: by May 11, 2007 Notification of acceptance: by June 22, 2007 Materials for distribution: by July 22, 2007 Workshop Organizers Fred Cohen, Fred Cohen Associates Jeremy Epstein, webMethods Dan Geer, Geer Risk Services Andrew Jaquith, Yankee Group Elizabeth Nichols, ClearPoint
[SC-L] MetriCon 2.0 CFP
Last year's conference, MetriCon 1.0 featured a software security metrics track ( http://securitymetrics.org/content/Wiki.jsp?page=Metricon1.0), including: * A Metric for Evaluating Static Analysis Tools - Chess Tsipenyuk, Fortify * An Attack Surface Metric - Manadhata Wing, Carnegie-Mellon * Good enough Metrics - Epstein, WebMethods * Software Security Patterns and Risk - Heyman Huygens, U of Leuven * Code Metrics - Chandra, Secure Software -gp Second Workshop on Security Metrics (MetriCon 2.0) Call for Papers MetriCon 2.0 CFP August 7, 2007 Boston, MA Overview Do you cringe at the subjectivity applied to security in every manner? If so, MetriCon 2.0 may be your antidote to change security from an artistic matter of opinion into an objective, quantifiable science. The time for adjectives and adverbs has gone; the time for hard facts and data has come. MetriCon 2.0 is intended as a forum for lively, practical discussion in the area of security metrics. It is a forum for quantifiable approaches and results to problems afflicting information security today, with a bias towards practical, specific implementations. Topics and presentations will be selected for their potential to stimulate discussion in the Workshop. MetriCon 2.0 will be a one-day event, Tuesday, August 7, 2007, co-located with the 16th USENIX Security Symposium in Boston, MA, USA (http://www.usenix.org/events/sec07/). Beginning first thing in the morning, with meals taken in the meeting room, and extending into the evening. Attendance will be by invitation and limited to 60 participants. All participants will be expected to come with findings and be willing to address the group in some fashion, formally or not. Preference given to the authors of position papers/presentations who have actual work in progress. Each presenter will have 10-15 minutes to present his or her idea, followed by 15-20 minutes of discussion with the workshop participants. Panels and groups of related presentations may be proposed to present different approaches to selected topics, and will be steered by what sorts of proposals come in response to this Call. Goals and Topics The goal of the workshop is to stimulate discussion of and thinking about security metrics and to do so in ways that lead to realistic, early results of lasting value. Potential attendees are invited to submit position papers to be shared with all. Such position papers are expected to address security metrics in one of the following categories: Benchmarking Empirical Studies Metrics Definitions Financial Planning Security/Risk Modeling Tools, Technologies, Tips, and Tricks Visualization Practical implementations, real world case studies, and detailed models will be preferred over broader models or general ideas. How to Participate Submit a short position paper or description of work done/ongoing. Your submission must be no longer than five(5) paragraphs or presentation slides. Author names and affiliations should appear first in/on the submission. Submissions may be in PDF, PowerPoint, HTML, or plaintext email and must be submitted to MetriCon AT securitymetrics.org. Presenters will be notified of acceptance by June 22, 2007 and expected to provide materials for distribution by July 22, 2007. All slides and position papers will be made available to participants at the workshop. No formal proceedings are intended. Plagiarism constitutes dishonesty. The organizers of this Workshop as well as USENIX prohibit these practices and will take appropriate action if dishonesty of this sort is found. Submission of recent, previously published work as well as simultaneous submissions to multiple venues is acceptable but please so indicate in your proposal. Location MetriCon 2.0 will be co-located with the 16th USENIX Security Symposium (Security ¹07). (http://www.usenix.org/events/sec07/) Cost $200 all-inclusive of meeting space, materials preparation, and meals for the day. Important Dates Requests to participate: by May 11, 2007 Notification of acceptance: by June 22, 2007 Materials for distribution: by July 22, 2007 Workshop Organizers Fred Cohen, Fred Cohen Associates Jeremy Epstein, webMethods Dan Geer, Geer Risk Services Andrew Jaquith, Yankee Group Elizabeth Nichols, ClearPoint Metrics, Co-Chair Gunnar Peterson, Arctec Group, Co-Chair Russell Cameron Thomas, Meritology ___ 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. ___
Re: [SC-L] Economics of Software Vulnerabilities
Just because people can look at a project in detail, doesn't mean they will. More to the point, just because people can, doesn't mean code auditing gurus will look at it. And sometimes, when they do look they get booted out of the project http://www.heise-security.co.uk/news/82500 -gp ___ 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. ___
Re: [SC-L] How is secure coding sold within enterprises?
JD Meier had a good post recently on influencing without authority, which is the position security finds itself in: 1. assume all potential allies 2. clarify goals and priorities 3. diagnose the allies world 4. identify relevant currencies 5. deal with relationships 6. influence through give and take http://blogs.msdn.com/jmeier/archive/2007/03/09/influencing-without-authority.aspx how does this translate to app security? well i think it means find stakeholders/allies wherever you can. any group that is interested try to 1) educate them about software risks and software security and 2) give them tools/process they can bring to bear on the problem. specifically, legal teams are generally very interested in risks, so i have seen several legal teams at very large companies deploy parts of the OWASP legal project to good effect. business analysts can be trained on how specify some security concerns in use cases/user stories. qa teams can be educated on security specific testing tools and techniques, architects can learn how to design reusable security services, and so on. so whatever group that seems eager to get involved it makes sense to engage, once security concerns are embedded in test plans and use cases, aligned with business goals, the software security effort is not a one off from a developer point of view. find all allies, turn none away, arm them with knowledge, turn em loose. the other issue is that there are many security services that you cannot expect an app project to deliver on its own. skyscrapers should not have to have their own fighter jets to protect against people flying planes into them, that is why you have an air force. making the case for platform security can be hard, but that is where the architects have to help (i seem to recall that security is a nonfunctional requirement and that architects are supposed to own non functional requirements). one of the reasons i like browser-based federated identity is because you can externalize some authN code from the app, you get stronger identity tokens across the wire, you don't have developers creating their own authN code, and of course the users get SSO and SLO. this is like app armor, in my view, a reference model for security services - improved security mechanism, great usability, business value, and a simplified programming model. -gp Quoting McGovern, James F (HTSC, IT) [EMAIL PROTECTED]: Thanks for the response. I already own the book and understand how to engage vendors. Where I am seeking assistance is all the work that goes on within a large enterprise before these two things occur. The ideal situation for me would be to get my hands on the five to ten page Powerpoint slide deck that others who have blazed this path before me have used to sell the notion to their executives. -Original Message- From: Andrew van der Stock [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 5:06 PM To: McGovern, James F (HTSC, IT) Cc: SC-L Subject: Re: [SC-L] How is secure coding sold within enterprises? In terms of creating a SDLC, pop out to Borders and get Howard and Lipner's The Security Development Lifecycle ISBN 9780735622142 http://www.microsoft.com/mspress/books/8753.aspx It is simply the best text I've read in a long time. You may be interested in the work Mark Curphey et al is doing at his new start up. They launched an ISM portal a couple of weeks back. http://www.ism-community.org/ If you're just after ideas on how to engage vendors, check out Curphey's blog for some nice insider posts: http://securitybuddha.com/2007/03/07/top-10-tips-for-hiring-web-application-pen-testers/ http://securitybuddha.com/2007/03/07/top-ten-tips-for-hiring-security-code-reviewers/ http://securitybuddha.com/2007/03/08/top-ten-tips-for-managing-technical-security-folks/ He ran Foundstone's services for a while, and built up a pretty good consultancy. The sort of metrics you're after are notoriously hard to find out in the wild. There's some folks capturing screenshots of enterprise dashboards. This may or may not help at all. http://dashboardspy.com/ Thanks, Andrew On 3/19/07 4:12 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I agree with your assessment of how things are sold at a high-level but still struggling in that it takes more than just graphicalizing of your points to sell, hence I am still attempting to figure out a way to get my hands on some PPT that are used internal to enterprises prior to consulting engagements and I think a better answer will emerge. PPT may provide a sense of budget, timelines, roles and responsibilities, who needed to buy-in, industry metrics, quotes from noted industry analysts, etc that will help shortcut my own work so I can start moving towards the more important stuff. -Original Message- From: Andrew van der Stock [ mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 2:50 PM To: McGovern, James F (HTSC, IT) Cc:
Re: [SC-L] What defines an InfoSec Professional?
actually just the former. Robert Garigue characterized firewalls, nids, et al as good network hygiene. The equivalent of a dentist telling you to brush your teeth. An infosec pro needs much more depth than that. The model is charlemagne http://1raindrop.typepad.com/1_raindrop/2007/02/thinking_about_.html -gp -Original Message- From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] Date: Thursday, Mar 8, 2007 10:27 am Subject: [SC-L] What defines an InfoSec Professional? If you have two individuals, one of which has been practicing secure coding= practices and encouraging others to do so for years while another individu= al was involved with firewalls, intrusion detection, information security p= olicies and so on, are they both information security professionals or just= the later? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___
Re: [SC-L] What defines an InfoSec Professional?
What Garigue was trying to say is that deploying a firewall on a network is not security's mandate; it is _part of_ running a network. Basic hygiene. Brushing your teeth is part of having teeth. Deploying anti-virus on a windows desktop is not security; it is _part of_ operating a desktop. This is an important distinction, because it captures why so much security spend is targeted at the wrong issues. Security evolved out of operations, and today we all still live with this historical baggage. If you want to operate a network or a desktop in an enterprise, you have certain security responsibilities defined by information security policy...perhaps even backed up mechanisms, good for you, but these have little to do with information security, much like going to a dentist that just told you to brush your teeth and gave you a tooth brush would have extremely limited valueyet this is what we get from information security groups across this great cyberland of ours. I would point you to the fallacy of keeping up with the Jones' explored in detail at the Justice League http://www.cigital.com/justiceleague/2007/02/22/keeping-up-with-the-jones-se curity-initiatives/ Security groups that help businesses make risk tradeoffs based on functionality, time, and cost add value (you know just like software development does). Amateurs study cryptography; professionals study economics. -- Allan Schiffman -gp On 3/8/07 1:07 PM, Shea, Brian A [EMAIL PROTECTED] wrote: The right answer is both IMO. You need the thinkers, integrators, and operators to do it right. The term Security Professional at its basic level simply denotes someone who works to make things secure. You can't be secure with only application security any more than you can be secure with only firewalls or NIDs. The entire ecosystem and lifecycle must be risk managed and that is accomplished by security professionals. Each professional may have a specialty due to the breadth of topics covered by Security (let's not forget our Physical Security either), but all would be expected to act as professionals. Professionals in this definition being people who are certified and expected to operate within specified standards of quality and behavior much like CISSP, CPA, MD, etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gunnar Peterson Sent: Thursday, March 08, 2007 9:13 AM To: [EMAIL PROTECTED] Cc: SC-L@securecoding.org Subject: Re: [SC-L] What defines an InfoSec Professional? actually just the former. Robert Garigue characterized firewalls, nids, et al as good network hygiene. The equivalent of a dentist telling you to brush your teeth. An infosec pro needs much more depth than that. The model is charlemagne http://1raindrop.typepad.com/1_raindrop/2007/02/thinking_about_.html -gp -Original Message- From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] Date: Thursday, Mar 8, 2007 10:27 am Subject: [SC-L] What defines an InfoSec Professional? If you have two individuals, one of which has been practicing secure coding= practices and encouraging others to do so for years while another individu= al was involved with firewalls, intrusion detection, information security p= olicies and so on, are they both information security professionals or just= the later? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___
Re: [SC-L] The seven sins of programmers | Free Software Magazine
Along these same lines, I submit ³the Four Coders of the Apocalypse² by Dave Thomas and Andy Hunt. One of the major areas we need to work is adoption. Programmers are not all created equal, this presentation shows four types of programmers, and describes what drives them and ideas on dealing with the different types. Excellent bit of software development archaelogy, if you need tips on communicating software security designs, rationale, etc. I would argue that through the work of Gary McGraw, Ken van Wyk, Michael Howard, OWASP, Build Security portal, and many other resources that we are awash in good ideas/tools/templates. What we really need is adoption. Adoption is predicated on understanding the programmer¹s mindsets. The Four Coders of the Apocalypse are The Lifer (someone else will take care of things, knows everything about one topic, all solutions involve that topic, ³it can¹t be done²) The White Rabbit (no time to do it right, ³I can¹t talk now²) The Racehorse (run forward wearing blinkers, never change existing code) The Beautiful Dreamer (programming as an end in itself) http://www.pragmaticprogrammer.com/talks/4coders/4coders.htm -gp On 2/23/07 7:02 AM, Kenneth Van Wyk [EMAIL PROTECTED] wrote: SC-L, So my trusty rss aggregator (NewsFire) found an interesting blog for me this morning, and I thought I'd share it here. The blog is from Free Software Magazine and it's titled, The seven sins of programmers. On the surface, it has nothing whatsoever to do with software security -- the word security is never even mentioned in passing -- but I believe there are some worthy security lessons to be gleamed from it. http://www.freesoftwaremagazine.com/blog/seven_sins Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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. ___
Re: [SC-L] Compilers
Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. -gp On 12/21/06 9:30 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___
Re: [SC-L] re-writing college books - erm.. ahm...
Seeking perfect correctness as an approach to security is a fool's errand. Security is designing systems that can tolerate imperfect software. Exactly. On Curb Your Enthusiasm this happened recently. Larry David was frantically looking for a DVD case, but could not find it. LD: I don't know what happened. I have a system. I put the DVD in the player, and I put the case on top of the player. But now it is gone. Friend: That's not a system. A system is - you buy a bunch of empty DVD cases and put them next to the player. -gp ___ 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
Re: [SC-L] Google code search games
DTDs http://www.google.com/codesearch?hl=enlr=q=file%3AdtdbtnG=Search -gp On 10/6/06 2:14 AM, Robert C. Seacord [EMAIL PROTECTED] wrote: Gadi, Here are some searches from Derek Jones: The new Google source code search page has opened up some interesting research possibilities. How many instances of: if (...) ; are there out there (skip the first half dozen unusual macro uses)? http://www.google.com/codesearch?hl=enlr=q=++%5Csif%5C(%5B%5E)%5D*%5C)%3B+la ng%3Ac%2B%2BbtnG=Search Security holes in PHP web applications: http://www.google.com/codesearch?hl=enlr=q=Where+%5C%24_POST+-addslashes+lan g%3Aphp Back door passwords :-) http://www.google.com/codesearch?q=+%22backdoor+password rCs ___ 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 ___ 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
Re: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
I can't say enough good things about this interview: Conversation with Bruce Lindsay Design For Failure http://www.acmqueue.org/modules.php?name=Contentpa=showpagepid=233 snip BL: There are two classes of detection. One is that I looked at my own guts and they didnt look right, and so I say this is an error situation. The other is I called some other component that failed to perform as requested. In either case, Im faced with a detected error. The first thing to do is fold your tentthat is, put the state back so that the state that you manage is coherent. Then you report to the guy who called you, possibly making some dumps along the way, or you can attempt alternate logic to circumvent the exception. In our database projects, what typically happens is it gets reported up, up, up the chain until you get to some very high level that then says, Oh, I see this as one of those really bad ones. Im going to initiate the massive dumping now. When you report an error, you should classify it. You should give it a name. If youre a component that reports errors, there should be an exhaustive list of the errors that you would report. Thats one of the real problems in todays programming language architecture for exception handling. Each component should list the exceptions that were raised: typically if I call you and you say that you can raise A, B, and C, but you can call Joe who can raise D, E, and F, and you ignore D, E, and F, then Im suddenly faced with D, E, and F at my level and theres nothing in your interface that said D, E, and F errors were things you caused. That seems to be ubiquitous in the programming and the language facilities. You are never required to say these are all the errors that might escape from a call to me. And thats because youre allowed to ignore errors. Ive sometimes advocated that, no, youre not allowed to ignore any error. You can reclassify an error and report it back up, but youve got to get it in the loop. /snip -gp Quoting Michael S Hines [EMAIL PROTECTED]: That's a rather pragmatic view, isn't it? Perhaps if other language constructs are not used, they should be removed? OTOH - perhaps the fault is not the language but the coder of the language? - lack of knowledge - pressure to complete lines of code - lack of [management] focus on security - or 100s of other reasons not to do the right thing... Sort of like life, isn't it? Mike Hines -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Leffler Sent: Friday, September 01, 2006 3:44 PM To: sc-l@securecoding.org Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind' Pascal Meunier [EMAIL PROTECTED] wrote: Tim Hollebeek [EMAIL PROTECTED] wrote: (2) in many languages, you can't retry or resume the faulting code. Exceptions are really far less useful in this case. See above. (Yes, Ruby supports retrying). Bjorn Stroustrup discusses retrying exceptions in Design and Evolution of C++ (http://www.research.att.com/~bs/dne.html). In particular, he described one system where the language supported exceptions, and after some number of years, a code review found that there was only one retryable exception left - and IIRC the code review decided they were better off without it. How much are retryable exceptions really used, in Ruby or anywhere else that supports them? -- Jonathan Leffler ([EMAIL PROTECTED]) STSM, Informix Database Engineering, IBM Information Management Division 4100 Bohannon Drive, Menlo Park, CA 94025-1013 Tel: +1 650-926-6921 Tie-Line: 630-6921 I don't suffer from insanity; I enjoy every minute of it! ___ 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 ___ 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 ___ 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
Re: [SC-L] Bumper sticker definition of secure software
Secure software you're (not) soaking in it. On 7/16/06 8:32 AM, mikeiscool [EMAIL PROTECTED] wrote: On 7/16/06, ljknews [EMAIL PROTECTED] wrote: At 3:27 PM -0400 7/15/06, Goertzel Karen wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C6A844.D6A28B6B I've been struggling for a while to synthesise a definition of secure software that is short and sweet, yet accurate and comprehensive. Here's what I've come up with: Secure software is software that remains dependable despite efforts to compromise its dependability. Agree? Disagree? I disagree about that being bumper-sticker size, and I think we really need bumper stickers. a better bumper sticker would be something like: secure software is what i write. call me now to find out how! ... i don't see the point of a short phrase. it's obvious what secure software is. software that has no bugs and no design faults. -- mic ___ 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 ___ 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
Re: [SC-L] Comparing Scanning Tools
Hi James, I think you are right to look at it as economic issue, but the other factor to add into your model is not just the short term impact to developer productivity (which is non-trivial), but also the long term effects of making decisions *not* to deal with finding bugs. Cleaning up data breach costs more than encryption Protecting customer records is a much less expensive than paying for cleanup after a data breach or massive records loss, research company Gartner said. Gartner analyst Avivah Litan testified on identity theft at a Senate hearing held after the Department of Veterans Affairs lost 26.5 million vet identities. A company with at least 10,000 accounts to protect can spend, in the first year, as little as $6 per customer account for just data encryption, or as much as $16 per customer account for data encryption, host-based intrusion prevention, and strong security audits combined, Litan said. Compare [that] with an expenditure of at least $90 per customer account when data is compromised or exposed during a breach, she added. Litan recommended encryption as the first step enterprises and government agencies should take to protect customer/citizen data. If that's not feasible, organizations should deploy host-based intrusion prevention systems, she said, and/or conduct security audits to validate that the company or agency has satisfactory controls in place. http://www.techweb.com/wire/security/188702019 Or, Brian Chess once pointed out: My favorite historical analogy this month is from medicine: it took *decades* between the time that researchers knew that fewer people died if surgeons washed their hands and the time that antisepsis was common in the medical community. That lag was entirely due to social factors: if it's 1840 you've been successfully practicing medicine for decades, why would you want to change your routine? And yet imagine a modern day surgeon who says I'm really busy today, so I'm going to save time by not scrubbing in before I start the operation. It's simply unthinkable. Hopefully software development is headed in the same direction, but on an accelerated timetable. -gp On 6/7/06 4:08 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Thanks for the response. One of the things that I have been struggling to understand is not the importance of using such a tool as I believe they provide value but more of the fact that these tools may not be financial sustainable. Many large enterprises nowadays outsource development to third parties. Likewise, the mindset in terms of budgeting tends to eschew per developer seat tool purchases. Nowadays, it is rare to find an enterprise not using free tools such as Eclipse and not paying for IDEs I have yet to find a large enterprise that has made a significant investment in such tools. I wonder if budgets and the tools themselves are really causing more harm than helping in that enterprises will now think about trading off such tools vs the expense they cost. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 4:34 PM To: McGovern, James F (HTSC, IT) Cc: sc-l@securecoding.org Subject: Re: [SC-L] Comparing Scanning Tools | Date: Mon, 5 Jun 2006 16:50:17 -0400 | From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] | To: sc-l@securecoding.org | Subject: [SC-L] Comparing Scanning Tools | | The industry analyst take on tools tends to be slightly different than | software practitioners at times. Curious if anyone has looked at Fortify and | has formed any positive / negative / neutral opinions on this tool and | others... We evaluated a couple of static code scanning tools internally. The following is an extract from an analysis I did. I've deliberately omitted comparisons - you want to know about Fortify, not how it compares to other products (which raises a whole bunch of other issues), and included the text below. Standard disclaimers: This is not EMC's position, it's my personal take. Caveats: This analysis is based on a 3-hour vendor presentation. The presenter may have made mistakes, and I certainly don't claim that my recall of what he said is error-free. A later discussion with others familiar with Fortify indicated that the experience we had is typical, but is not necessarily the right way to evaluate the tool. Effective use of Fortify requires building a set of rules appropriate to a particular environment, method of working, constraints, etc., etc. This takes significant time (6 months to a year) and effort, but it was claimed that once you've put in the effort, Fortify is a very good security scanner. I am not in a position to evaluate that claim myself. BTW, one thing not called out below is that Fortify can be quite slow. Our experience in testing was that a Fortify scan took about twice as long as a C++ compile/link cycle, unless you add data flow analysis - in which case the time
Re: [SC-L] Comparing Scanning Tools
Hi James, The point is going back to your original question -- I wonder if budgets and the tools themselves are really causing more harm than helping in that enterprises will now think about trading off such tools vs the expense they cost. -- the economic comparison needs to take into account the tradeoff not just the expense of the tool, developer productivity, and bug remediation early v. late, but also the breach itself has a cost when those bugs that are not dealt are eventually exercised. So I don't care if you don't like the Gartner numbers, you can use others to weigh the cost of the breach (Ponemon's are higher actually), but whatever number you choose to use should be factored in to your model to account for this. It may not be helpful if not scrubbing in allows your surgeons to operate on more patients if they are killing them faster due to infections they cause. -gp On 6/8/06 9:15 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Several thoughts: 1. I love it when industry analysts are perceived as being credible by throwing out financial costs for things they really don't have visibility into. 2. The VA lost data not do secure coding techniques but an employee not following the rules on what data to take out of the building. 3. No industry analyst has ever attempted to quantify cost vs benefit of secure coding when compared to other constraints. The quantification to date has only been the cliche: it is cheaper to fix X earlier in the lifecycle rather than later in which X could be pretty much any system quality. -Original Message- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 9:28 AM To: McGovern, James F (HTSC, IT) Cc: Secure Mailing List Subject: Re: [SC-L] Comparing Scanning Tools Hi James, I think you are right to look at it as economic issue, but the other factor to add into your model is not just the short term impact to developer productivity (which is non-trivial), but also the long term effects of making decisions *not* to deal with finding bugs. Cleaning up data breach costs more than encryption Protecting customer records is a much less expensive than paying for cleanup after a data breach or massive records loss, research company Gartner said. Gartner analyst Avivah Litan testified on identity theft at a Senate hearing held after the Department of Veterans Affairs lost 26.5 million vet identities. A company with at least 10,000 accounts to protect can spend, in the first year, as little as $6 per customer account for just data encryption, or as much as $16 per customer account for data encryption, host-based intrusion prevention, and strong security audits combined, Litan said. Compare [that] with an expenditure of at least $90 per customer account when data is compromised or exposed during a breach, she added. Litan recommended encryption as the first step enterprises and government agencies should take to protect customer/citizen data. If that's not feasible, organizations should deploy host-based intrusion prevention systems, she said, and/or conduct security audits to validate that the company or agency has satisfactory controls in place. http://www.techweb.com/wire/security/188702019 Or, Brian Chess once pointed out: My favorite historical analogy this month is from medicine: it took *decades* between the time that researchers knew that fewer people died if surgeons washed their hands and the time that antisepsis was common in the medical community. That lag was entirely due to social factors: if it's 1840 you've been successfully practicing medicine for decades, why would you want to change your routine? And yet imagine a modern day surgeon who says I'm really busy today, so I'm going to save time by not scrubbing in before I start the operation. It's simply unthinkable. Hopefully software development is headed in the same direction, but on an accelerated timetable. -gp * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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 ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc
Re: [SC-L] Secure Application Protocol Design
There is a well understood best practice in software development that developers should not attempt to write their own cryptographic algorithms because of the complexity, lack of peer review, and value of that which the cryptographic functions are protecting. Developers, in contrast, routinely write one-off identity solutions that are never peer reviewed by a wider audience. This identity information is propagated and integrated throughout software systems and used as a basis for making security decisions about access control to critical resources and the confidentiality of personal and business data. https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assemb ly/207.html?branch=1language=1 Even if the crypto is implemented correctly, there are usually problems in the identity implementation which is the basis for access control decisions, anyhow. So developers should not write that either. -gp On 6/5/06 1:20 PM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: Would love to see Gary address a couple of behaviors I have seen in my travel amongst architect types in corporate America especially the practice of secure application protocol design that isn't so secure. Is anyone writing/blogging deeply on this aspect? Likewise, there are many folks in corporate America that have not yet acknowledged that they shouldn't be playing part-time cryptographer and don't have the competency to design cryptographic primitives such as hash functions and algorithms to protect data. Does anyone know of any friendly articles that speak to this problem space? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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 ___ 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
Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
This comes back to that great concept called 'Faith-based' Security (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html ), which is when people are told so many times that something is secure, that that they believe that it MUST be secure. Some examples:This is also neatly summarized by Brian Snow thusly:We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.-gp1. Notes and links on "We Need Assurance!" paperhttp://1raindrop.typepad.com/1_raindrop/2005/12/the_road_to_ass.html___ 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
Re: [SC-L] eWeek: AJAX Poses Security, Performance Risks
a lot of this gets back to a framework versus roll your own debate http://1raindrop.typepad.com/1_raindrop/2005/05/wsmex_v_httpget.html http://www.identityblog.com/2005/04/30.html#a210 also, for some good context security in ajax, rest, et. al. as well as examples of how amazon and google deals with security check out mark o'neill's deck from rsa: http://radio.weblogs.com/0111797/2006/02/20.html#a44 -gp On Feb 1, 2006, at 12:31 AM, Crispin Cowan wrote: ljknews wrote: I have been involved in a dialog with AJAX fans (which is different from experts) who say you security folks just have to bow to the inevitable and figure out how to secure whatever mechanism we come up with. This attitude is not unique to AJAX advocates. I remember holding this view myself, while wrestling with the problems of producing a truly transparent distributed operating system in the late 1980s and early 1990s; security was a bother that made things hard(er). Of course, this is just lifetime employment for security people :) I have certainly made a career out of securing things that are inherently insecure. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/ ~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption ___ 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 ___ 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
Re: [SC-L] BSI: SOA what?
Good stuff, you (and your co-authors) are right: SOA and Web Services are properly viewed as opportunities for security improvements, not security nightmares. Also, I have a paper here (http://www.arctecgroup.net/ISB1009GP.pdf) on Service Oriented Security (SOS) Architecture -gp Quoting Gary McGraw [EMAIL PROTECTED]: Hi all, I'm sure by now everyone has heard at least one marketing person say SOA in some capacity. Such it is with buzzwords. Looks like we're still climbing the hype curve with this one too. The one great opportunity with SOA (or Service Oriented Architecture for those allergic to acronyms) is that during a rearchitecting exercise, software security can play a critical role. Avoid flaws when rearchitecting by applying the architectural risk analysis touchpoint! IEEE Security Privacy magazine published an article that Jeremy, Scott Matsumoto, and I wrote about SOA security. You can get it here: http://www.cigital.com/papers/download/bsi12-soa.doc.pdf Please consider subscribing to IEEE SP. It's a great magazine and a bargain at only $29 (no IEEE membership required). See http://www.computer.org/security/bsisub for more. gem www.swsec.com p.s. I recently updated my home page after, oh, three or four years... www.cigital.com/~gem This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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 ___ 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
Re: [SC-L] Bugs and flaws
Hi John, Which of the following more aptly characterizes the problem?: IMPL. BUG: Insufficient security-constraint existed on the admin Servlet in the app's deployment descriptor. ARCH. FLAW: No façade component gated privileged functionality -alternatively- ARCH. FLAW: Privileged functionality incapable of judging Principal's entitlement (both fine, one user changing another's password, or coarse, application functionality improperly accessed) Clausewitz said to be strong, first in general, and then at the decisive point. Assuming you consider authentication and authorization on admin functions a decisive point, then this scenario is a failure in both instances. The question you raise is locating the responsibility to deal with this problem. In a distributed system, there are many potential areas to locate those controls. Problems do not necessarily have to be solved (and in some cases cannot be) at the same logical layer they were created (http:// 1raindrop.typepad.com/1_raindrop/2005/11/thinking_in_lay.html). Would an authenticating reverse proxy have prevented this problem? How about stronger identity protocols? -gp ___ 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
Re: [SC-L] Announcement: The Web Application Firewall Evaluation Criteria v1
That page is a link to the doc types html: http://www.webappsec.org/projects/waf_evaluation/v1/wafec-draft-1-20051007.html txt http://www.webappsec.org/projects/waf_evaluation/v1/wafec-draft-1-20051007.txt pdf http://www.webappsec.org/projects/waf_evaluation/v1/wafec-draft-1-20051007.pdf -gp Quoting ljknews [EMAIL PROTECTED]: At 11:39 PM -0400 10/9/05, [EMAIL PROTECTED] wrote: The Web Application Firewall Evaluation Criteria project is proud to announce its first public release. The goal of the project is to develop a detailed web application firewall evaluation criteria; a testing methodology that can be used by any reasonably skilled technician to independently assess quality of a web application firewall. The primary purpose of this release is to solicit comments from the public. You can download the current version of the evaluation criteria from the project home page: http://www.webappsec.org/projects/waf_evaluation/ Hmmm. That page shows me a blank page with a lovely logo and toolbar at the top. Other pages on that site do not have that problem. Then again, http://validator.w3.org says that page has 167 errors on it. I would say that conforming to standards should be the first step, especially when an automatic checker is available. -- Larry Kilgallen
[SC-L] Build Security In
The DHS/SEI portal Build Security In is now live, there is a ton of resources and artifacts for developers to use to write more secure code: https://buildsecurityin.us-cert.gov/portal/ The ones i worked on are here Identity in Assembly and Integration https://buildsecurityin.us-cert.gov/portal/article/bestpractices/ assembly_integration_and_evolution/ Identity_in_Assembly_and_Integration.xml Architectural Risk Analysis https://buildsecurityin.us-cert.gov/portal/article/bestpractices/ architectural_risk_analysis/architectural_risk_assessment.xml -gp
Re: [SC-L] Fwd from CIO Update: Why is application security so elusive?
CIO Asia has a column on A Few Good Metrics http://cio-asia.com/ShowPage.aspx? pagetype=2articleid=2560pubid=5issueid=63 The article talks about using metrics to quantify risks and control effectiveness. There's no denying that proven economic principles can—and should—be applied to information security investments. At the same time, a bumper crop of valuable metrics exist that don't require classes on Nobel Prize-winning theories or a working knowledge of the Greek alphabet. You've actually already sowed the seeds of these less dense but equally valuable metrics. They're sitting in your log files, on your network, in the brains of your business unit managers, just waiting to be harvested. You won't need computational prowess to exploit this crop's value, just some legwork and—this is key—the most effective presentation tools ... Jaquith has sharp, sometimes contrarian opinions on what makes a good metric and what makes for good presentation of metrics. For example, he thinks annual loss expectancy (ALE), a tool used to measure potential losses against probability of losses occurring over time, is useless, because in infosecurity, the L and the E in ALE are wild guesses. Quoting Geer, he says, The numbers are too poor even to lie with. -gp On Sep 18, 2005, at 10:17 AM, Kenneth R. van Wyk wrote: FYI, there's a column in CIO Update by Ed Adams exploring some of the reasons why secure software is so hard to find. Unlikely to be anything new to SC-L readers, but it could be worth a quick read in any case. In particular, his recommendations (to his presumably mostly CIO audience) are quite different than what you might expect to find, say, here on SC-L. In any case, you can find the article at: http://www.cioupdate.com/trends/article.php/ 3548306 (Full disclosure: CIO Update is run by Jupiter Media, who also owns the site (eSecurityPlanet.com) where I'm a monthly columnist.) Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
Re: [SC-L] Information Security Considerations for Use Case Modeling
When I coach teams on security in the SDLC, I ask them to first see what mileage they can get out of existing artifacts, like Use Cases, User Stories, and so on. While these artifacts and processes were not typically designed with security in mind, there is generally a lot of underutilized properties in them that can be exploited by security architects and analysts. The Use Case model adds traceability to security requirements, but just as importantly it allows the team to see not just the static requirements, rather you can the requirements in a behavioral flow. Since so much of security is protocol based and context sensitive, describing the behavioral aspects is important to comprehensibility. At the end of exploring existing artifacts, then there needs to be a set of security-centric artifacts like threat models, misuse cases, et. al. The output, e.g. design decisions, of these security-centric models are fed back into the requirements in an iterative fashion. Security analysts and architects cannot do all the work that goes into secure software development by themselves. There may be a handful of security people supporting hundreds of developers. This is why we need to educate not just developers on writing secure code, but also business analysts on security Use Cases, requirements, etc. (the main purpose of my article), testers on how to write/run/read security test cases, an so on. -gp On Jun 26, 2005, at 5:37 AM, Johan Peeters wrote: This topic is very pertinent. I agree that the lack of attention paid to security in many development projects stems from an inability to track security requirements in the software development life cycle. By addressing security requirements in a use case model, I believe that traceability can be improved enormously. However, traditional use cases are not always adequate to express security requirements. For example, whereas it may be possible to say that a user needs to authenticate to perform an action, it is not possible to express that attackers must be prevented from executing their own code on the system. I therefore feel there is a strong case for extending the use case concept to abuse cases, as introduced by McDermott in C. Fox, Using Abuse Case Model for Security Requirements Analysis in 1999 (http:// www.acsac.org). In agile ecologies, use cases have transmuted to user stories. I have proposed to also extend user stories to abuser stories (http:// www.johanpeeters.com/papers/abuser stories.pdf). kr, Yo Gunnar Peterson wrote: I have published a new paper on integrating security into Use Case Modeling: http://www.arctecgroup.net/secusecase.htm -gp -- Johan Peeters http://www.johanpeeters.com +32 16 649000
RE: [SC-L] Credentials for Application use
Keith Brown has a good discussion of at least one of the design choices, namely delegation vs. impersonation: http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.html http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsImpersonation.html -gp Quoting Gizmo [EMAIL PROTECTED]: I have a similar situation in one of my applications. The customer wishes to secure the database. Since we use a Btrieve database, the only way to do this is be setting an owner name on the DB, and then encrypting using the owner name as the password. However, once the DB is secured, you can't access it unless you have the owner name, and giving out the owner name to everyone who uses the app to access the DB pretty much defeats the whole purpose of the exercise. The only way I can see to deal with this is something similar to what I've done in my app: The user provides the management console with the password to secure the DB. The app encrypts the password using the blowfish algorithm and a private key. It then postpends a SHA1 hash, Base64 encodes the result, and stores it in three places: a local configuration file, a remote configuration file, and the registry. All three stores are secured using an ACL such that only the user the main server app runs under has access to the data. In the event that one of the stores is corrupted or tampered with (as determined by the SHA1 hash) voting logic is used to determine which stored password is to be discarded. I imagine that someone here has a better idea, and if so, I'd love to hear it. Later, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mikey Sent: Tuesday, May 10, 2005 6:49 PM To: SC-L@securecoding.org Subject: [SC-L] Credentials for Application use This is a broad question around the current practices and recommendation of what not to do when it comes to credentials used by applications to gain access to a resource or data stored elsewhere. As an example, I have some middleware components that need to gain access to a data repository that contains sensitive information. The middleware components and data repository reside in separate, distinct security boundaries protected by differing authentication and access control mechanisms. Application developers insists the only way to gain access to the data repository is to create a set of credentials for the repository that only they can use. But because the middleware components are using it, there is no requirement for a user to enter those credentials in order to authenticate usage. I guess I wouldn't want the users to know the details of this set of credentials either. Short of creating a user credential for each user accessing the application on the data repository side, they insist that they need to store the userid and password in a static format somewhere on the middleware server. For example, a configuration file or some part of the operating system. Is there a best practice guideline for this scenario? What have other people in the same situation been doing here?
Re: [SC-L] re: Why Software Will Continue to Be Vulnerable
It appears that the user-obvious malware would need to reach the anterior insula to make a difference in computer security. From Business Week -- Why Does logic often takes a backseat in making decisons?: The National Hockey League and its players wrangle over a salary cap. The impasse causes the season to be canceled. Everybody loses. What went wrong? According to the new science of neuroeconomics, the explanation might lie inside the brains of the negotiators. Not in the prefrontal cortex, where people rationally weigh pros and cons, but deep inside, where powerful emotions arise. Brain scans show that when people feel they're being treated unfairly, a small area called the anterior insula lights up, engendering the same disgust that people get from, say, smelling a skunk. That overwhelms the deliberations of the prefrontal cortex. With primitive brain functions so powerful, it's no wonder that economic transactions often go awry. In some ways, modern economic life for humans is like a monkey driving a car, says Colin F. Camerer, an economist at California Institute of Technology. http://www.businessweek.com/print/magazine/content/05_13/b3926099_mz057.htm?chan=mz; -gp Quoting Bill Cheswick [EMAIL PROTECTED]: Here's a depressing survey I found it utterly unsurprising. The bad guys almost never erase hard drives, or do other terribly inconvenient things to the machines they own. They simply run in the background, mostly, and the users don't understand the issues. My father has repeatedly asked why he should care that his computer is totally owned. I've told him that his CPU engine is blowing blue smoke all over the Internet, but that doesn't help. An outbreak of user-obvious malware might change the equation, but I am not suggesting that someone run the experiment. ches
[SC-L] Doing something about software security
I was thinking about something that Dave Winer said on the Gillmor Gang about how the software industry moves forward when small groups (like 1 or 2) of developers get motivated to solve a problem. I was wondering how this applies to software security, since it seems like a perfect description for what seems to have motivated Phil Zimmermann to write PGP. In information security, we seem to have a preponderance of ideas and technologies from vendors and academia, but relatively less (compared to the software space) amount of grassroots efforts by small groups of developers making incremental improvements. There are probably a couple of reasons for this, first security tends to be a system property, so it can be difficult to deal with this incrementally. Secondly, security is sort of invisble, e.g. in normal app development work you code a lot and then *something* happens, your web server is suddenly multithreaded and can handle tons more volume of requests. In security, you work really hard, write a lot of code and then something doesn't happen. Does anyone have candidates for grassroots efforts targeted at software security and secure coding? Not necessarily required to be open source (though I would expect most of them to be), but a low barrier to entry for developers to use, e.g. free. I have started a list including: * mod_security * RATS * OWASP (Standards and tools) * Legion of the Bouncy Castle * Microsoft's Threat Modeling Tool Any other nominations? -gp
RE: [SC-L] Doing something about software security
Thanks for the feedback and link (as well as to those who have replied off line). Note, I did not intend that the 5 tools I listed were exhaustive, just trying to get an idea what works in the field and wanted to get the ball rolling. Any other candidates out there? Flawfinder, anyone? -gp Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: You seem to be leaving out one of the largest open efforts at security. ISECOM at http://www.isecom.org covers security testing, secure coding, incident response and other security related topics. -Original Message- From: Gunnar Peterson Date: 4/19/05 6:32 am To: Secure Coding Mailing List Subj: [SC-L] Doing something about software security I was thinking about something that Dave Winer said on the Gillmor Gang about how the software industry moves forward when small groups (like 1 or 2) of developers get motivated to solve a problem. I was wondering how this applies to software security, since it seems like a perfect description for what seems to have motivated Phil Zimmermann to write PGP. In information security, we seem to have a preponderance of ideas and technologies from vendors and academia, but relatively less (compared to the software space) amount of grassroots efforts by small groups of developers making incremental improvements. There are probably a couple of reasons for this, first security tends to be a system property, so it can be difficult to deal with this incrementally. Secondly, security is sort of invisble, e.g. in normal app development work you code a lot and then *something* happens, your web server is suddenly multithreaded and can handle tons more volume of requests. In security, you work really hard, write a lot of code and then something doesn't happen. Does anyone have candidates for grassroots efforts targeted at software security and secure coding? Not necessarily required to be open source (though I would expect most of them to be), but a low barrier to entry for developers to use, e.g. free. I have started a list including: * mod_security * RATS * OWASP (Standards and tools) * Legion of the Bouncy Castle * Microsoft's Threat Modeling Tool Any other nominations? -gp
[SC-L] SOS: Service Oriented Security
I have blogged at a high level about some work I am doing on security aspects in SOA and Web Services. Service Oriented Security (SOS) architecture defines a set of architectural views, their key consituents, constraints, and relationships. As the SOA space continues to evolve our software security models will also need to adapt to these new realities that change or make obsolete (and in some cases breathe new life into) security mechanisms we have relied on over the years. Initial high level overview of SOS architectural views: http://1raindrop.typepad.com/1_raindrop/2005/03/sos_service_ori.html I will also be doing a presentation at OWASP Europe on this, and will forward slides if people are interested. -Gunnar
[SC-L] Design for failure
Gee, no my OS is better than yours? What are mailing lists for then? [Ed. Nope, sorry. While our volume is low, I like to think that our signal:noise ratio is high. Let's keep it that way. Besides, Debian rocks! :-) KRvW] If people on this list have not read it yet, the conversation with Bruce Lindsay on Desiging for Failure in November's ACM Queue is great read: http://www.acmqueue.org/modules.php?name=Contentpa=showpagepid=233 -gp
Re: [SC-L] Secured Coding
so the question then is how do we security professionals catch up to where the anasazis were 700 hundred years ago: http://riskman.typepad.com/perilocity/2004/08/cliff_forts_vs_.html -gp Quoting Greenarrow 1 [EMAIL PROTECTED]: As quoted in a recent email from the article, A Patch is a Patch, Antone Gonsalves, Editor for InternetWeek: To read the entire article use the following link: http://update.internetweek.com/cgi-bin4/DM/y/ekcm0GPBjC0G4X0BbSA0At Whether we're willing to accept it or not, bulletproof software doesn't exist. Some applications are more secure than others, and some vendors could do more to protect customers. But at the end of the day, we're responsible for our own safety. Build your defenses, as best you can, and then try not to worry. If it helps, just think how small your problems are in relation to the universe. I truly believe this as no matter how secured we make our programs there will always be someone to figure how to break it. Regards, George Greenarrow1 InNetInvestigations-Forensics
Re: [SC-L] How do we improve s/w developer awareness?
Concur that security is more colorless than most of the other ilities. My point is that the other domains which serve up the non-functional requirements are colorless to some degree as well. So in terms of how the other ility domains approach the quantification and elaboration of the goals that emerge from their domains and getting them in the hands of architects and developers, there may be some activities and artifacts in there that we can learn from. -gp Quoting Jeff Williams [EMAIL PROTECTED]: We certainly have a lot to learn from the other communities, but security is worse than the other *-ilities, because it is more difficult to see. Consumers can tell which operating system is easier to use, and which one is faster, but there is no way to know which is more secure today. Until consumers can tell the difference between a security program and one that is not, they will not pay more for the secure one. Which means that it is not going to make many managers' radar screen, and therefore developer awareness will never happen on a broad scale. In my opinion, the way out of this trap is to get more information to consumers about the security in software. Information like how many lines of code, what languages, what libraries, process used, security testing done, mechanisms included, and other information can and should be disclosed. --Jeff - Original Message - From: Gunnar Peterson [EMAIL PROTECTED] To: Yousef Syed [EMAIL PROTECTED] Cc: Secure Coding Mailing List [EMAIL PROTECTED] Sent: Friday, November 12, 2004 6:58 AM Subject: Re: [SC-L] How do we improve s/w developer awareness? Making software secure should be a requirement of the development process. I've had the priviledge to have worked on some very good projects where the managers emphasised security in the beginning of the projects life cycle since it was a requirement of the client. Making software secure absolutely should be part of the development lifecycle, and as early as possible, too. My overall point was that if you talk to the people who really care about usability (as distinguished from just features) you will hear very similar frustrations about their ability to get what they consider true usability requirements into the end product. So in terms of learning from other communities I think as opposed to beating our heads against the same wall it can be helpful to learn from another *-ility community to see what ways they have tried successfully/unsuccessfully to increase the quality in software from their viewpoint. My suggestion is that the problem is not just software security but run a little deeper to the main problem of software quality of which security is one of the factors (albeit an important one). So what are the common threads amongst usability and security? For examples it is interesting to note that both communities seem to value early involvement in the development lifecycle and striving for simplicity in design. Software security does not need more barriers, but to the extent that we can find allies with similar goals and issues from other communities (could be *-ilitity, business, compliance, legal btw) and collaborate with them to communicate the value of quality, then our chances for shipping better software are increased. -gp Societies have invested more than a trillion dollars in software and have grotesquely enriched minimally competent software producers whose marketing skills far exceed their programming skills. Despite this enormous long-run investment in software, economists were unable to detect overall gains in economic productivity from information technology until perhaps the mid-1990s or later; the economist Robert Solow once remarked that computers showed up everywhere except in productivity statistics. Quality may sometimes be the happy by-product of competition. The lack of competition for the PC operating system and key applications has reduced the quality and the possibilities for the user interface. There is no need on our interface for a visible OS, visible applications, or for turning the OS and browsers and e-mail programs into marketing experiences. None of this stuff appeared on the original graphical user interface designed by Xerox PARC. That interface consisted almost entirely of documents--which are, after all, what users care about. Vigorous competition might well have led to distinctly better PC interfaces--without computer administrative debris, without operating system imperialism, without unwanted marketing experiences--compared to what we have now on Windows and Mac. Today nearly all PC software competition is merely between the old release and the new release of the same damn product. It is hard to imagine a more perversely sluggish incentive system for quality. Indeed, under such a system, the optimal economic strategy for market
