Re: [SC-L] OWASP Session - Fortify 360 - Thursday, September 17, 2009 (webex available)
I posted an lengthy email to the owasp-leaders list about this event which you can read on my blog: http://diniscruz.blogspot.com/2009/09/fortify-hands-on-demosession-at.html(in there you can also see a couple more ideas that come up of that owasp-leaders email thread) Let me know if (after reading my post) you have further comments, ideas or worries about this OWASP 'activity' :) Dinis Cruz OWASP Board Member On Wed, Sep 16, 2009 at 7:53 PM, Eric Dalci eric_da...@yahoo.fr wrote: SC-L, The Owasp Northern Virginia chapter is pleased to invite you to its next session on *Thursday September 17th*. We will be hosting a presentation, demo and hands on session of Fortify 360 ( http://www.fortify.comhttps://webmail.cigital.com/owa/redir.aspx?C=e4372f720cb1453c9c262f8cb8d38effURL=http%3a%2f%2fwww.fortify.com). Fortify 360 includes Fortify SCA (Source Code Analyzer) and the Fortify 360 Server which is Fortify's solution for an enterprise deployment of SCA. The session will start with a presentation by Eric Klein (Fortify), followed by a demo and finally a hands on session where the audience will be free to install Fortify SCA on their machine and scan the Webgoat application. The audience will also be introduced with the Fortify 360 Server and try some of the enterprise level features such as collaborative code review, metrics and so on. Bring your laptop if you want to try Fortify 360! For the hands on, bring your laptop, the install takes about 10-15 minutes. We'll have installation files for Windows, Mac and Linux. You can also follow via *webex* (see below for links) The target audience is anyone interested in Secure Code Review with a Static Analysis tool at the desktop level and/or enterprise level. We will need to register visitors before hand...please email wade.woolw...@owasp.org for registration and confirm attendance. Pizza and refreshments will be served. http://www.owasp.org/index.php/Virginia_%28Northern_Virginia%29#tab=Schedulehttps://webmail.cigital.com/owa/redir.aspx?C=e4372f720cb1453c9c262f8cb8d38effURL=http%3a%2f%2fwww.owasp.org%2findex.php%2fVirginia_%2528Northern_Virginia%2529%23tab%3dSchedule *Location*: 22260 Pacific blvd, Sterling, VA. 20166 (AOL Office) Topic: OWASP Session - Fortify 360 *Date: Thursday, September 17, 2009* Time: 6:00 pm, Eastern Daylight Time (GMT -04:00, New York) Meeting Number: 487 746 568 Meeting Password: Owasp1 Please click the link below to see more information, or to join the meeting. --- To join the online meeting (Now from iPhones too!) --- 1. Go to https://cigital.webex.com/cigital/j.php?ED=126987157UID=0PW=f26e92a72b1b0a151a5dhttps://webmail.cigital.com/owa/redir.aspx?C=e4372f720cb1453c9c262f8cb8d38effURL=https%3a%2f%2fcigital.webex.com%2fcigital%2fj.php%3fED%3d126987157%26UID%3d0%26PW%3df26e92a72b1b0a151a5d 2. Enter your name and email address. 3. Enter the meeting password: Owasp1 4. Click Join Now. --- To join the teleconference only --- Call-in toll-free number (US/Canada): 866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdfhttps://webmail.cigital.com/owa/redir.aspx?C=e4372f720cb1453c9c262f8cb8d38effURL=http%3a%2f%2fwww.webex.com%2fpdf%2ftollfree_restrictions.pdf -- ___ Owasp-wash_dc_va mailing list owasp-wash_dc...@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_vahttps://webmail.cigital.com/owa/redir.aspx?C=e4372f720cb1453c9c262f8cb8d38effURL=https%3a%2f%2flists.owasp.org%2fmailman%2flistinfo%2fowasp-wash_dc_va ___ Owasp-wash_dc_va mailing list owasp-wash_dc...@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_vahttps://webmail.cigital.com/owa/redir.aspx?C=e4372f720cb1453c9c262f8cb8d38effURL=https%3a%2f%2flists.owasp.org%2fmailman%2flistinfo%2fowasp-wash_dc_va ___ 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,
[SC-L] Silver Bullet transcript
hi sc-l, A partial transcript for Bob Blakely's silver bullet episode will be published in IEEE Security Privacy magazine in the upcoming issue. You can read a copy yourself here: http://www.cigital.com/silverbullet/shows/silverbullet-040-bblakely.pdf gem company www.cigital.com 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. ___
[SC-L] Unicode Security : Microsoft releases BinScope and MiniFuzz to the public
FYI, a couple of interesting developments in the software security tool space: http://www.lookout.net/2009/09/16/microsoft-releases-binscope-and-minifuzz-to-the-public/ Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com SC-L Moderator smime.p7s Description: S/MIME cryptographic signature ___ 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] OWASP Session - Fortify 360 - Thursday, September 17, 2009 (webex available)
SC-L, The Owasp Northern Virginia chapter is pleased to invite you to its next session on Thursday September 17th. We will be hosting a presentation, demo and hands on session of Fortify 360 (http://www.fortify.com). Fortify 360 includes Fortify SCA (Source Code Analyzer) and the Fortify 360 Server which is Fortify's solution for an enterprise deployment of SCA. The session will start with a presentation by Eric Klein (Fortify), followed by a demo and finally a hands on session where the audience will be free to install Fortify SCA on their machine and scan the Webgoat application. The audience will also be introduced with the Fortify 360 Server and try some of the enterprise level features such as collaborative code review, metrics and so on. Bring your laptop if you want to try Fortify 360! For the hands on, bring your laptop, the install takes about 10-15 minutes. We'll have installation files for Windows, Mac and Linux. You can also follow via webex (see below for links) The target audience is anyone interested in Secure Code Review with a Static Analysis tool at the desktop level and/or enterprise level. We will need to register visitors before hand...please email wade.woolw...@owasp.org for registration and confirm attendance. Pizza and refreshments will be served. http://www.owasp.org/index.php/Virginia_%28Northern_Virginia%29#tab=Schedule Location: 22260 Pacific blvd, Sterling, VA. 20166 (AOL Office) Topic: OWASP Session - Fortify 360 Date: Thursday, September 17, 2009 Time: 6:00 pm, Eastern Daylight Time (GMT -04:00, New York) Meeting Number: 487 746 568 Meeting Password: Owasp1 Please click the link below to see more information, or to join the meeting. --- To join the online meeting (Now from iPhones too!) --- 1. Go to https://cigital.webex.com/cigital/j.php?ED=126987157UID=0PW=f26e92a72b1b0a151a5d 2. Enter your name and email address. 3. Enter the meeting password: Owasp1 4. Click Join Now. --- To join the teleconference only --- Call-in toll-free number (US/Canada): 866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf -- ___ Owasp-wash_dc_va mailing list owasp-wash_dc...@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_va ___ Owasp-wash_dc_va mailing list owasp-wash_dc...@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-wash_dc_va ___ 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] Reality Check: Vmware's Kris Inglis
hi sc-l, Turns out lots of different kinds of enterprises are spearheading large scale software security initiatives. VMware has an extensive software security initiative that has leveraged and evolved the EMC approach. Kris Inglis runs the product security group at VMware (what I would term their software security group). We talk about Vmware's approach in episode 8 of Reality Check: http://www.cigital.com/realitycheck/show-008/ Reality Check is syndicated by CSO magazine. 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. ___
Re: [SC-L] Inherently Secure Code?
At 8:47 AM -0700 8/27/09, Benjamin Tomhave wrote: Should any sort of overflow really be allowed? It is not, except by management decision (in choosing an unsafe language). -- Larry Kilgallen ___ 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?
Ben Tomhave wrote: Wall, Kevin wrote: I don't mean to split hairs here, but I think fundamental concept vs intermediate-to-advanced concept is a red herring. In your case of you teaching a 1 yr old toddler, NO is about the only thing they understand at this point. That doesn't imply that concepts like street are intermediate-to-advanced. It's all a matter of perspective. If you are talking to someone with a Ph.D. in physics about partial differential equations, PDEs *are* a fundamental concept at that level (and much earlier in fact). The point is, not to argue semantics, but rather to teach LEVEL-APPROPRIATE concepts. I think you do mean to split hairs, and I think you're right to do so. Context is very important. For example, all this talk about where to fit secure coding into the curriculum is great, but it also ignores the very arge population of self-taught coders out there, as well as those who learn their craft in a setting other than a college or university. Ergo, it still seems like we're talking at ends about an issue that, while important, is still only at best a partial solution. Of course it's only a partial solution and I think you raise some very valid concerns. Normally, I wouldn't consider the self-taught in a discussion of where does secure coding belong in the CURRICULUM, but we can't ignore that 800 lb gorilla either. That of course is a much harder challenge. I suppose in some sense we should expect / hope that these same concepts that we've been discussing are addressed in the numerous books, periodicals, web sites, etc. where most of this learning happens. But that's probably much more difficult sitation to change...more of a wild, wild west in comparison to academia. Ultimately, most sane people act in accordance with that they are rewarded for doing things correct and disciplined for doing wrong. In academia, we can do this with grades for students, pay and/or tenure or other perks for professors / lecturers, etc. But once we get into books and magazines realm, we have to look for the publishers to reward / discipline appropriately and IMO they don't necessarily have the same drivers as to academia. Many publishers seem to be more concerned with just making a quick $$ rather than being accurate or thoroughly training people to do things correctly. (How else can you explain books explain tabloids, unless you subscribe to the MiB theory. And IMHO, there are plenty of tabloid-like publishers writing books in the programming field, but I digress.) Getting back to my point, you don't have that less control for someone putting up their own educational web pages that profess to teach programming to which many of the self-educated seem to rely on. There are plenty good ones, but most I've seen seem to be oblivious to secure coding practice (w/ exception of security-related sites such as OWASP, etc.) So it's only things like reputation, and ultimately market pressures that force any corrective actions in regards to publishers of written and web material. Add to that the problem that BECAUSE these people are self-taught, the generally don't have someone to provide guidance to separate the wheat from the chaff like instructors hopefully do with their students. But if self-taught programmers are the 800 pound gorilla, then corporate business is the 4 ton elephant. If anything, I would say that addressing the pressures that seem to be on corporate programmers that come to bear _against_ secure coding practice (although unintentionally) is the MUCH BIGGER problem. (Most people go into CS to move into industry after all, not to stay and teach/research in academia.) Most businesses rate secure code as a very low need and to emphasize time-to-market (which presumably has a direct correlation to market share, or so we've been told) over everything else. IMHO, that leads to more slip-shod code than any other single factor. Adding defensive code to make it more robust against attacks takes additional time, which on large projects can be quite significant. To make matters worse, many IT shops in the USA seem to reward the how fast can you crank out code (no matter how insecure) over the how good of quality do you deliver mentality. What is rewarded in IT shops is quantity of LOC cranked out each week (wrongly widely perceived as equivalent to productivity) over quality (less buggy code, which I believe correlates well less vulnerabilities). I have no sour grapes here--never wanted to move into management--yet over my 30+ years in industry (mostly telecom), I've seen the fast get rewarded, transfer to another project before things crash-and-burn, and then go on to get promoted to some management position. And then they continue to act this was as managers because that's what got them there. Let's face it, the IT industry in the USA is one huge dysfunctional family. So, I think *that's* why we've been focusing on formal education. There is a chance, a glimmer of
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Yet another perspective. I believe that this question may be somewhat flawed as it doesn't take into consideration certain demographic challenges. Right now the model seems to be based on either being academic (sitting through a semester of some old fog with no real-world experience blabbering theory) or in the professional world and their ability to bring in consultants to perform in-house training (in a highly constrained time crunch). So, if you are an employee of a small software company, how do you learn to write secure code? Academia hasn't yet adjusted to the modern world of professionals where education needs to be a component in work/life balance and not an impediment to it and therefore this isn't really an option for the masses. Likewise, if you aren't employed by a large enterprise with a training budget that can hire all these training firms that want to do onsite classes for dozens of employees, you are left with reading lots of books on your free time, a few OWASP TV videos and google. One of the more interesting experiences that I had was that a professor at RPI uses one of the books I am the lead author for in his class. If I wanted to be a guest lecturer, this would be no problem, yet if I wanted to get credit for the course, I would actually have to sit through the entire thing which would be as interesting as watching paint dry. I have on several occasions made the offer that I will pay for all fees for a given course upfront and I want to take the final exam. If I did not score 100% you could fail me and still no university would take my offer. We got to find a balance between one-day train the world in corporate America and months upon months of mind-numbling indoctrination that universities push if we are to truly conquer the challenge of secure coding. 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] Where Does Secure Coding Belong In the Curriculum?
We are NOT craftsmen by any stretch of the imagination. If you have ever worked in a large enterprise, the ability to change roles and be fluid in one's career is rewarding yet has unintended consequences. If I went to my boss tomorrow and said that I no longer want to be an architect and instead want some experience managing a project, what training do you think I will be afforded before I actually get to project manage a large initiative? For that matter I am an architect, what training do you think I have received? Much of my daily job is art where all of about ten minutes requires craftsmanship. We need to stop being delusional and thinking that us IT folks are bound by ANY principle. If you find a single principle taught in a university setting that hasn't been waived in a corporate environment at one time or another, I sure would love to know what that is. We are artists. End of discussion... From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jim Manico [...@manico.net] Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim ___ 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. ___ 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] Inherently Secure Code?
To be sure, inherently secure code is a misnomer. However, that being said, my original contention was that certain common vulnerabilities should be automatically managed these days rather than relying on explicit code to catch them. Should any sort of overflow really be allowed? I have to believe there are ways to safely trap those - perhaps they result in an abend, but at least not in a manner that achieves the goals of a compromise attempt. Similarly, it seems that there should be ways to force the deserialization and parsing of data that could be safer than allowing raw, unvalidated input to be acted upon. I wonder, too, if part of the error in the curriculum thread is focusing too low-level - that is, instead of focusing just on coding skills, maybe there should also be a larger discussion of publishing frameworks, development environments, etc., that introduce a lot of these security capabilities as inherited properties/functions? Done properly, it would lead to inherently better properties. fwiw. -ben Peter G. Neumann wrote: I don't much like INHERENTLY SECURE CODE. Software components by themselves are not secure. Security (and trustworthiness that encompasses security, reliability, survivability, etc.) is an emergent property of the entire system or enterprise. To say that a component is secure is rather fatuous. See my DARPA report on composable trustworthy architectures for starters. http://www.csl.sri.com/neumann/chats4.pdf or .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 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. ___ -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] We can't solve problems by using the same kind of thinking we used when we created them. Albert Einstein ___ 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] Inherently Secure Code?
I am not sure I agree that this is any more achievable than claiming a bank building should allow all valid customers in, but keep out all thieves. While we can and should make great strides, we will always have some exposure because we have to let some things through. The only way we can have perfectly secure code is to not allow someone to use it. The same is true of bug free code, but that is another argument. :) Isn't this kind of like wanting the evil bit to be set in all malicious packets? Great idea, but not achievable. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Benjamin Tomhave list-s...@secureconsulting.net: we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure. ___ 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?
Personally I think secure coding should be included in the entire curriculum irrespective of the level. People learn habits early on that they tend to carry for as long as they are programmers. How many programmers that learned the KR style of indentation for example continue to use it as their default style even when they have learned new languages. Having just done a quick survey of the programming books on my shelves I don't find security or secure coding covered much if at all. I doubt that is because some business guy came down to the author and told him to excise security from the book. If basic security and secure coding practices are not integrated into programming from the beginning it is an add on, and hence not a natural component of the (art|science) of programming and much easier to skip. I have started teaching my 12 year old son C programming at home. We started off with a basic Hello World, then added his name as a variable, then a loop to print different names, then added the ability to take the name as input from the command line. At each step we added in a bit of exception handling, and once we got to user input data we added basic data and input validation. Each new version of the program had a test plan and had to handle exceptions. This is a very simple example and is not something production ready, but every step showed him how to program without leaving security out. In my opinion, any educational program that deals with computers or networks should have security and secure coding woven into it. The amount and type of secure coding depends on the subject. A management class that calculates costs and ROI of a project should have metrics for the cost of security or robustness failures. Networking classes should have secure configuration integrated. Software engineering/design would need to have appropriate modules on encryption, identity management, etc, etc. In the end I think the question should be: Is there a place where does security and secure coding NOT belong in a curriculum? ___ 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?
Not so much anti-social as untrusting, supicious, and paranoid. Actually, being highly social could provide an excellent cover to fool the bad guys into thinking one is a lot less security-savvy than one actually is. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of McGovern, James F (HTSC, IT) [james.mcgov...@thehartford.com] Sent: Tuesday, August 25, 2009 2:09 PM To: Secure Code Mailing List Subject: [SC-L] Where Does Secure Coding Belong In the Curriculum? There are several perspectives missing from the dialog: - Before we even talk about secure coding, we need a course on secure thinking. Most folks are indoctrinated into thinking positive which blinds them from seeing vulnerabilities right in front of them. A prereq on being antisocial might be a good start ___ 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?
James McGovern wrote... - Taking this one step further, how can we convince professors who don't teach secure coding to not accept insecure code from their students. Professors seed the students thinking by accepting anything that barely works at the last minute. Universities need to be consistent amongst their own teaching/thinking. Well, actually, I think that what Matt Bishop wrote in his response to Benjamin Tomhave is the key: But in introductory classes, I tend to focus on what I am calling robust above; when I teach software security, I focus on both, as I consider robustness part of security. By the way, you can do this very effectively in a beginning programming class. When I taught Python, as soon as the students got to basic structures like control loops (for which they had to do simple reading), I showed them how to catch exceptions so that they could handle input errors. When they did functions, we went into exceptions in more detail. They were told that if they didn't handle exceptions in their assignments, they would lose points -- and the graders gave inputs that would force exceptions to check that they did. Most people got it quickly. That is, Matt suggested a direct reward / punishment. Specifically, if the students don't account for bad input via exceptions or some other suitable mechanism, the simply loose points. Matt's right. If it boils down to grades, most students will get it, and fast. And whether we call this secure-coding, robustness, or simply correctness, it's a start. I think that too many people when they hear that we need to start teaching security at every level of CS are thinking of more complicated things like encryption, authentication protocols, Bell-LaPadula, etc. but I don't think that was where the thrust of this thread was leading. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.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 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] informIT: attack categories
hi sc-l, Fred sent me some email today and reminded me that he has written about this idea himself in IEEE Security Privacy magazine. We already had a link to his article on the Silver Bullet website, but here's a direct link: The Monoculture Risk Put in Context IEEE Security and Privacy 7, 1 (January/February 2009), 14-17. Fred Schneider and Ken Birman. http://www.cs.cornell.edu/fbs/publications/IEEEspMonoculture.pdf gem On 8/25/09 1:35 PM, gem g...@cigital.com wrote: hi sc-l, If you listened recently to the latest episode of Silver Bullet with Fred Schneider from Cornell http://www.cigital.com/silverbullet/show-041/, one of the ideas Fred and I discussed was the notion of attack categories and anticipating large scale trends in attack space. Hopefully you guys all recall that I am a strong proponent of understanding the attacker's perspective (see, for example Exploiting Software from way back in 2004 where Hoglund and I coined the term attack pattern http://exploitingsoftware.com/). This month's informIT article is about the notion of long term attack categories and is meant to inform software security research: Software [In]security: Attack Categories and History Prediction http://www.informit.com/articles/article.aspx?p=1393066 BTW, shout outs for the OWASP top 10 and CWE in the article may surprise the usual nay sayers. Feedback is most welcome. (Thanks to Ken and Sammy for helping me make this article slightly more coherent.) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast 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] informIT: attack categories
hi steve, The bugs/flaw continuum is, in fact, a continuum. It's great that you guys have begun to collect and publish information about flaws in the CWE. I agree completely with your statement I suspect that design/architecture level taxonomies will be very challenging to build. Part of what Fred is trying to spark with his work is some research funding for that area. gem On 8/25/09 6:36 PM, Steven M. Christey co...@linus.mitre.org wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I fully expect to see this reflected in the updated CVE vulnerability trends for 2007/2008, which (fingers crossed) will be released in the next month or so (OK, most of the flaws will be in web apps, but still...) we lack a taxonomy of flaws such as the ones we have for bugs (see the Seven pernicious kingdoms and the CWE). CWE is not just a bug parade, it's also a flaw parade ;-) Although the parts related to flaws don't have the depth or specificity that exists for bugs/faults. The weaknesses introduced during design view CWE-701 actually lists 353 entries. http://cwe.mitre.org/data/lists/701.html ... although there are a lot of weaknesses that you could argue are bugs. For example, is path traversal a bug or a flaw? It probably depends on how file handling is performed within a specific application. Actually, I think the lines between flaws and bugs/faults can get pretty fuzzy. We do want to address CWE's relative lack of depth for flaws, however. The hierarchy in the research view (CWE-1000) may be the best way to peruse where CWE stands. I'd love to hear from others who are working in classification at the flaw level. Current areas of promise under CWE are CWE-227 (API Abuse which has been borrowed from Seven Pernicious Kingdoms and given a little more structure), resource lifecycle issues and control spheres (CWE-664), external control of critical data/variables/systems/clients (CWE-642), protection mechanism failures (CWE-693), and even many of the classic Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental that these areas still need some work, and any/all input is welcome. Use the graph tab on the individual CWE pages to see the sub-hierarchies. Interestingly (or perhaps not), implementation bugs and design/architecture flaws may share some of the same underlying fundamental properties. For example, a bug-level action of setting a variable declaration to public instead of private has some of the same properties as a flaw-level action of creating an open socket that anybody can connect to - you're unintentionally exposing a resource to somebody who shouldn't have any access to that resource at all. Or, as an example of a resource lifecycle problem, a use-after-free implementation bug isn't so different than the flaw in which you continue to use a certificate after it has expired. I suspect that design/architecture level taxonomies will be very challenging to build. For one part, there's a lot less research in the area than implementation bugs (at least the research that I'm aware of), and certainly a lot less public vuln data to draw from (e.g. CVE). There's a lot of stuff on design but not in any easily-packaged form to build a taxonomy, and it's often tied to specific technologies. For another, you have a lot more different perspectives at play. We can look at an unbounded strcpy and say well that's clearly a bug but at the design level, is the problem use of a language that supports arbitrary indexing of arbitrary pointers or use of a risky API function that doesn't perform its own bounds-checking or use of a data structure [string] that does not have expliticly-stated length as a separate field from the buffer or failure to validate input? (The answer may be all of the above or it depends on your perspective, but that's where taxonomy construction gets really hard.) I, for one, can't wait. - Steve ___ 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?
The playing in traffic example is one extreme end of the spectrum. A good analogy for the other end might be physics where you just teach Newtonian theory it as if it were 100% accurate and then, if the student decides to take a relativistic physics class, you teach them on day 1 that everything they know isn't right. It seems teaching secure programming must lie somewhere between these two ends of the spectrum. Perhaps a more useful exercise (rather than debating where in the gradient through metaphor) is to try to enumerate the variables that play into what draws a topic toward one end or the other. Such variables might include: * stickiness of the bias/habits acquired as you learn more * impetus to learn more * ability/access to learn more Just a thought. p. On 8/25/09, Goertzel, Karen [USA] goertzel_ka...@bah.com wrote: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. But that doesn't mean we wait until the kids are 11 or 12 to tell them shouldn't play in traffic. There has to be some way to start introducing the idea even to the rawest of raw beginning programming students that good is much more desirable than expedient, and then to introduce the various properties that collectively constitute good - including security. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? ... ___ 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. ___ -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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?
Matt Bishop wrote: Instead, what you can do is frame the issues as good programming. When teaching for loops, teach the idea of a limit (upper and lower bounds). Then when you get to arrays, it's natural to discuss bounds checking in the context of iteration (I don't phrase it that way, of course). When you grade, you check for it. Presto! Now you have taught what is commonly considered a security requirement without ever mentioning the word security. I would agree with this, as I think it again syncs with what James McGovern talked about earlier, too. A graduated approach to secure coding (for whatever definition we might insert) is the only logical progression. However, as you conceded, we have to be very careful just how much we introduce and when. I remember the disconnect in the mid-90s when the CompSci curriculum switched to OO. Some of us got caught in the blender where our first CS class was non-OO and our 2nd class was suddenly all OO and we didn't know what the heck was going on. It seems we're perhaps still in this transitional state to a large part. By the way, you can do this very effectively in a beginning programming class. When I taught Python, as soon as the students got to basic structures like control loops (for which they had to do simple reading), I showed them how to catch exceptions so that they could handle input errors. When they did functions, we went into exceptions in more detail. They were told that if they didn't handle exceptions in their assignments, they would lose points -- and the graders gave inputs that would force exceptions to check that they did. Let's just hope that the code isn't compiled with -O3 or similar, creating an unintended bug. :) http://isc.sans.org/diary.html?storyid=6820 Most people got it quickly. Getting it and applying it IRL are of course two completely different things. I still find it somewhat absurd that we even need to have this discussion still after how many decades of curriculum development? :) -ben -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Reading is to the mind what exercise is to the body. Sir Richard Steele ___ 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?
Goertzel, Karen [USA] wrote: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. Actually, I'm not teaching my 1 yo toddler much of anything about traffic right now. I'm more playing guardian when she runs around the house and making sure she doesn't get into situations for which she would be completely and totally unprepared (and in serious danger). She lacks the language skills to even marginally understand basic concepts like street let alone don't play in the street. I think this rather proves my point that secure coding is not itself a fundamental concept, but rather an intermediate-to-advanced concept. Matt Bishop's comments are great, but they've also been applied in a context of higher ed., and recognize the limits of student understanding at different phases of development. -ben But that doesn't mean we wait until the kids are 11 or 12 to tell them shouldn't play in traffic. There has to be some way to start introducing the idea even to the rawest of raw beginning programming students that good is much more desirable than expedient, and then to introduce the various properties that collectively constitute good - including security. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? ... -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] That which has always been accepted by everyone, everywhere, is almost certain to be false. Paul Valery ___ 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?
Ben, Let's just hope that the code isn't compiled with -O3 or similar, creating an unintended bug. :) http://isc.sans.org/diary.html?storyid=6820 Brings back memories -- the first day on the job as a summer intern I had to track down a bug in a UNIX device driver. Turned out the optimizer was clobbering a jump -- the driver worked fine unoptimized. I quit believing tools like compilers were flaw-free after that! Most people got it quickly. Getting it and applying it IRL are of course two completely different things. I still find it somewhat absurd that we even need to have this discussion still after how many decades of curriculum development? :) Oh, I don't -- I think it's all too understandable. A story first, to provide some background. One of my grad students (a security type, of course :-)) was my TA for the undergraduate operating systems class. We had the students form teams, and each team modified a kernel. The TA then graded interactively, asking the students about what they did and why, as he went through their code. My TA was appalled at the poor quality of the code of most teams -- it worked, but was not robust and was sloppy. So, he told each group that if they turned in code that poor the next time, he'd deduct 20% on general principles. So what do students do in that case? Right -- complain to the professor (me). I said something to the effect that I strongly disagreed with the TA, and felt he should have handled the situation differently; but since he said he'd only take off 20%, instead of the 40% I would have taken off, I'd support his decision. The students got the message. On the next assignment (and for the res of the class), the code was much better. This suggests to me the problem is not so much a failure to teach robustness; in fact, I suspect most intro to programming teachers do mention it (although to different degrees of thoroughness and probably not using that name). The *real* problem is that we don't keep reinforcing it throughout the student's career. And that's an artifact of a lack of resources for the type of grading. Give classes the support to do this, and I suspect you'd see people get in the habit of writing better code. Better, use students and people from industry who know this stuff to staff a clinic analogous to a writing clinic for English and law schools -- that would reinforce it not just for the students, but for the clinic staff as well. Anyone who's interested in this idea can read about a small experiment I did in a paper at http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/ The results of having students use such a clinic, on a very small scale, led to some pretty good improvements in their code. The problem, of course, is that supporting such a clinic requires a lot of people time, and getting people to donate their time, or the resources (read: cash) to pay for it, isn't easy. Matt ___ 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?
Matt Bishop wrote: And that's an artifact of a lack of resources for the type of grading. Give classes the support to do this, and I suspect you'd see people get in the habit of writing better code. Better, use students and people from industry who know this stuff to staff a clinic analogous to a writing clinic for English and law schools -- that would reinforce it not just for the students, but for the clinic staff as well. This sounds like an excellent extension for OWASP. :) -ben -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] I hope if dogs ever take over the world and they choose a king, they don't just go by size, because I bet there are some Chihuahuas with some good ideas. Deep Thoughts by Jack Handy ___ 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?
So many mistakes have been made in generations before mine that we are now trapped in a box of our own making that has us squabbling over academic minutiae like how to teach secure coding when we should not have to consider this topic at all - the code itself should be inherently secure. This is the comment that agrees with my own belief. When teaching how to program secure coding should be seen as inherent in this and not as some sort of optional add that is only required if the code is supposed to secure. Many of the techniques are just making the code more robust and this covers a considerable amount of the problems with code today. I see no reason that this shouldn't be taught as part of any programming course. Does this cover all secure coding, no of course not, but unless the foundations of secure implementation is inherent then more advance issues ar the least of the communities worries. Consider the environment before printing this mail. Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmas...@thales-esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited. ___ 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?
Brad Andrews writes... I had proofs in junior high Geometry too, though I do not recall using them outside that class. I went all the way through differential equations, matrix algebra and probability/statistics and I don't recall much focus on proofs. This was in the early 1980s in a good school (Illinois), so it wasn't just modern teaching methods that were too blame. I am not sure that the proofs were all that useful for understanding some things either, though the logic they taught has value that I missed a bit of since I did hit some modern techniques. This may be heading slightly OT, but I don't think your experience is really that unusual. My BS was a double major in math and physics and my MS was in CS. We used proofs in most of my math classes, many of my physics classes, and several of my CS classes. Besides the frequency, what varied in each of these was the level of rigor expected. The proofs in math were extremely rigorous, the ones in physics less so, and the ones in most of my CS classes would have been classified as only so much hand waving if they would have been done in my math classes. But an important thing to note in all of these courses was, with the exception of very few advanced (senior grad level) math classes such as advanced calculus and abstract algebra and number theory, the use of 'proofs' wasn't the end, but only a means to the end. But still 'proofs' were utilized throughout much of this very diverse coursework to add to the rigor of the logic and presumably to reinforce understanding and learning. In the same way, I think that 'security' (or 'robustness' or 'correctness' or whatever you wish to call it) needs to be CONSISTENTLY blended into the college and possibly even high school CS curriculum so some element of it is touched upon in each of the classes and as one progresses it is discussed more and more. So just as 'proofs' are sprinkled into math, physics, CS, etc. we need to sprinkle in basic security / robustness concepts such as: + An understanding of what input may be 'trusted' and what inputs cannot be trusted leading to the concept of trust boundaries. + The concept of correctness extends merely past handling 'correct' input and needs to somehow gracefully handle incorrect input as well. + Understanding the concept of risk, eventually leading to an understanding of risk analysis in upper level CS courses + Having an adversarial testing mindset, always thinking how can I 'break' this program or system?. (BTW, sad to say, this has probably been the hardest thing to teach my colleagues. Some of them seem to get it, and some of them never do.) There are probably others--this is by no means a complete list--but we need to emphasize that to those instructing CS that this is not going to take up a significant portion of their coursework nor require a significant amount of time or effort on there part. Rather it needs to be folded into the mix as appropriate. I think back to my days in elementary mathematics. I recall learning at a very early age, when learning division, that you can't divide by 0. The explanation given by the teach wasn't in depth, it was more like you are just not permitted to do that, or occasionally it's undefined without telling us WHY it's undefined. In a similar manner, we can teach don't blindly accept unchecked input, etc. And then if that is reinforced in the grading process I do think it will come through. Surely if we could just do that much, it would be a good start. But my observation, based on my CS colleagues that I've taught with and before that, the CS courses that I've taken at the graduate level, is that other than the obligatory half hour mention of security in my operating systems course, I can barely recall it ever even coming up. And I also seldom recall that instructors would every toss your programs truly malformed input either. By comparison, when I had an opportunity to teach a masters level CS course on distributed systems (the Tannenbaum book), I tossed in matters of security throughout, not just in the chapters about security. Of course, I don't think until we got to the chapters about security that the students realized that's what I was teaching them, but that's OK too. The subliminal methods sometimes work as well. -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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,
Re: [SC-L] informIT: attack categories
Gary, Great article and since you used attacks and categories in the same :) sentence I am tempted to ask if you looked at WASC Threat Classification project? On Tuesday, August 25, 2009, Steven M. Christey co...@linus.mitre.org wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I fully expect to see this reflected in the updated CVE vulnerability trends for 2007/2008, which (fingers crossed) will be released in the next month or so (OK, most of the flaws will be in web apps, but still...) we lack a taxonomy of flaws such as the ones we have for bugs (see the Seven pernicious kingdoms and the CWE). CWE is not just a bug parade, it's also a flaw parade ;-) Although the parts related to flaws don't have the depth or specificity that exists for bugs/faults. The weaknesses introduced during design view CWE-701 actually lists 353 entries. http://cwe.mitre.org/data/lists/701.html ... although there are a lot of weaknesses that you could argue are bugs. For example, is path traversal a bug or a flaw? It probably depends on how file handling is performed within a specific application. Actually, I think the lines between flaws and bugs/faults can get pretty fuzzy. We do want to address CWE's relative lack of depth for flaws, however. The hierarchy in the research view (CWE-1000) may be the best way to peruse where CWE stands. I'd love to hear from others who are working in classification at the flaw level. Current areas of promise under CWE are CWE-227 (API Abuse which has been borrowed from Seven Pernicious Kingdoms and given a little more structure), resource lifecycle issues and control spheres (CWE-664), external control of critical data/variables/systems/clients (CWE-642), protection mechanism failures (CWE-693), and even many of the classic Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental that these areas still need some work, and any/all input is welcome. Use the graph tab on the individual CWE pages to see the sub-hierarchies. Interestingly (or perhaps not), implementation bugs and design/architecture flaws may share some of the same underlying fundamental properties. For example, a bug-level action of setting a variable declaration to public instead of private has some of the same properties as a flaw-level action of creating an open socket that anybody can connect to - you're unintentionally exposing a resource to somebody who shouldn't have any access to that resource at all. Or, as an example of a resource lifecycle problem, a use-after-free implementation bug isn't so different than the flaw in which you continue to use a certificate after it has expired. I suspect that design/architecture level taxonomies will be very challenging to build. For one part, there's a lot less research in the area than implementation bugs (at least the research that I'm aware of), and certainly a lot less public vuln data to draw from (e.g. CVE). There's a lot of stuff on design but not in any easily-packaged form to build a taxonomy, and it's often tied to specific technologies. For another, you have a lot more different perspectives at play. We can look at an unbounded strcpy and say well that's clearly a bug but at the design level, is the problem use of a language that supports arbitrary indexing of arbitrary pointers or use of a risky API function that doesn't perform its own bounds-checking or use of a data structure [string] that does not have expliticly-stated length as a separate field from the buffer or failure to validate input? (The answer may be all of the above or it depends on your perspective, but that's where taxonomy construction gets really hard.) I, for one, can't wait. - Steve ___ 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. ___ -- Thanks Regards, Prasad N. Shenoy ___ 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?
On Aug 25, 2009, at 8:16 PM, Olin Sibert wrote: Exploits are FUN. I agree, at least to a point. Whenever I work exploits into my workshops, the results are right on the mark. So long as the exploits are balanced with just the right amount of remediations, it works great. The key is to hook the students with the exploits, and then sprinkle in a now here's how to do it _right_ discussion while they're still paying attention. ;-) And FWIW, I've found OWASP's WebGoat to be phenomenally effective at doing just that. There are other similar tools out there as well, but the point is to give the class a safe sandbox to play in. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) smime.p7s Description: S/MIME cryptographic signature ___ 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] informIT: attack categories
At 6:36 PM -0400 8/25/09, Steven M. Christey wrote: Gary, You said in the article: The next category of attacks to expect are attacks that target defects in design and architecture - which I call flaws. I think it's already happening. I think it has been happening for years. I use Microsoft Word V5.1a from 1992, because Microsoft followed that with Word 6.0 which introduced the design defect allowing Macro Viruses. Of course this was not actually an innovation, as IBM had previously introduced _and_withdrawn_ a similar vulnerability in their CMS operating environment (the mail program would automatically call a text formatter which could call the operating system under the direction of the sender. Those who do not study history are condemned to repeat it. -- Larry Kilgallen ___ 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?
Your example is spurious as a refutation of what I was trying to say (as I suspect you already know). Obviously you're not going to try to teach a not-yet-verbal infant a self-preservation concept that requires even the most rudimentary reasoning. That said, I'll be interested to hear from you in, say, a year and a half from now. And I still maintain that the intellectual maturity of a two-and-a-half-year-old hardly constitutes intermediate-to-advanced EXCEPT possibly when compared with that of a one-year-old. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Wednesday, August 26, 2009 12:27 AM To: Goertzel, Karen [USA] Cc: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Goertzel, Karen [USA] wrote: We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. Actually, I'm not teaching my 1 yo toddler much of anything about traffic right now. I'm more playing guardian when she runs around the house and making sure she doesn't get into situations for which she... ___ 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 too remember learning proofs in Jr. High. And I also believe the main objective was to teach 12 and 13 year olds that it is possible to apply a repeatable, disciplined process to how they approach problem solving. Certainly not a worthless lesson, even if the mathematics involved are never used again. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews [andr...@rbacomm.com] Sent: Tuesday, August 25, 2009 4:23 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I had proofs in junior high Geometry too, though I do not recall using them outside that class. I went all the way through differential equations, matrix algebra and probability/statistics and I don't recall much focus on proofs. This was in the early 1980s in a good school (Illinois), so it wasn't just modern teaching methods that were too blame. I am not sure that the proofs were all that useful for understanding some things either, though the logic they taught has value that I missed a bit of since I did hit some modern techniques. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI ___ 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 see your point. On the other hand, there are times I worry that teach the hacker mentality approach to secure development training smacks a bit too much teaching future policemen the delights of robbery, rape, torture, and murder in order to prepare the to defend the public against robbers, rapists, torturers, and murders. Definitely teach - with examples - what it is about software that makes it so easy to exploit and violate. But stop short of handing the students detailed blueprints and instructions, reinforced by lots of hands-on lab time. I'm just untrusting enough of human nature to worry that once some of them discover how much more fun it is to hack than to defend against hacking, what you'll end up with is not the next Bob Seacord but the next Kevin Mitnick. At the very least, make psychological exams a prerequisite of acceptance into your class, so you can weed out the likely psychopaths and sociopaths. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Olin Sibert [u3...@siliconkeep.com] Sent: Tuesday, August 25, 2009 8:16 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I'm mostly a lurker here, and I'm a practitioner rather than a professional educator, but there's a viewpoint I haven't seem much of that I want to support, namely: Exploits are FUN. Teach from that angle, and I think you'll get more traction ___ 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?
Your Picasso - or, perhaps, Frank Lloyd Wright would be a better analogy - definitely has a role in software development. I want his creativity up front in the specification and high-level design of the building (the software system). But when it comes to detailed design and testing, I'm going to call in the engineers, and when it comes to coding, no-one does it better than skilled construction workers who have mastered the use of hammers, saws, adzes, etc. So yes - the coders are craftsmen. But the problem is that in software development, the roles are seldom so clearcut, especially not in Agile development. So one does find far too many craftsmen attempting the engineers' and architects' jobs without anything like the necessary training and certification of their competence to perform those functions. Or maybe, if we accept the software development as an art analogy, our problem is we have way too many architects trying to code successfully. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jim Manico [...@manico.net] Sent: Tuesday, August 25, 2009 11:17 PM To: Benjamin Tomhave Cc: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science Keep your Picasso out of my coding shop, world of discrete mathematics and predicate logic! I don't care how cheap his hourly is. :) I'd prefer to think of coders as craftsman; we certainly are not artists, scientists or engineers. ;) And craftsman are bound by the laws of mathematics and the sponsors who pay us, artists have no bounds. - Jim ___ 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] Functional Correctness
Well, this topic gets muddy pretty quickly since I agree with many of the comments made on this thread. We have to be careful with hype and claims made by new models (BSIMM and OpenSAMM in particular) since depending on how the 'rest of the world' sees them speaks directly to our credibility as industry experts. I've tried hard when presenting OpenSAMM to fully claim that the model is chocked full of value judgements about what organizations SHOULD be doing to make a justified argument (qualitatively) that the software they produce has a degree of assurance built-in. Is it a guarantee? No. Is it still valuable? Absolutely. Before, we had no ability to make an apples-to-apples comparison between two organizations, and the model helps that. We also didn't know how to quantify iterative improvement very well or explain the breadth of the software security problem to people either, and OpenSAMM helps that too. I disagree with the remark that maturity models are only useful to companies starting with nothing, because I've seen firsthand how OpenSAMM has helped people (already doing a lot for assurance) think through aspects of the software security problem that fell outside their tunnel-vision. Now, on to the sticky topic of value judgements. Based on how I've seen the BSIMM presented, one might think that at face value, it is somehow more free of author/contributor value judgements than OpenSAMM or other secure SDLC models (I've read several articles referring to these as 'alchemy'). This is simply not true. I, for one, agree with Brad that claims of a scientific nature need to be extremely carefully qualified. At the end of the day, we don't yet know enough about practical methods for improving software security that have much justification beyond what experts think amounts to a 'good thing' (excepting formal methods, of course, but I did say practical :). This is the case for both BSIMM and OpenSAMM. I welcome comments/questions/flames. p. On 8/22/09, Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com wrote: Brad Andrews Writes: After all, we can just implement this maturity model and eliminate all our security problems, at least in the application, right? That is likely to end up resulting in even more resistance in the future when management questions why they need to keep spending more for software security, a secure architecture, etc. Don't people learn what they need to know at some point? I don't thinks that's ever been the case that you can just apply your model and all will be well Microsoft didn`t release their SDL and said there all our software will now be secure, they're constantly evolving their processes. Also some of the activities within the BSIMM are about constant improvement and keeping up with the latest trends, so even just following the BSIMM your processes are never static. I don't think we will ever be static. As soon as we remove the low hanging fruit, the fruit higher up the tree will be the problem. Or, the fruit on another tree :) who's attacking the OS now when the apps are so easy to attack This isn't to say a maturity model is useless, but I remain skeptical that it will live up to the hype (low key now, but there) it is being presented with. I think that the models (both BSIMM and OSAMM) help to provide a framework and a direction to those that have no real security practices at all. Or allow a measurement of existing process and see where their weaknesses are. That and the senior management like the pretty graphs even if they don't know what it means :D CJC -- ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ ___ 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] OWASP Podcast August Update
Hello SC-L! The OWASP Podcast Series continues to accelerate! We released 5 podcasts this month which I hope you find to be of value. 39August 25, 2009Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_39.mp3 | Show Notes /index.php/Podcast_39Interview with Gunnar Peterson (Webservices)38August 25, 2009Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_38.mp3 | Show Notes /index.php/Podcast_38Interview with the OWASP Global Education Committee37August 22, 2009*Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_37.mp3 * | Show Notes /index.php/Podcast_37Interview with Jason Lam and Johannes Ullrich (SANS Institute)36August 15, 2009Listen Nowhttp://www.owasp.org/download/jmanico/owasp_podcast_36.mp3 | Show Notes /index.php/Podcast_36May 2009 News Commentary Recorded July 23 with Boaz Gelbord, Andre Gironda, Jason Lam, Jim Manico, Alex Smolen, Ben Tomhave, Andrew van der Stock and Jeff Williams (part 2)35August 4, 2009Listen Now http://www.owasp.org/download/jmanico/owasp_podcast_35.mp3 | Show Notes /index.php/Podcast_35Interview with Anton Chuvakin, Ph.D (PCI) Faster than a speeding bullet *winks*, the OWASP Podcast Serieshttp://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Showsis bringing on 2 additional hosts, is spawning a Spanish AppSec podcast series, and will be releasing interviews from Andy Steingruebl (PayPal), David Rice (Geekonomics), and the DC AppSec crowd (Acronyms) in September. Ken, please forgive me for ignoring your advice to slow down. ;D Aloha to all of SC-L and thank you for listening. -- Jim Manico jim.man...@aspectsecurity.com jim.man...@owasp.org ___ 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?
On Aug 25, 2009, at 02:35, Benjamin Tomhave wrote: First, security in the software development concept is at least an intermediate concept, if not advanced. Not at all. That would be like saying that correctness is also an advanced concept, because it gets in the way of coding. Security is about exploiting assumptions (often hidden) that we make when we write and deploy software. I see no reason why teaching to think about assumptions should be deferred. You teach math students how to do proofs right from the beginning for essentially the same reasons :-) Perhaps this means that the language itself needs to require strong type checking that enforce appropriate secure coding behavior? Unfortunately, security assumptions are rarely written down so I don't see how they can be enforced at the language or compiler level. Best, Stephan ___ 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?
For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Great strategy! Our hacker friends will love it. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Monday, August 24, 2009 8:35 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced ___ 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?
On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote: You don't teach proofs - not really. The elementary and junior high curriculum generally does not contain anything about proofs I was talking about college students because that's when I was properly taught programming. That may no longer be true. But in maths, I *was* taught how to do proper proofs in high school (from 7th grade on, when we had Geometry). I may have been unusually lucky. I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science. It increasingly makes sense given the failures up to this point. The problem then is that every Joe, Dick, and Harry out there who can get hello world to compile think they're artists. Seriously, unlike art, programming is usually not a vehicle for one's creative urges, but a tool to get a job done, as you yourself say. (I hesitate to use the word science as an antonym to art here, perhaps craft would be better.) Unfortunately, security assumptions are rarely written down so I don't see how they can be enforced at the language or compiler level. Here you make a patently bad assumption yourself. It should be possible for the compiler to automatically protect against overflows, as an example. Sure, for certain languages and certain classes of well-understood problems, compiler or language support can be engineered. But my point stands: security assumptions are rarely written down. This is because they are taken to be self-evident and not in need of explicit formulation. Also, they depend on the domain. If I express a hospital drug disbursal system in any of the common general-purpose programming languages, the assumption that one cannot be a doctor and a nurse at the same time is usually implicit. I challenge you to develop Java or C ++ support that will capture any flaw in the implementation of this particular RBAC *without* having to make that assumption explicit. Safe input validation and output encoding could also be forced at a given level. Really? I'd be interested in hearing about such techniques that cannot be short-cut (which, as you state, is one big factor for security defects in software). Best, Stephan ___ 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?
On Tue, Aug 25, 2009 at 4:09 AM, Stephan Neuhausstephan.neuh...@disi.unitn.it wrote: On Aug 25, 2009, at 02:35, Benjamin Tomhave wrote: First, security in the software development concept is at least an intermediate concept, if not advanced. Not at all. That would be like saying that correctness is also an advanced concept, because it gets in the way of coding. Security is about exploiting assumptions (often hidden) that we make when we write and deploy software. I see no reason why teaching to think about assumptions should be deferred. You teach math students how to do proofs right from the beginning for essentially the same reasons :-) Sarcasmreally? First graders are learning to do math proofs instead of basic addition? I'm quite surprised by this./Sarcasm We're missing I think the point I raised earlier. Not everyone learns to program in high school or college. And, even learning the basics of what an algorithm are is tricky, much less learning defensive programming, etc. So, yes, it is an advanced concept for the majority of beginning programmers. -- Andy Steingruebl stein...@gmail.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] Where Does Secure Coding Belong In the Curriculum?
On Aug 25, 2009, at 18:07, Andy Steingruebl wrote: Sarcasmreally? First graders are learning to do math proofs instead of basic addition? I'm quite surprised by this./Sarcasm Yeah, sorry. When I wrote about students I meant college students. I don't know, is that a difference between British English (pupils) and American English (students)? Anyway, my bad. We're missing I think the point I raised earlier. Not everyone learns to program in high school or college. And, even learning the basics of what an algorithm are is tricky, much less learning defensive programming, etc. But the topic of the thread is Where Does Secure Coding Belong In the Curriculum? and I maintain that when someone is intellectually mature enough so that you can teach them how to program and at the same time really know what they're doing, you can teach them about correctness and security too. Best, Stephan ___ 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?
Ben, First, security in the software development concept is at least an intermediate concept, if not advanced. Riffing on Brad's comments, it seems irrational to think that you can jump straight from structural basics with which many students struggle (OO anybody?) directly to concepts that bridge computer architecture, code structure, and various other problems. I agree and I disagree. If I walked into an ECS 10 (Intro to Programming class) and began We use the waterfall model to provide a moderate level of assurance ... about 75% of the students would be out the door. That's one problem with teaching security per se: you need to describe *what* your security requirements are, and when you're struggling to learn how to write a for loop, being asked to implement security requirements as such is intimidating. Instead, what you can do is frame the issues as good programming. When teaching for loops, teach the idea of a limit (upper and lower bounds). Then when you get to arrays, it's natural to discuss bounds checking in the context of iteration (I don't phrase it that way, of course). When you grade, you check for it. Presto! Now you have taught what is commonly considered a security requirement without ever mentioning the word security. I find the distinction between robust and secure is useful, although often the two are interchangeable. By robust, I mean the more nebulous requirement that the program not crash (although it may terminate gracefully :-)) and that it handle unexpected inputs reasonably, and so forth. By secure, I mean meeting a specific set of requirements that describe what security means; for example, unexpected inputs may require specific actions (in which case handling them is both robust and secure :-)). Note: I'm not sure the distinction here is too meaningful, so please don't ask me to define a boundary. But in introductory classes, I tend to focus on what I am calling robust above; when I teach software security, I focus on both, as I consider robustness part of security. By the way, you can do this very effectively in a beginning programming class. When I taught Python, as soon as the students got to basic structures like control loops (for which they had to do simple reading), I showed them how to catch exceptions so that they could handle input errors. When they did functions, we went into exceptions in more detail. They were told that if they didn't handle exceptions in their assignments, they would lose points -- and the graders gave inputs that would force exceptions to check that they did. Most people got it quickly. Matt ___ 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?
The just get the bloody thing to work is usually an attitude foisted on developers by the business side. I work in an internal application security function for a large enterprise and i'm yet to meet a developer who wasn't concerned about security. Developer education is very important and we have a lot of it available for out developers, some of it even compulsory. However, unless there is the will of the business behind it, developer concerns are oft pushed aside in the interest of expediency. I find the business side usually does have a genuine interest in security and quality, however they are concepts that remain largely unquantifiable, and in the case of security you only need to mess up once to end up with a nasty situation. It's can be a tough sell getting time to focus on these things, given they can be so vague. In the case of my organisation, business side support comes from both internal advocacy of security practises by our function and externally imposed legal requirements. Mostly the latter ;) Filtering inputs is NOT hard, and most developers are getting better at things like that. However, the problems of application security go beyond the developer level, and it's important not to lose sight of that fact. If there were an easy solution everything would already be perfectly secure. Pete On Wed, Aug 26, 2009 at 12:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Great strategy! Our hacker friends will love it. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Benjamin Tomhave [list-s...@secureconsulting.net] Sent: Monday, August 24, 2009 8:35 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Two quick comments in catching up on the thread... First, security in the software development concept is at least an intermediate concept, if not advanced ___ 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] Where Does Secure Coding Belong In the Curriculum?
We teach toddlers from the time they can walk that they shouldn't play in traffic. A year or two later, we teach them to look both ways before crossing the street. Even later - usually when they're approaching their teens, and can deal with grim reality, we give examples that illustrate exactly WHY they needed to know those things. But that doesn't mean we wait until the kids are 11 or 12 to tell them shouldn't play in traffic. There has to be some way to start introducing the idea even to the rawest of raw beginning programming students that good is much more desirable than expedient, and then to introduce the various properties that collectively constitute good - including security. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Andy Steingruebl [stein...@gmail.com] Sent: Tuesday, August 25, 2009 1:14 PM To: Goertzel, Karen [USA] Cc: Benjamin Tomhave; sc-l@securecoding.org Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? On Tue, Aug 25, 2009 at 7:26 AM, Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: For consistency's sake, I hope you agree that if security is an intermediate-to-advanced concept in software development, then all the other -ilities (goodness properties, if you will), such as quality, reliability, usability, safety, etc. that go beyond just get the bloody thing to work are also intermediate-to-advanced concepts. In other words, teach the goodness properties to developers only after they've inculcated all the bad habits they possibly can, and then, when they are out in the marketplace and never again incentivised to actually unlearn those bad habits, TRY desperately to change their minds using nothing but F.U.D. and various other psychological means of dubious effectiveness. Seriously? We're going to teach kids in 5th grade who are just learning what an algorithm is how to protect against malicious inputs, how to make their application fast, handle all exception conditions, etc? ... ___ 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] Grading Secure Programs
On Aug 21, 2009, at 12:18 PM, Brad Andrews wrote: This brings up a great point. How can we grade a program's security level? Is it just a checkoff list? Which elements should be in that checkoff list? You may be interested in reading: Teaching Secure Programming IEEE Security and Privacy archive Volume 3 , Issue 5 (September 2005) table of contents Pages: 54 - 56 Year of Publication: 2005 ISSN:1540-7993 Authors Matt Bishop University of California, Davis Deborah A. Frincke Pacific Northwest National Laboratory Publisher IEEE Educational Activities Department Piscataway, NJ, USA ___ 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 was thinking of a beginner-level programming class. I have and it can be a challenge, especially if they don't have the programming mindset. Even if they do, you don't have the time for the things you spoke about. You are focusing on basic coding constructs first. :) -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Stephan Neuhaus stephan.neuh...@disi.unitn.it: On Aug 21, 2009, at 17:51, Brad Andrews wrote: Has anyone who holds to this taught a beginning level programming class? I have. I taught a security class to undergrads. It was easier than I thought, at least the basics were. I got them excited by a let's try to break things attitude. They wrote buffer overflow exploits (using freely available shellcode), they cracked linear congruential PRNGs, they subverted insecure protocols. As far as I can tell, they had a good time, since I had the highest retention rate for optional courses in that year: 40 signed up for the course and 39 took the final exam. Once they understood that the right mind-set is not oh come on, what can possibly go wrong? but okay, let's see what *can* go wrong, they were on their way. Stephan ___ 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] Functional Correctness
Now that you mention it I was listening to the CERT podcast where you and a couple of others discussed the BSIMM (probably a while back since I am well behind on those). You made a statement along these lines and I immediately thought that I disagreed! :) I don't think software security is as simple as that. I do agree that companies can (and should) do far more than they do and that many things could be eliminated with very mechanical fixes, but I don't think that gives a good long-term perspective. I also think that it will set management's expectation at a level that will ultimately be harmful. After all, we can just implement this maturity model and eliminate all our security problems, at least in the application, right? That is likely to end up resulting in even more resistance in the future when management questions why they need to keep spending more for software security, a secure architecture, etc. Don't people learn what they need to know at some point? I don't think we will ever be static. As soon as we remove the low hanging fruit, the fruit higher up the tree will be the problem. This isn't to say a maturity model is useless, but I remain skeptical that it will live up to the hype (low key now, but there) it is being presented with. I am sure this is not as smoothly presented as it needs to be, but I am fairly certain of the general thrust of my conviction. I suppose 20+ in software development helps. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Gary McGraw g...@cigital.com: Software security is an intensely practical problem that will require a practical approach. By studying organizations that are doing a decent job, perhaps we can draw some practical lessons. That's precisely what we're up to with the BSIMM http://bsi-mm.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] What is the size of this list?
Actually, we can't prove programs are bug free if by bug we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything right in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews [andr...@rbacomm.com] Sent: Friday, August 21, 2009 11:41 AM To: sc-l@securecoding.org Subject: Re: [SC-L] What is the size of this list? I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can prove programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a flawless piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI [snippety snip] ___ 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] Functional Correctness
We are approaching huge industry-wide application security critical mass for the first time. Now is the time to strike. If all we teach is input validation+canonicalization, query parameterization, and output encoding, we stop xss and sqli via education Jim Manico On Aug 21, 2009, at 11:54 AM, Brad Andrews andr...@rbacomm.com wrote: I completely agree, though how are we really going to reach this point? We have been talking about this at least since I got into development in the early 1980s. We are not anywhere closer, though we have lots of neat tools that do lots of neat stuff. Unfortunately, our programs are also a lot more complicated, making the correct proof much more difficult. Can we really believe it is just around the corner to prove this? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com: Martin Gilje Jaatun wrote: Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. ___ 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] What is the size of this list?
Great points Karen! We can't prove a program is secure in the same vein. The danger I am spouting off about is the idea that we would solve the software security problem if we just take a more scientific or mature (or whatever) approach. I think those can definitely reduce the risk, but I don't think it will reach the goal. I am all for getting 50% of the way there. That is a lot better than being 0% or even 25% of the way there! I am just VERY concerned that if we try to sell management the idea that we are now taking a scientific approach (or whatever the term), we will end up with implied promises that will lead them to expect perfection, which won't come. They will likely ignore all our disclaimers that we are only seeking a partial solution to what we can solve, at least in the current state of thinking. Getting them to even take any action is a challenge in many companies, so some could argue my concerns are foolish. I think they are important because you want to make sure any buy-in you eventually get expects the right things. If you don't do this, you will end up in an even worse position down the road. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Goertzel, Karen [USA] goertzel_ka...@bah.com: Actually, we can't prove programs are bug free if by bug we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything right in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. ___ 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?
Are there any industry metrics that indicate what percentage of full-time software developers actually learned coding in a university setting? I actually learned in high-school, focused on business administration in college (easiest major on the planet) and learned/matured on the job. Likewise, I also am surrounded by many folks who have been in IT for say 30 or so years that learned coding from those infomercial type schools you see on TV late at night. So, the question of whether trade schools should teach secure coding should be asked as well. 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] Where Does Secure Coding Belong In the Curriculum?
Andy Steingruebl wrote: I think our real question isn't just how to reach the professional programmer trained via formal training programs, but also how to reach the amateur programmer trained via books, trial+error, etc. One area here is making sure examples are done correctly. The database examples that connected to an MS SQL server with userid=SA;password= used to drive me crazy. The sample code does it that way so I better do it that way. It makes for more complicated sample code but it may be the only way to reach these self taught folks. -- Mike Lyman mly...@west-point.org ___ 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?
Brad Andrews wrote: Has anyone who holds to this taught a beginning level programming class? Getting students to understand what a loop is can be hard enough, given limited time. Diving into exploits and buffer overflows can be much more difficult. Getting into exploits at this level is probably more than many can handle but it's not a bad time to teach proper bounds checking and making sure any math operations don't result in overflows. Part of the lesson might even be to create loops with math that cause these errors deliberately if students are no longer taught how numbers are represented in memory and what happens when you exceed the limits directly. Might not be a bad idea though to step back on basic courses and rather than dive in to programing concepts right away start with some demonstrations of what happens with bad code and follow up with refreshers periodically through the course. Nothing in great depth unless the students can handle it but showing them what happens after coding errors might raise awareness and start them thinking what happens when this breaks rather than strictly focusing on how do it get it to work. I cringe at the thought of what I used to do in code based on the habits that started in high school and college. I am sure some things could be put into a basic class, but the ideas are a bit deeper. Security at the Hello World! or Mortgage Calculator program level seems quite difficult. This bears some thinking through, but the security risks seem to be: - Make sure the input amount is in dollars. - Make sure the term is numeric and within reasonable ranges. - Make sure that interest rate is in the form of XX.XX. That's a great start at getting them to think about how they have to treat input and validate it. I don't recall any of my instructors ever focusing on making sure the input to anything is what was expected. I'm sure some did but I don't recall it. Even if the students don't always get it right at this point, get them started thinking about it. Where do you inject security there? Sure, you can note the importance of checking the data, but just because someone checks the input here doesn't mean they will have a clue on checking the input on a web form for an SQL injection attempt. You might not touch on this until you get to those type applications. If they were taught to question input all along though, by time you get to something like this the habit might be forming. -- Mike Lyman mly...@west-point.org ___ 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?
Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. A much-too-late entry for the bumper sticker contest we had here a few years back: Works as you wish, under all condish. (Okay, okay, so maybe that kind of abbreviating is a bit out of style... by 70 years or so) -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume other info. ___ 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?
Karen Goertzel wrote... I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. Except, unfortunately, as an industry / profession, we can't even get the far-simpler (IMO) _functional correctness_ right let alone (so-called) non-functional issues such as security, safety, fault tolerance, etc. (Mathematical rigor and proof-of-correctness aside, but in many [most?] cases that's not practical and even if it were, most programmers' brains turn to mathematical mush whenever they see any kind of correctness proof. Meaning that it ain't going to happen if it requires thinking. ;-) In some regard, I think this holds things back. If we don't do a good job testing that the software does all that it's supposed to do under *ideal* conditions, how are we ever to expect developers and testers to test to make sure that the software doesn't do additional things that it's NOT supposed to do under less than ideal conditions. There's a reason why Ross Anderson and Roger Needham talked about Programming Satan's Computer (see http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf). [Yes, I 'm aware that paper was about the correctness of distributed cryptographic protocols, but I think both Anderson and Needham would agree that the term Programming Satan's Computer applies more generally than just to that narrow aspect of security.] Not that I'm advocating of giving up, mind you. If the battle seems hopeless, perhaps we would see more progress if we were to address secure programming issues simply as a related aspect of program correctness. Why? Because the development community seems to be more willing to address those things. (Obviously, part of that is that many programming flaws are rather tangible and something that casual users can experience. Yeah! That's the ticket. Let's teach the general populace how to hack into systems! Pass out free You've been pwnd! T-shirts with every successful pwnage. Now *THAT* would be devious. ;-) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.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 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] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)
Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. I couldn't agree more! However, I have had several discussions with a colleague who is fairly well known in theSoftware Process Improvement Mafia on the topic of how to ensure that security requirements are considered for _all_ kinds of code, not just security software. Particularily in the context of agile development techniques, security keeps getting the short end of the stick, losing every time to working features. His stance on this is that if security were important to the customer, the customer would provide and prioritize security requirements. To me, this is a bit like saying If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it. If we can brainwash the coming generations of programmers into accepting Karen's definition of quality code, we might finally be getting somewhere. -Martin ___ 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?
Here's an extract from the Information Assurance Technology Analysis Center (part of DTIC) Software Security Assurance: A State of the Art Report (http://iac.dtic.mil/iatac/download/security.pdf): Courses on secure software development, secure programming, etc., typically begin by introducing common attacks against software-intensive information systems and the vulnerabilities targeted by those attacks, then progress to modeling, design, coding, and testing practices that software developers can adopt to reduce the likelihood that exploitable vulnerabilities will appear in the software they produce. The following is a representative sampling of such courses: - Arizona State University: Software Security - Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems - Carnegie Mellon University (CMU) and University of Ontario (Canada): Secure Software Systems - George Mason University: Secure Software Design and Programming - George Washington University: Security and Programming Languages - Catholic University of Leuven (Belgium): Development of Secure Software - New Mexico Tech: Secure Software Construction - North Dakota State University: Engineering Secure Software - Northeastern University: Engineering Secure Software Systems - Northern Kentucky University, Rochester Institute of Technology, and University of Denver: Secure Software Engineering - Polytechnic University: Application Security - Purdue University: Secure Programming - Queen’s University (Kingston, ON, Canada): Software Reliability and Security - Santa Clara University: Secure Coding in C and C++ - University of California at Berkeley, Walden University (online): Secure Software Development - University of California at Santa Cruz: Software Security Testing - University of Canterbury (New Zealand): Secure Software - University of Nice Sophia-Antipolis (Nice, France): Formal Methods and Secure Software - University of Oxford (UK): Design for Security - University of South Carolina: Building Secure Software. As noted earlier, other schools offer lectures on secure coding and other software security relevant topics within their larger software engineering or computer security course offerings. At least two universities - the University of Texas at San Antonio and University of Dublin (Ireland) - have established reading groups focusing on software security. As part of its Trustworthy Computing initiative, Microsoft Research has established its Trustworthy Computing Curriculum program [309] for promoting university development of software security curricula. Interested institutions submit proposals to Microsoft, and those that are selected are provided seed funding for course development. Another recent trend is post-graduate degree programs with specialties or concentrations in secure software engineering (or security engineering for software-intensive systems). Some of these are standard degree programs, while others are specifically designed for the continuing education of working professionals. The following are typical examples: - James Madison University: Master of Science in Computer Science with a Concentration in Secure Software Engineering - Northern Kentucky University: Graduate Certificate in Secure Software Engineering - Stanford University: Online Computer Security Certificate in Designing Secure Software From the Ground Up - University of Colorado at Colorado Springs: Graduate Certificate in Secure Software Systems - Walden University (online): Master of Science in Software Engineering with a Specialization in Secure Computing - University of Central England at Birmingham: Master of Science in Software Development and Security - Chalmers University (Gothenburg, Sweden): Master of Science in Secure and Dependable Computer Systems. In another interesting trend (to date, exclusively in non-US schools), entire academic departments - and in one case a whole graduate school—are being devoted to teaching and research in software dependability, including security, e.g.: - University of Oldenburg (Germany) TrustSoft Graduate School of Trustworthy Software Systems - Fraunhofer Institute for Experimental Software Engineering (IESE) (Kaiserslautern, Germany): Department of Security and Safety - Bond University (Queensland, Australia): Centre for Software Assurance. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw [...@cigital.com] Sent: Thursday, August 20, 2009 2:55 PM To: Neil Matatall; Secure Code Mailing List Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of Software Security http://swsec.com. Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Everyone, Thank you for all of the input. Really. This information has been extremely helpful! Neil Goertzel, Karen [USA] wrote: Here's an extract from the Information Assurance Technology Analysis Center (part of DTIC) Software Security Assurance: A State of the Art Report (http://iac.dtic.mil/iatac/download/security.pdf): Courses on secure software development, secure programming, etc., typically begin by introducing common attacks against software-intensive information systems and the vulnerabilities targeted by those attacks, then progress to modeling, design, coding, and testing practices that software developers can adopt to reduce the likelihood that exploitable vulnerabilities will appear in the software they produce. The following is a representative sampling of such courses: - Arizona State University: Software Security - Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems - Carnegie Mellon University (CMU) and University of Ontario (Canada): Secure Software Systems - George Mason University: Secure Software Design and Programming - George Washington University: Security and Programming Languages - Catholic University of Leuven (Belgium): Development of Secure Software - New Mexico Tech: Secure Software Construction - North Dakota State University: Engineering Secure Software - Northeastern University: Engineering Secure Software Systems - Northern Kentucky University, Rochester Institute of Technology, and University of Denver: Secure Software Engineering - Polytechnic University: Application Security - Purdue University: Secure Programming - Queen’s University (Kingston, ON, Canada): Software Reliability and Security - Santa Clara University: Secure Coding in C and C++ - University of California at Berkeley, Walden University (online): Secure Software Development - University of California at Santa Cruz: Software Security Testing - University of Canterbury (New Zealand): Secure Software - University of Nice Sophia-Antipolis (Nice, France): Formal Methods and Secure Software - University of Oxford (UK): Design for Security - University of South Carolina: Building Secure Software. As noted earlier, other schools offer lectures on secure coding and other software security relevant topics within their larger software engineering or computer security course offerings. At least two universities - the University of Texas at San Antonio and University of Dublin (Ireland) - have established reading groups focusing on software security. As part of its Trustworthy Computing initiative, Microsoft Research has established its Trustworthy Computing Curriculum program [309] for promoting university development of software security curricula. Interested institutions submit proposals to Microsoft, and those that are selected are provided seed funding for course development. Another recent trend is post-graduate degree programs with specialties or concentrations in secure software engineering (or security engineering for software-intensive systems). Some of these are standard degree programs, while others are specifically designed for the continuing education of working professionals. The following are typical examples: - James Madison University: Master of Science in Computer Science with a Concentration in Secure Software Engineering - Northern Kentucky University: Graduate Certificate in Secure Software Engineering - Stanford University: Online Computer Security Certificate in Designing Secure Software From the Ground Up - University of Colorado at Colorado Springs: Graduate Certificate in Secure Software Systems - Walden University (online): Master of Science in Software Engineering with a Specialization in Secure Computing - University of Central England at Birmingham: Master of Science in Software Development and Security - Chalmers University (Gothenburg, Sweden): Master of Science in Secure and Dependable Computer Systems. In another interesting trend (to date, exclusively in non-US schools), entire academic departments - and in one case a whole graduate school—are being devoted to teaching and research in software dependability, including security, e.g.: - University of Oldenburg (Germany) TrustSoft Graduate School of Trustworthy Software Systems - Fraunhofer Institute for Experimental Software Engineering (IESE) (Kaiserslautern, Germany): Department of Security and Safety - Bond University (Queensland, Australia): Centre for Software Assurance. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw [...@cigital.com] Sent: Thursday, August 20, 2009 2:55 PM To: Neil Matatall; Secure Code Mailing List Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of Software
Re: [SC-L] embedded systems security analysis
A colleague and I have been looking at the problem a bit, in the context of need for survivability in safety-critical systems. Below is an extract of the paper Software Survivability: Where Safety and Security Converge authored by Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore Winograd at the American Institute of Aeronautics and Astronautics' infot...@aerospace Conference in Seattle last spring. There's also a brief discussion of security issues associated with embedded software in the DHS/DACS Enhancing the Development Life Cycle to Produce Secure Software - specifically pages 272-275. The document is freely downloadable after quick registration on the DACS (DTIC's Data and Analysis Center for Software) Web site: https://www.dacs.dtic.mil/techs/enhanced_life_cycles/ Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com -- B. Embedded No Longer Means Isolated Before discounting a comparable threat to embedded systems, consider the following excerpt from Chapter seven of Exploiting Software [8] by Greg Hoglund and Gary McGraw: For no valid technical reasons, people seem to believe that embedded systems are invulnerable to remote software-based attacks. One common misconception runs that because a device does not include an interactive shell out of the box, then accessing or using ‘shell code’ is not possible. This is probably why some people (wrongly) explain that the worst thing that an attacker can do to most embedded systems is merely to crash the device. The problem with this line of reasoning is that injected code is, in fact, capable of executing any set of instructions, including an entire shell program that encompasses and packages up for convenient use standard, supporting [operating system]-level functions. It does not matter that such code does not ship with the device. Clearly, this kind of code can simply be placed into the target during an attack. Just for the record, an attack of this sort may not need to insert a complete interactive TCP/IP shell. Instead, the attack might simply wipe out a configuration file or alter a password. There are any numbers of complex programs that can be inserted via a remote attack on an embedded system. Shell code is only one of them. Even the most esoteric of equipment can be reverse engineered, debugged, and played with. It does not really matter what processor or addressing scheme is being used, because all an attacker needs to do is to craft operational code for the target hardware. Common embedded hardware is (for the most part) well documented, and such documents are widely available. One of the most widely publicized successful attacks on an embedded system was the 2002 hack of the flash memory of the Microsoft XBox game cube in order to access the algorithm used by the game cube’s cryptosystem to decrypt and verify its bootloader. [9] Now consider how safety-critical embedded systems—from temperature controls to medical devices to on-board airplane and automotive computers and sensors—are increasingly becoming network-accessible. For example, embedded software in implanted medical devices is now accessible via radio frequency identification (RFID) interfaces. [10] And telemedicine applications in use by DoD enable software-controlled surgical robots located in U.S. military facilities in Iraq to be operated via satellite uplinks by doctors at the U.S. Navy Hospital in Bethesda, Maryland. [11] Consider General Motors’ OnStar and its less familiar rivals (Ford’s RESCU and VEMS, Volvo’s OnCall, BMW’s Assist, Mercedes-Benz’s TeleAid and COMAND). These services all include the ability of call center representatives to perform remote telematic diagnostics of the onboard computers in their subscribers’ vehicles. The data they collect via transmissions from the cars’ computers are returned to the remote call centers via cellular or satellite phone links. Remote monitoring and diagnosis of automotive computers sounds benign enough (though there are significant privacy concerns associated with some of the data being gathered by these services), but OnStar has gone a step beyond simple observation to actual remote control of at least one of the automobile’s safety-critical onboard computers: the one that controls its ignition. As USA Today reported in October 2007, [12] the 1.7 million General Motors 2009 vehicles equipped with OnStar now allow their owners to grant permission for OnStar to cooperate with the police if their vehicles are stolen; specifically, if a police car is involved in a high-speed car chase with a stolen OnStar-enabled vehicle, the police can request that the stolen vehicle’s engine “be remotely switched off through the OnStar mobile communications system”. The objective of this police/OnStar cooperation is laudable: it allows the police to terminate car chases
Re: [SC-L] embedded systems security analysis
I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It might be something like the ability to insert a card in a PC slot (as in the Princeton attack on Diebold touchscreen systems), a USB stick (some of the UC Santa Barbara attacks - I think that was ESS touchscreen machines), Harri Hursti's attacks via a memory card on Diebold optical scanners, Princeton's attacks via a proprietary memory card on Sequoia systems, etc. (There are others too - the machines in my county use USB sticks and run Windows CE, so I believe they're susceptible to even trivial attacks via an autorun.) I also worked with a team that did some attacks on another embedded system in a voting machine, although we didn't get far enough to publish results before we ran out of students to do the grunt work. So I'd 1000% agree with Arian - not only is assuming you're safe dangerous, but it's also wrong. There's lots of attacks on other types of embedded systems - there have been a few against electric power control systems, water control systems, etc. And there are more that haven't seen the light of day I just heard about a very serious attack the other day that hasn't ever made it into the news. --Jeremy On Thu, Aug 20, 2009 at 2:09 PM, Arian J. Evansarian.ev...@anachronic.com wrote: Rafael -- to clarify concretely: There are quite a few researchers that attack/exploit embedded systems. Some google searches will probably provide you with names. None of the folks I know of that actively work on exploiting embedded systems are on this listbut I figure if I know a handful of them in my small circle of software security folks - there have to be many more out there. Assuming you are safe is not just a dangerous assumption: but wrong. Specifically - One researcher I know pulls boards system components apart and finds out who the source IC and component makers are. Then they contact the component and IC makers and pretends to be the board or system vendor who purchased the components, and asks for documentation, debuggers, magic access codes hidden in firmware (if he cannot reverse them). If this fails, the researcher has also befriended people at companies who do work with the IC or board maker, traded them information, in exchange for debuggers and the like. This particular researcher does not publish any of their research in this area. They do it mainly (I think) to help build better tools and as a hobby. (Several of you on this list probably know exactly whom I'm talking about. This person would prefer privacy, and I think the person's employer demands it, unless you get him in person and feed him enough beer.) If I were a bettin' man I'd figure if I know a few person doing this type of thing for quite a few years now -- there are bound to be many, many more Not sure what list to go to for talks on that type of thing. Blackhat.com has some older presentations on this subject. -- Arian Evans On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ 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 -
Re: [SC-L] embedded systems security analysis
Thank you for all the info you guys have sent, it has been very informative... :) It is harder to steal the source (you need more electronical knowledge and expensive debuggers and stuff) but it is possible... Do you guys know some pages with security tips for embedded systems? ___ 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?
Neil Matatall wrote: So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Secure coding needs to be taught anytime programing is taught. From my experience in my son's boy scout troop, I'm not sure I'd call it out as security and confuse middle school/junior high school students but I'd teach them basics like input validation and bounds checking as basic good programing. The security aspects can wait until later when they can better handle several concepts at once. After that is just needs to be part of the course and called out for what it is. There is room for stand alone security focused training and courses but it needs to be drilled in all along the way. I recall my own computer science instructors telling us *not* to spend time on bells and whistles and concentrate on the concept the lesson was covering. If the lesson was on pointers, adding things like error checking and user friendly features didn't count for anything. I can understand why that was said but it sends the wrong message and begins the development of bad habits. That was 20 to 30 years ago and most computer users' idea of security was locking their car doors but it did set us up for bad habits. Basics need to be drilled in early and always count for something even if the lesson is while loops. -- Mike Lyman mly...@west-point.org ___ 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] embedded systems security analysis
We looked at the problem of voting system security specifically in the context of insider threat for last year's IATAC State of the Art Report on the Insider Threat to Information Systems - some of which involved rogue developers engineering backdoors into such systems. Unfortunately the document is limited distribution and FOUO, so I can't excerpt here. But if you're interested and a government employee or contractor, let me know and I'll get you instructions on how to register with DTIC to obtain a copy. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jeremy Epstein [jeremy.j.epst...@gmail.com] Sent: Thursday, August 20, 2009 5:39 PM To: Arian J. Evans Cc: Secure Coding List Subject: Re: [SC-L] embedded systems security analysis I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. 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 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. :) Seriously, though, cyberspace is such an integral part of modern life, parents need to inculcate online security into their toddlers the same way they teach them to look both ways before crossing the street, and not to talk to or get into the car with strangers. In essence, we need to teach kids the virtual equivalents of these safe behaviours when they go online - which some of them are doing as early as age 4! If they can be brainwashed that early, they will come to have higher expectations of what SHOULD be present with regard to security properties in software-based systems. Then the notion won't seem alien to them. What will seem alien TO US is that they won't understand the struggles we've had to get people to start adding security. The idea of security having ever NOT been there will be bizarre to them. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Mike Lyman [mlyman-ci...@comcast.net] Sent: Friday, August 21, 2009 8:17 AM To: Secure Coding Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Neil Matatall wrote: So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Secure coding needs to be taught anytime programming is taught ___ 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] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)
Actually CJC, it's often even worse than that. In many cases, the customer or consumer has an implicit requirement for security that remains unstated. Only when the system fails and is successfully attacked does that requirement shift from implicit to explicit. You mean it wasn't secure?? You've got to be kidding... In some sense that's what happened to Microsoft way back in the virus-bag days. History shows that it is best to anticipate implicit requirements and address them as possible. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 8/21/09 8:40 AM, Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com wrote: Martin Gilje Jaatun wrote: Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. I couldn't agree more! However, I have had several discussions with a colleague who is fairly well known in theSoftware Process Improvement Mafia on the topic of how to ensure that security requirements are considered for _all_ kinds of code, not just security software. Particularily in the context of agile development techniques, security keeps getting the short end of the stick, losing every time to working features. His stance on this is that if security were important to the customer, the customer would provide and prioritize security requirements. To me, this is a bit like saying If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it. The problem (certainly as I see it) is that the customer is likely to say Make it secure without really understanding what that means. Secure against what exactly? Or you'll get a list of security features that the customer wants, but as we all know security features != secure product. Instead we've taken a combined approach of including customer requirements and adding specific requirements of our own focusing a good Secure development practices. If we can brainwash the coming generations of programmers into accepting Karen's definition of quality code, we might finally be getting somewhere. And that's the trick we've been attempting here. Secure software is nothing more than really good quality code. We already use coding guidelines and have a strong(ish) process of code reviews. So we have augmented our coding and review guidelines to include secure coding aspect such as input/output validation, good memory management etc. That said there is still a lot of scope for improvement in the rest of the software development process (testing and design in particular). CJC ___ 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?
On Wed, Aug 19, 2009 at 2:15 PM, Neil Matatallnmata...@uci.edu wrote: Inspired by the What is the size of this list? discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Does it help at all to consider how and where most people actually learn to program/develop? I don't have percentages handy of how many people with a job title or informal role as programmer or developer actually took any formal education in this. If we're just trying to reach the group of developers that went through formal training then we've seen some pretty good answers here in this thread already. If we want to cover others though, we need to look elsewhere. Let's look at another few fields where safety is important and yet the work is often done by both professionals and amateurs - Plumbing and/or Electrical Work. My own view is that much software development is actually a lot closer to the work of the amateur electrician than the professional electrician. That is, unlike fields like engineer, architect, lawyer, accountant, we don't rely on professional standards, degrees, certifications, etc. for most programmers. I'm leaving aside for a moment whether we can or should, and just pointing out that it is the case. In the case of the amateur electrician you'll find a wide variety in their knowledge of safety concerns, adherence to code, etc. They probably know enough to not electrocute themselves while they are working (though not always) but don't necessarily know enough to put in wiring that won't burn their house down in a few years. I think our real question isn't just how to reach the professional programmer trained via formal training programs, but also how to reach the amateur programmer trained via books, trial+error, etc. In these cases the best bet is to make sure that the general training manuals, how-to guides, etc. have a lot of safety/security information included in them. That the books people use to learn actually show them safe examples, etc. Obviously there are variations of code requirements per location and such, but basic safety rules will probably be mostly universal. - Andy ___ 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] Where Does Secure Coding Belong In the Curriculum?
Has anyone who holds to this taught a beginning level programming class? Getting students to understand what a loop is can be hard enough, given limited time. Diving into exploits and buffer overflows can be much more difficult. I am sure some things could be put into a basic class, but the ideas are a bit deeper. Security at the Hello World! or Mortgage Calculator program level seems quite difficult. This bears some thinking through, but the security risks seem to be: - Make sure the input amount is in dollars. - Make sure the term is numeric and within reasonable ranges. - Make sure that interest rate is in the form of XX.XX. Other things checked for would be - Proper output. - Pausing at the right point so the output can be viewed correctly. I am sure I am missing things, but this should serve as a base. Where do you inject security there? Sure, you can note the importance of checking the data, but just because someone checks the input here doesn't mean they will have a clue on checking the input on a web form for an SQL injection attempt. I get students who can't loop to start over, they are certainly not going to catch that they need to do deeper input inspection, especially in a completely unrelated topic. I am probably blowing some smoke here and I may disagree with myself later, but I think this discussion is worth having. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Mike Lyman mlyman-ci...@comcast.net: Neil Matatall wrote: So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Secure coding needs to be taught anytime programing is taught. From my experience in my son's boy scout troop, I'm not sure I'd call it out as security and confuse middle school/junior high school students but I'd teach them basics like input validation and bounds checking as basic good programing. The security aspects can wait until later when they can better handle several concepts at once. After that is just needs to be part of the course and called out for what it is. There is room for stand alone security focused training and courses but it needs to be drilled in all along the way. I recall my own computer science instructors telling us *not* to spend time on bells and whistles and concentrate on the concept the lesson was covering. If the lesson was on pointers, adding things like error checking and user friendly features didn't count for anything. I can understand why that was said but it sends the wrong message and begins the development of bad habits. That was 20 to 30 years ago and most computer users' idea of security was locking their car doors but it did set us up for bad habits. Basics need to be drilled in early and always count for something even if the lesson is while loops. -- Mike Lyman mly...@west-point.org ___ 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] Functional Correctness
I completely agree, though how are we really going to reach this point? We have been talking about this at least since I got into development in the early 1980s. We are not anywhere closer, though we have lots of neat tools that do lots of neat stuff. Unfortunately, our programs are also a lot more complicated, making the correct proof much more difficult. Can we really believe it is just around the corner to prove this? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com: Martin Gilje Jaatun wrote: Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. ___ 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] Customer Demand
While no customer is likely to say they don't care about software working now that we are past Y2K, they don't think about it at all and are unlikely to allow any schedule slippage to allow for making sure that is true. Customers only really care about the things they will pay for. Many companies claim they can't stand poor software or services, but they still pay for them, so they will keep getting them. Until we convince them that good security really is important and that they must demand and pay for it, we won't make the progress we want to make. How many companies wouldn't even be doing the PCI level of effort if they weren't forced to do so? How many strictly limit it to their PCI environment rather than looking at the risk to the whole enterprise? Even major breaches don't help since the it can't happen here attitude is common all over, in spite of the fact it is a risky stance. While part of this is just a cynical rant, I think the base point is that we have a whole lot more selling to do on the need for software security before we can properly place it throughout the curriculum. That sales job is hard. The fact a few people have gotten it doesn't mean most have or that we are completely ready for the next step. I realize many here may not be saying that, but that is the message I get stepping back. And I am a dreamer/visionary. I like to think well ahead of things, but focusing too much there makes us likely to continue to be a niche area, leaving lots of vulnerabilities. Wouldn't a better focus be on the customer demand end? Stirring that up will do more to advance secure development than any number of maturity models. Unfortunately, it is a much more difficult task. I would bet it is also not as conceptually interesting to many. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Martin Gilje Jaatun secse-ch...@sislab.no: His stance on this is that if security were important to the customer, the customer would provide and prioritize security requirements. To me, this is a bit like saying If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about 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 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] Silver Bullet: Fred Schneider
hi sc-l, The 41st epsiode of Silver Bullet just went live. This episode features a conversation with Fred Schneider, a computer sceince professor at Cornell and a very important thought leader in security research. Fred was the author of the seminal National Academies study Trust in Cyberspace. We talk about the relationship between reliability and security, about fault tolerant systems, and about diversity as a security mechanism. We also talk about writing secure code, outlawing C, and the end of the age of bugs. Fred brings up the idea of categories of attack and the evolution of attacks from configuration, through bugs, to flaws and finally to trust problems. http://www.cigital.com/silverbullet/show-041/ Fred is particularly well spoken and cogent, and it was a great privilege to chat about security with him. As always, your feedback 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. ___
[SC-L] Where Does Secure Coding Belong In the Curriculum?
Inspired by the What is the size of this list? discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html /redirect?url=http%3A%2F%2Fmichael-coates%2Eblogspot%2Ecom%2F2009%2F04%2Funiversities-web-app-security%2Ehtmlurlhash=c5OA_t=disc_detail_link and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? I started a discussion in the Educause group on linked in. I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=gid=138011discussionID=5737656 It looks like some Universities are offering courses now... Neil ___ 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?
Here is where my enterpriseyness will show. I believe the answer to the question of where secure coding belongs in the curiculum is somewhat flawed and requires addressing the curiculum holistically. If you go to art school, you are required to study the works of the masters. You don't attempt to paint a Picasso in the first semester, yet us IT folks think it is OK to write code before studying the differences between good code and bad code. If a student never learns good from bad and over time develops bad habits, then teaching security at ANY stage later in life is the wrong answer. We need to remix the way IT is taught in Universities and revisit the fundamentals of how to approach IT as a whole. My second and conflicting opinion says that Universities shouldn't be teaching secure code as they won't get it right. Students should understand the business/economic impact that lack of secure coding causes. If this is left strictly to Universities, it will most certainly feel academic (in the bad sense). A person doesn't become a real IT professional until they have a few years of real-world experience under their belts and therefore maybe this is best left to their employers as part of professional development and/or Master's programs that are IT-focused but not about the traditional computer-science/software engineering way of thinking... http://twitter.com/mcgoverntheory 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 is the size of this list?
Another lurker revealing himself ... my name is Matt Bishop, and I lurk at the University of California at Davis where I teach and do research in lots of areas of computer security, including (surprise!) what is traditionally called secure programming and secure software development. For what it's worth, I don't like the use of the term secure because it's too vague -- I'd prefer robust or something related to assurance, but I can't come up with a short term. Oh, well. I've been working with secure coding for many years. I'm particularly interested in the interaction between coding and policy, and also in how to teach this stuff. I've done some training (long ago, with SANS), but now I focus on college/university education (for the most part). I get lots of good examples and ideas from this list, and sometimes the postings challenge me to think about different perspectives. In particular, the discussions of how people use these techniques, and the ones people find the most pernicious and troubling, help me give realistic examples when I teach students how to write good code. So Ken, thank you for starting and maintaining this list -- I think you've done the community a great service. A thought about Rob Floodeen's comment: 2. How to incorporate the concept of secure coding and new techniques/tools to do so. This should be a minor objective through our academic curriculum as well. Just like advanced math skills, we should have advanced secure coding skills for Software Engineers. My own feeling is that this should be a basic skill for people who program, not just software engineers. But the level at which practitioners (for want of a better term) need to know this varies depending on what they do. An occasional programmer (a physicist, for example) probably doesn't need to know about race conditions and, indeed, about security in general -- but she would need to know how to write a program that checks its input (lest the results be invalid -- GIGO), which is security from her point of view. A software engineer darn well better know about race conditions, though! So I agree with what Rob posted, and I did have one thought. Is writing good English a minor objective of an English major? Probably, in the sense English curricula focus on interpretation of literature, literary criticism, and other aspects of literature. But it's an essential one. So perhaps incidental and important describes how I feel better than minor. Matt ___ 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'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.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. ___
[SC-L] embedded systems security analysis
Rafael -- to clarify concretely: There are quite a few researchers that attack/exploit embedded systems. Some google searches will probably provide you with names. None of the folks I know of that actively work on exploiting embedded systems are on this listbut I figure if I know a handful of them in my small circle of software security folks - there have to be many more out there. Assuming you are safe is not just a dangerous assumption: but wrong. Specifically - One researcher I know pulls boards system components apart and finds out who the source IC and component makers are. Then they contact the component and IC makers and pretends to be the board or system vendor who purchased the components, and asks for documentation, debuggers, magic access codes hidden in firmware (if he cannot reverse them). If this fails, the researcher has also befriended people at companies who do work with the IC or board maker, traded them information, in exchange for debuggers and the like. This particular researcher does not publish any of their research in this area. They do it mainly (I think) to help build better tools and as a hobby. (Several of you on this list probably know exactly whom I'm talking about. This person would prefer privacy, and I think the person's employer demands it, unless you get him in person and feed him enough beer.) If I were a bettin' man I'd figure if I know a few person doing this type of thing for quite a few years now -- there are bound to be many, many more Not sure what list to go to for talks on that type of thing. Blackhat.com has some older presentations on this subject. -- Arian Evans On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ 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] Where Does Secure Coding Belong In the Curriculum?
hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of Software Security http://swsec.com. Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since then. * University of California at Davis * University of Virginia * Johns Hopkins University * Princeton University * Purdue University (especially the CERIAS center) * Rice University * University of California at Berkeley * Stanford University * Naval Postgraduate School (a military school for graduates) * University of Idaho * Iowa State University * George Washington University * United States Military Academy at West Point Matt Bishop made some excellent points in this thread. He and I discuss the notion of education versus training at length in Silver Bullet episode 31 http://www.cigital.com/silverbullet/show-031/ part of which was transcribed here http://www.cigital.com/silverbullet/shows/silverbullet-031-mbishop.pdf. gem company www.cigital.com book www.swsec.com On 8/19/09 5:15 PM, Neil Matatall nmata...@uci.edu wrote: Inspired by the What is the size of this list? discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html /redirect?url=http%3A%2F%2Fmichael-coates%2Eblogspot%2Ecom%2F2009%2F04%2Funiversities-web-app-security%2Ehtmlurlhash=c5OA_t=disc_detail_link and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? I started a discussion in the Educause group on linked in. I guess it requires authentication and possibly group membership: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=gid=138011discussionID=5737656 It looks like some Universities are offering courses now... Neil ___ 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 is the size of this list?
On Aug 18, 2009, at 2:21 PM, Arian J. Evans wrote: Jeremiah Grossman and I were both pondering the size of the SCL recently. Is the list size public? It's not public per se, but only in the sense that the number isn't directly available--unless you ask for it. The list has pretty consistently hovered around 1000 subscribers since pretty shortly after I launched it in late 2003. I am curious why I don't see many new names on SC-L. Lots of lurkers? We do seem to have a high percentage of lurkers, but I always like to encourage newcomers as well as new active participants. I do my best to keep my moderating light, and I welcome all perspectives and opinions on the topics we discuss here. My primary moderating criteria are ensuring submissions are relevant to the list charter and keep a civil tone. Beyond that, everyone on the list is largely free to say/discuss whatever suits. Plain and simple: the list is what the members make of it. btw// SCL has always been a great place for academic and progressive-minded folks to talk about state of the art, and future ideas for secure coding. I have always recommended it to developers looking for new places to learn as a best and brightest haunt. So thanks for running it guys, Thanks. I've consistently found over the years that efforts like this are worth the effort in a myriad of ways, and it's something that I gladly take on. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ 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 is the size of this list?
Hi SC-L, I'm a Lurker. I work for CERT | SEI | CMU and monitor the list in an attempt to keep an ear to the ground. While I'm not a professional programmer I do have an undergrad and graduate degree in CS which means I've been trained a little about programming. I'm really interested in two things with this list, 1. How do we teach secure coding from a training perspective (I develop training scenarios for CERT and I'm in the Workforce Development group, so this is exactly the kind of list that draws my attention.) 2. How to incorporate the concept of secure coding and new techniques/tools to do so. This should be a minor objective through our academic curriculum as well. Just like advanced math skills, we should have advanced secure coding skills for Software Engineers. Warm Regards, -Robert Floodeen On Wed, Aug 19, 2009 at 11:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ 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] CFP - Secure Software Engineering (SecSE 2010)
Fourth International Workshop on Secure Software Engineering (SecSE2010) http://www.sintef.org/secse In conjunction with ARES 2010 http://www.ares-conference.eu/conf/ February, 15th - 18th 2010 Andrzej Frycz Modrzewski Cracow College, Krakow, Poland Call for Papers === Software is an integral part of everyday life, and we expect and depend upon software systems to perform correctly. Software security is about ensuring that systems continue to function correctly also under malicious attack. As most systems now are web-enabled, the number of attackers with access to the system increases dramatically and thus the threat scenario changes. The traditional approach to secure a system includes putting up defence mechanisms like IDS and firewalls, but such measures are no longer sufficient by themselves. We need to be able to build better, more robust and more secure systems. Even more importantly, however, we should strive to achieve these qualities in all software systems, not just the ones that need special protection. This workshop will focus on techniques, experiences and lessons learned for building secure and dependable software. Topics == Suggested topics include, but are not limited to: -Secure architecture and design -Security in agile software development -Aspect-oriented software development for secure software -Security requirements -Risk management in software projects -Secure implementation -Secure deployment -Testing for security -Quantitative measurement of security properties -Static and dynamic analysis for security -Verification and assurance techniques for security properties -Lessons learned -Security and usability -Teaching secure software development -Experience reports on successfully attuning developers to secure software engineering Important dates: -Submission Deadline: September 30th 2009 -Author Notification: November 1st 2009 -Author Registration: November 11th 2009 -Proceedings Version: November 11th 2009 -Conference/ Workshop: February, 15th - 18th 2010 Submission Guidelines = Authors are invited to submit papers in IEEE Computer Society Proceedings Manuscripts style (two columns, single-spaced, including figures and references, using 10 pt fonts, and number each page). Please consult the IEEE CS Author Guidelines at the following web page: http://www2.computer.org/portal/web/cscps/formatting We solicit the submission of academic workshop papers (6 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Duplicate submissions are not allowed. A submission is considered to be a duplicate submission if it is submitted to other conferences/workshops/journals or if it has been already accepted to be published in other conferences/workshops/journals. Duplicate submissions thus will be automatically rejected without review. Contact author must provide the following information: Paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords. Paper registration and submission is done through the ARES CISIS 2010 Paper Management System at the following address: https://stdev.ifs.tuwien.ac.at/ares2010/ Submission of a paper implies that should the paper be accepted, at least one of the authors will register for the ARES conference and present the paper in the workshop. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. Note that SecSE 2010 does not require anonymized submissions. Publication === All accepted papers will be published as ISBN proceedings by the IEEE Computer Society, and will be available online through IEEE Xplore (EI indexing). Journal special issue: Distinguished papers submitted to SecSE will be invited for possible publication in the International Journal of Secure Software Engineering (ISSN 1947-3036 - http://www.igi-global.com/ijsse). Organizing committee: Martin Gilje Jaatun, SINTEF ICT, Norway Torbjørn Skramstad, Norwegian University of Science and Technology (NTNU) Lillian Røstad, Norwegian University of Science and Technology (NTNU) Enquiries to the organizing committee may be sent to: SecSE replace with at-character sislab.no Program committee (to be confirmed) === Rubén Alonso, Visual Tools, Spain Sergey Bratus, Dartmouth College, USA Ana Cavalli, GET/INT, France Estibaliz Delgado, European Software Institute, Spain Ivan Flechais, University of Oxford, UK Khaled M. Khan,Qatar University, Qatar Andrea Lanzi, Institute Eurecom, France Per Håkon Meland, SINTEF ICT, Norway Khalid Mughal, University of Bergen,
[SC-L] Static analysis tool exposition (SATE) 2009 - call for participation
We are preparing an exposition for static analysis tools that find security relevant defects. Briefly, participating tool makers run their tools on real programs. Researchers led by NIST analyze the tool reports. Everyone reports results and experiences at a workshop. The tool reports and analysis are made publicly available later. The plan is at http://samate.nist.gov/SATE.html We plan to provide the test sets by 19 August, and to hold the workshop on 6 November. We invite tool makers to sign up. If you would like to participate in the exposition, or if you have questions, please email Vadim Okun (vadim.okun 'at' nist.gov). Sincerely, Vadim ___ 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] [WEB SECURITY] Re: Integrated Dynamic and Static Scanning
Good catch, that is exactly right. My oversight. A while back Fortify released a white paper entitled Misplaced Confidence in Application Penetration Testing [reg required] http://www.fortify.com/security-resources/library/overviews.jsp Tools also available to help measure. On Aug 6, 2009, at 5:04 PM, James Landis wrote: There's a big claim in area 2) that actually does exist: instrumentation of static code to give you code coverage metrics for your dynamic scanning efforts. Well, maybe it's not area 2), but it's definitely a static analyzer vendor feeding dynamic analysis. -j On Thu, Aug 6, 2009 at 4:30 PM, Jeremiah Grossman jerem...@whitehatsec.com wrote: Hey all, I've been monitoring this thread [1] and some excellent points have been raised (cross-posting to websecurity as the subject matter applies). I'm personally very interested in the potential benefits of an integration between dynamic and static analysis scanning technology. The spork of software security testing. The desire of many is a single solution that unifies the benefits of both methodologies and simultaneously reduces their respective well- described limitations. For at least the last couple of years there have been vendors claiming success in this area, of which I remain skeptical. A brief explanation of the bi-directional and somewhat simple sounding innovations that vendors are trying to develop: 1) Dynamic Scanner - Static Analyzer A dynamic analysis engine capable of providing HTTP vulnerability details (URL, cookie, form etc.) to a static analysis tool. Static analysis results narrowed down to a single line of insecure code or subroutine to speed vulnerability remediation. Prioritize issues that are located in a publicly available code flow vs. those that are not technically remotely-exploitable. Isolate security issues where source code was not available, such as third-party libraries. Static Analyzer - Dynamic Scanner 2) A static analyzer capable of providing a remotely available attack surface (URLs, Forms, etc.) to a dynamic analysis tool. Dynamic analysis may realize additional testing comprehensiveness, measurement of coverage depth, and hints for creating exploit proof- of-concepts. Not to mention able to provide more detailed application fix recommendations. vendor bias As it stands currently, the state-of-the-art is basically a reporting mash-up. Very little of the aforementioned advancements have been proven to funtion outside of the lab environment. If anyone has evidence to the contrary they can point to, please speak up. For those curious as to Tom Brennan's comment, these are the areas Fortify and WhiteHat are together working on. /vendor bias This is an excellent time to be in the application and software security industry. Over the next few years there is going to be a lot of innovation and awareness in the defense side of the industry. Talent, skill, and experience is going to command a premium. [1] http://www.mail-archive.com/sc-l@securecoding.org/msg02731.html Regards, Jeremiah Grossman Chief Technology Officer WhiteHat Security, Inc. http://www.whitehatsec.com/ blog: http://jeremiahgrossman.blogspot.com/ twitter: @jeremiahg Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives:http://www.webappsec.org/lists/websecurity/archive/ Subscribe via RSS:http://www.webappsec.org/rss/websecurity.rss [RSS Feed] Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA ___ 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] Integrated Dynamic and Static Scanning
Speaking of the lab environment, my thesis from 2006 (http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/thesis.pdf) explores the interplay between static and runtime in gory detail. I am not aware of these hybrid approaches being integrated into commercial products. Regards, -Ben -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Jeremiah Grossman Sent: Thursday, August 06, 2009 4:30 PM To: sc-l@securecoding.org; websecur...@webappsec.org Subject: Re: [SC-L] Integrated Dynamic and Static Scanning Hey all, I've been monitoring this thread [1] and some excellent points have been raised (cross-posting to websecurity as the subject matter applies). I'm personally very interested in the potential benefits of an integration between dynamic and static analysis scanning technology. The spork of software security testing. The desire of many is a single solution that unifies the benefits of both methodologies and simultaneously reduces their respective well-described limitations. For at least the last couple of years there have been vendors claiming success in this area, of which I remain skeptical. A brief explanation of the bi-directional and somewhat simple sounding innovations that vendors are trying to develop: 1) Dynamic Scanner - Static Analyzer A dynamic analysis engine capable of providing HTTP vulnerability details (URL, cookie, form etc.) to a static analysis tool. Static analysis results narrowed down to a single line of insecure code or subroutine to speed vulnerability remediation. Prioritize issues that are located in a publicly available code flow vs. those that are not technically remotely-exploitable. Isolate security issues where source code was not available, such as third-party libraries. Static Analyzer - Dynamic Scanner 2) A static analyzer capable of providing a remotely available attack surface (URLs, Forms, etc.) to a dynamic analysis tool. Dynamic analysis may realize additional testing comprehensiveness, measurement of coverage depth, and hints for creating exploit proof-of-concepts. Not to mention able to provide more detailed application fix recommendations. vendor bias As it stands currently, the state-of-the-art is basically a reporting mash-up. Very little of the aforementioned advancements have been proven to funtion outside of the lab environment. If anyone has evidence to the contrary they can point to, please speak up. For those curious as to Tom Brennan's comment, these are the areas Fortify and WhiteHat are together working on. /vendor bias This is an excellent time to be in the application and software security industry. Over the next few years there is going to be a lot of innovation and awareness in the defense side of the industry. Talent, skill, and experience is going to command a premium. [1] http://www.mail-archive.com/sc-l@securecoding.org/msg02731.html Regards, Jeremiah Grossman Chief Technology Officer WhiteHat Security, Inc. http://www.whitehatsec.com/ blog: http://jeremiahgrossman.blogspot.com/ twitter: @jeremiahg ___ 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] IBM Acquires Ounce Labs, Inc.
Mattyson -- I almost complete agree with you. I will say - during ongoing deep dive assessments, we commonly find that applications that have one or more authC/Z issues at launch, will reintroduce them over time, if they write and push a lot of code. Anecdotally I would say we see at least one major Auth issue (or similar critical issue) per year in volatile code, over time, during ongoing assessments. (I'll do some hard math later on this.) The recurring issues are usually singular in nature, and not systemic. I'll give you an example: so you find that an app has a broken auth system; let's say it is a J2EE app, pre-MVC. Fundamental auth design-issue. To remediate they write an auth.Request.Routing servlet, and all servlets are only supposed to take callers that come through auth.Request.Routing. Design issue solved. So about once a year someone pushes a servlet (or form) with sensitive/critical functions, that does not properly call auth.Request.Routing. So now you have an implementation (or process, code review, peer review, SDL) problem. You get the idea. Insert all your points. So regular, or ongoing deep dives have a lot of value for high-risk applications to figure out which of the rest of the system broke. :) I agree scanner jockey work definitely has a place, and so do ongoing deep dives. The two can be combined with the right platform. Next up is integrating all these different types of analysis, and leveraging them all to provide better business context. There are cost-effective ways to enable people to do deeper blackbox and whitebox, and get better (and more contextual) results, I want to promote that. (Contextual Black Box vs. Blind Black Box). But I will save that for another chapter in this discussion. nota bene: In case I sounded too critical I should add -- one of the best things I hear in the field about Veracode is the strength of their customer-first/customer-centric focus and support, which is near and dear to my own heart. That should be a model for us all, and I wouldn't want to partner/work with with anyone who did things differently. I also hear Veracode is very good about customizing/tuning results of static analysis for clients. I think customization for individual customers is an essential reality for all types of analysis of custom code and business needs. Once again I think this is an important lesson for us all, and in my biased opinion: a major strength of SaaS appsec offerings. Any time you have to eat your own dogfoot, *and* satisfy clients on a recurring basis: you are going to get better fast. ChrisW could also claim I owe him a large intellectual debt for discussions over the years, but thankfully he's too polite for that. :) btw// I used to joke about how the BUFD (big up front design) crowd almost always addresses security with a BFPT (big final pen test) before shipping. So, possibly, we had that discussion over beers. Dusseldorf? ;) Anyway, great discussion. If you look back @SC-L three years ago, discussions like this show how much the industry and customer needs are evolving. Good stuff. Cheers, -- Arian Evans On Wed, Aug 5, 2009 at 7:14 PM, Matt Fisherm...@piscis-security.com wrote: I think anyone who has experience with deep dynamic testing knows they need automation tools with custom configuration ability, the ability to record workflow, a framework to create custom tests, etc. Absolutely. But Arian there are differing deployment models. You don't just touch an application once in it's life and leave it, right ? You're doing architecture reviews, reviewing the functional requirement and RBACs, reviewing code, doing integrated security testing, doing a final validation (or as a friend once put it over drinks the big giant pen-test). For any of those activities, you need real live, experienced skilled testers. Once it goes live, however, you may very well have a SOC, NOC, or even security team who is tasked with the continual scanning and monitoring of their space who's goal is to touch everything - however lightly - at least once very x days. For this type of scenario where bulk scalability counts over quality - AND A QUALITY ASSESSMENT AND VALIDATION WAS ALREADY PERFORMED- I would suggest a scanner monkey may be appropriate. Of course you would NEVER want that to be your ONLY assessment or validation. Chris, SPI had a product called DevInspect that performed static and dynamic analysis as a single product, and was definitely around before Aug '07. Not saying it was red-hot, just saying it was there. I'd like to see NTO. Given the slower dev times of the larger companies and begrudgingly slow addition of core capabilities to them, I'm really hoping that some of the smaller guys end up growing and filling niches. For instance, I've heard that one smaller player crawls every bit as well as a major player, and *much* better than the other major player, but while costing considerably less
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
Arian J. Evans wrote... The problem I had in the past with benchmarks was the huge degree of customization in each application I would test. While patterns emerge that are almost always automatable to some degree, the technologies almost always require hand care-and-feeding to get them to an effective place. I think this notion of combining the tools with qualified users is the true potential power of the SaaS solutions that are coming to market. It's a pity that the these dynamic-scanning vendors can't work together to come up with a common approach to at least helping this automation you speak of at least part way along. (Yes, I know. I'm dreaming. ;-) Some ideas that I've had in the past is that they could request and make use of: 1) HTTP access logs from Apache and/or the web / application server. These might be especially useful when the logs are specially configured to also collect POST parameters and then the application's regression tests are run against the application to collect the log data. Most web / app servers support Apache HTTPD style access log format, so parsing shouldn't be too terribly difficult in terms of the # of variations they need to handle. 2) For Java, the web.xml could be used to gather data that might allow some automation, especially wrt discovery of dynamic URLs that otherwise difficult to discover by autoscanning. 3) If Struts or Strut2 is being used, gather info from the Struts validators (forget OTTOMH what the XML files called where this is placed, bot those are what I'm referring to). 4) Define some new custom format to allow the information they need to be independently gathered. Ideally this would be minimally some file format (maybe define a DTD or XSD for some XML format), but their tools could offer some GUI interface as well. Of course, I'm not sure I'd expect to see anything like this in my lifetime. At this point, most of the users of these tools don't even see this as a need to the same degree that Arian and readers of SC-L do and it's not clear how vendors addressing these shortcomings IN A COMMON WAY would help them to compete. More likely, we'll get there from here by evolution and vendors copying ideas from one another. The other significant driver AGAINST this as I see it as many vendors sell professional services for specialized consulting on how to do these things manually. That bring in extra $$ into their companies so convincing them to give up their cash cow is a hard sell. And as a purchaser of one of these tools, if you don't have the needed expertise in house (many do, but I'm guessing a lot more don't), it's hard to tell your director that you can't use that $75K piece of shelfware that your security group just bought because they can't figure out how to configure it. Instead, they are more likely to quietly just drop another $10K or so for consulting discretely and hope their director or VP doesn't notice. -kevin -- Kevin W. Wall 614.215.4788Application Security Team / Qwest IT The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME ___ 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] IBM Acquires Ounce Labs, Inc.
Chris -- Good point with Larry's paper. NTO Spider is, by design, a simplified scanner for unskilled users, and I do not think it was designed to be an effective tool for deep dynamic analysis of a web application. It is, however, probably the best scanner on the market for people who don't have the time or skill to configure dynamic testing tools for their applications! Larry Suto's paper reinforces this use-case desktop webapp scanners: Each scanner was run in default mode and not tuned in any capacity to the application. The importance of this lies in how effective the default mode so that scalability of scanning is not limited by manual intervention and setup procedures which can be very time consuming. Second, in most cases it is simply unrealistic to spend much time with many applications. While I definitely look forward to more objective data on this subject, I do not think Suto's report is a good example of how consultants or SaaS providers deliver expert security analysis when they use dynamic testing automation IMO. (I know this is not how I ever did things.) I think anyone who has experience with deep dynamic testing knows they need automation tools with custom configuration ability, the ability to record workflow, a framework to create custom tests, etc. I do not believe NTO spider offers any of these essential features. I believe it was explicitly designed for unskilled users' use-cases. (A valid and important market to be sure.) Admittedly I could be very wrong here. The NTO guys are sharp folks and I haven't seen Spider in a while. As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. Completely agreed. I prefer to back up my statements about dynamic tools with hard, quantifiable data. Deprived of that, I tend to rely on historical experience, if it is a subject I have enough experience on within that problem domain. If you recall I used to do extensive testing and benchmarking of dynamic testing tools across custom widgets I wrote, and production enterprise applications, and publish them @OWASP and NIST conferences, and HE: Webapps 2nd Ed. Back then the quality of the tools was very volatile, and changed significantly every release, and from application to application you would test, so by the time you vetted all your data, it was almost obsolete. Again the importance of customizable, manually guided tools, when dealing with new and bespoke applications. I tried to tackle static analysis but became overwhelmed by the challenge of setting up effective labs, and the huge array of static analysis tools that were available. Given that I now work on a dynamic testing platform: it would be completely fair to accuse me of being non-objective when discussing various vendors dynamic testing tools -- and I would have to agree with you. It won't make my statements any less valid, but I have to throw that out there to be fair. Ultimately you hit the need for objective data spot-on. I would be lying if I didn't say that I would LOVE to see more head-on benchmarking between static analysis technology vendors like Veracode, Fortify, Ounce, Coverity, Klockwork, etc. etc. The problem I had in the past with benchmarks was the huge degree of customization in each application I would test. While patterns emerge that are almost always automatable to some degree, the technologies almost always require hand care-and-feeding to get them to an effective place. I think this notion of combining the tools with qualified users is the true potential power of the SaaS solutions that are coming to market. I look forward to seeing the release of more objective analysis by smarter minds than I, and am very impressed with how far things have come since the simple tests I tried to run over the years. $0.02. Cheers, -- Arian Evans On Tue, Aug 4, 2009 at 5:54 PM, Chris Wysopalcwyso...@veracode.com wrote: I wouldn't say that NTO Spider is a sort of dynamic web scanner. It is a top tier scanner that can battle head to head on false negative rate with the big conglomerates' scanners: IBM AppScan and HP WebInspect. Larry Suto published an analysis a year ago, that certainly had some flaws (and was rightly criticized), but genuinely showed all three to be in the same league. I haven't seen a better head-to-head analysis conducted by anyone. A little bird whispered to me that we may see a new analysis by someone soon. As a group of security practitioners it is amazing to me that we don't have more quantifiable testing and tools/services are just dismissed with anecdotal data. I am glad NIST SATE '09 will soon be underway and, at least for static analysis tools, we will have unbiased independent testing. I am hoping for a big improvement over last year. I especially like the category they are using for some flaws found as valid but insignificant. Clearly they are
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
Great answer, John. I especially like your point about web.xml. This goes dually for black-box testing. There would be a lot of advantage to being able to get (and compare) these types of config files today for dialing in BBB (Better Black Box vs. blind black box) testing. I don't think anyone is doing this optimally now. I know I am eager to find static analysis that can provide/guide my BBB testing with more context. I definitely think we will see more of these combined-services evolve in the future. It only makes sense, especially given some of the context-sensitive framing considerations in your response. Thanks for the solid thoughts, -- Arian Evans On Wed, Jul 29, 2009 at 5:44 AM, John Stevenjste...@cigital.com wrote: All, The question of Is my answer going to be high-enough resolution to support manual review? or ...to support a developer fixing the problem? comes down to it depends. And, as we all know, I simply can't resist an it depends kind of subtlety. Yes, Jim, if you're doing a pure JavaSE application, and you don't care about non-standards compilers (jikes, gcj, etc.), then the source and the binary are largely equivalent (at least in terms of resolution) Larry mentioned gcj. Ease of parsing, however, is a different story (for instance, actual dependencies are way easier to pull out of a binary than the source code, whereas stack-local variable names are easiest in source). Where you care about a whole web application rather than a pure-Java module, you have to concern yourself with JSP and all the other MVC technologies. Placing aside the topic of XML-based configuration files, you'll want to know what (container) your JSPs were compiled to target. In this case, source code is different than binary. Similar factors sneak themselves in across the Java platform. Then you've got the world of Aspect Oriented programming. Spring and a broader class of packages that use AspectJ to weave code into your application will dramatically change the face of your binary. To get the same resolution out of your source code, you must in essence 'apply' those point cuts yourself... Getting binary-quality resolution from source code therefore means predicting what transforms will occur at what point-cut locations. I doubt highly any source-based approach will get this thoroughly correct. Finally, from the perspective of dynamic analysis, one must consider the post-compiler transforms that occur. Java involves both JIT and Hotspot (using two hotspot compilers: client and server, each of which conducting different transforms), which neither binary nor source-code-based static analysis are likely to correctly predict or account for. The binary image that runs is simply not that which is fed to classloader.defineClass[] as a bytestream. ...and (actually) finally, one of my favorite code-review techniques is to ask for both a .war/ear/jar file AND the source code. This almost invariable get's a double-take, but it's worth the trouble. How many times do you think a web.xml match between the two? What exposure might you report if they were identical? ... What might you test for If they're dramatically different? Ah... Good times, John Steven Senior Director; Advanced Technology Consulting Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 Blog: http://www.cigital.com/justiceleague Papers: http://www.cigital.com/papers/jsteven http://www.cigital.com Software Confidence. Achieved. On 7/28/09 4:36 PM, ljknews ljkn...@mac.com wrote: At 8:39 AM -1000 7/28/09, Jim Manico wrote: A quick note, in the Java world (obfuscation aside), the source and binary is really the same thing. The fact that Fortify analizes source and Veracode analizes class files is a fairly minor detail. It seems to me that would only be true for those using a Java bytecode engine, not those using a Java compiler that creates machine code. ___ 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] Integrated Dynamic and Static Scanning
While I completely agree with this statement, it is a much tougher sell to management that is seeking to keep the company making money (or perhaps even alive). I believe that having (and using) an imperfect tool is better than nothing, so I would at least push for that. Getting things that play well together is even better. I think a complete overhaul and digging security flaws out is even better, but is a much harder sell in many places in my experience. Perhaps I am too jaded, but you have to work with what you can get approved and paid for. The cost of the indispensable experience is much higher than most companies will stomach. :) Some companies do value it, but most haven't seen the light yet in my experience. While that is limited compared to many on this list, I think my perspective is something that is easy to lose track of when you are fixing security issues every day. Everyone doesn't share the vision, unfortunately. And some of those that see the problem don't have the budget and executive support to fix the problem -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Andre Gironda and...@gmail.com: On 7/28/09, Brad Andrews andr...@rbacomm.com wrote: Experts can't be replaced by tools. ___ 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] Integrated Dynamic and Static Scanning
That is certainly true. I was just commenting on the issue of systems that work together tightly. None do now (as far as I know), but this should potentially allow that to happen. I did here a few moans when this news came out, since IBM is not known for inexpensiveness from what I hear :) -- Brad Andrews RBA Communications CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting McGovern, James F (HTSC, IT) james.mcgov...@thehartford.com: Sometimes integration is a good and bad thing. ___ 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] Source or Binary
On 7/29/09 8:08 PM, silky michaelsli...@gmail.com wrote: Of course it's a binary, it runs by itself, when there is a java vm to run it. Just like you need a win32 vm to run a typical .exe. You misunderstand the notion of virtual machines if you think of Win32 as a virtual machine. There is nothing virtual about windows. It runs on the real hardware (ignoring things like VMWare). Your Windows EXEs (except those running in the .NET CLR) also run on the real x86 hardware. I.e., your variables are loaded into CPU registers and operated on, etc. The Java Virtual Machine is a theoretical machine, and Java code is compiled down to Java bytecode that runs on this theoretical machine. The Java VM is the actual Windows EXE that runs on the real hardware. It reads these bytecodes and executes them. There is a very significant level of abstraction between a Java program running in a Java virtual machine and native code that has been compiled to a native object format (e.g., an .exe). Realizing that java binaries hold a lot more is a mental shift that probably must be actively kept in mind. Hold a lot more what? This doesn't make sense. It makes a lot of sense. Because Java is a string-based language, a great deal of symbolic information (e.g., class names, method names, inheritance hierarchies) remains in the class file, literally in string format, after you compile. If you're in the C++ world and you compile and then strip your binaries, that symbolic information is reduced a lot. If you use a java decompiler (e.g., jad, jode, etc.), you can get .java files from .class files and they are remarkably usable. While C++ decompilation is possible, the fidelity of decompiled Java programs is significantly higher. I.e., they match their original source, sometimes in astonishing accuracy. Take a look at java decompilation and compare it to what you know about native code decompilation. It is absolutely true that (ignoring anti-reversing techniques like obfuscation), Java binaries carry a lot more usable information to help in the dissection and understanding of their execution than an equivalent native-code program would. Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ ? +1.703.585.7868 Software Confidence. Achieved. ___ 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] Source or Binary
In a message dated July 30, 2009 10:09 AM EDT, Paco Hope wrote... The Java Virtual Machine is a theoretical machine, and Java code is compiled down to Java bytecode that runs on this theoretical machine. The Java VM is the actual Windows EXE that runs on the real hardware. It reads these bytecodes and executes them. There is a very significant level of abstraction between a Java program running in a Java virtual machine and native code that has been compiled to a native object format (e.g., an .exe). There's theory, and then there's practice. This is almost 100% accurate from a practical matter with the exception of HotSpot or other JIT compiler technologies that compile certain byte code into machine code and then execute that instead of the original byte code. I'm sure that Paco is aware of that, but just not sure all the other readers are. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.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 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] CERIAS : Beware SQL injections due to missing prepared statement support
Actually it's not vulnerable because the strings are escaped first. My point is simply that using prepared statements would have been more robust than escaping strings on the client side. I'm sorry I didn't make that clear, I'll go edit my post now. Thanks! Pascal Kenneth Van Wyk wrote: Here's one for the daily UGH! Great points raised by Pascal Meunier (see below) about poorly implemented language support for Prepared Statement SQL calls. In particular, Python's pyPGSQL actually takes its prepared statement and translates internally to an old-style concatenated string query, thereby opening itself up to various SQL injection vulnerabilities. http://www.cerias.purdue.edu/site/blog/post/beware_sql_injections_due_to_missing_prepared_statement_support/#When:16:32:23Z Interesting article, Pascal. Thanks! Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ 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] Static Vs. Binary
Something occurred to me last night as I pondered where this discussion¹s tendrils are taking us. An point I only made implicitly is this: The questionfor yearshas been ³conduct your SA on source code or binary?². You can see that there are interesting subtleties in even those languages that target intermediate representational formats (like Java and the .NET family of languages that compiles to MSIL). The garbage-collection-optimization problems that plague those asking ³How do I assure password String cleanup in Java² are of the same ilk as the gcc optimizations that trouble the C/C++ realm. Yes, this question is still pertinent. It _is_ interesting to those looking for thorough/sound analysis to consider fidelity and resolution at this level. People are beginning to echo what I've been saying for years, this problem extends beyond the initial compile into the runtime optimizations and runtime compilers. My previous post reiterates that there's a lot more to it than most people consider. I think I allowed that clarification to muddle my more strategic point: - Whereas THE question used to be source code vs. binary representation, the question is NOW: What set of IOC-container/XML combos, aspect weaver results, method/class-level annotations, and other such tomfoolery governs the execution of my application beyond what the compiler initially output? - As Fortify, Veracode, and others punch out this 'static analysis on binaries via SAAS' battle, they and the organizations they serve would do well to keep this question in mind... Or risk the same failures that the current crop of parser-based static-analysis tools face against dynamic approaches. -jOHN On 7/29/09 8:44 AM, John Steven jste...@cigital.com wrote: All, The question of ³Is my answer going to be high-enough resolution to support manual review?² or ³...to support a developer fixing the problem?² comes down to ³it depends². And, as we all know, I simply can¹t resist an ³it depends² kind of subtlety. Yes, Jim, if you¹re doing a pure JavaSE application, and you don¹t care about non-standards compilers (jikes, gcj, etc.), then the source and the binary are largely equivalent (at least in terms of resolution) Larry mentioned gcj. Ease of parsing, however, is a different story (for instance, actual dependencies are way easier to pull out of a binary than the source code, whereas stack-local variable names are easiest in source). Where you care about ³a whole web application² rather than a pure-Java module, you have to concern yourself with JSP and all the other MVC technologies. Placing aside the topic of XML-based configuration files, you¹ll want to know what (container) your JSPs were compiled to target. In this case, source code is different than binary. Similar factors sneak themselves in across the Java platform. Then you¹ve got the world of Aspect Oriented programming. Spring and a broader class of packages that use AspectJ to weave code into your application will dramatically change the face of your binary. To get the same resolution out of your source code, you must in essence Oapply¹ those point cuts yourself... Getting binary-quality resolution from source code therefore means predicting what transforms will occur at what point-cut locations. I doubt highly any source-based approach will get this thoroughly correct. Finally, from the perspective of dynamic analysis, one must consider the post-compiler transforms that occur. Java involves both JIT and Hotspot (using two hotspot compilers: client and server, each of which conducting different transforms), which neither binary nor source-code-based static analysis are likely to correctly predict or account for. The binary image that runs is simply not that which is fed to classloader.defineClass[] as a bytestream. ...and (actually) finally, one of my favorite code-review techniques is to ask for both a .war/ear/jar file AND the source code. This almost invariable get¹s a double-take, but it¹s worth the trouble. How many times do you think a web.xml match between the two? What exposure might you report if they were identical? ... What might you test for If they¹re dramatically different? Ah... Good times, John Steven Senior Director; Advanced Technology Consulting Direct: (703) 404-5726 Cell: (703) 727-4034 Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 Blog: http://www.cigital.com/justiceleague Papers: http://www.cigital.com/papers/jsteven http://www.cigital.com Software Confidence. Achieved. On 7/28/09 4:36 PM, ljknews ljkn...@mac.com wrote: At 8:39 AM -1000 7/28/09, Jim Manico wrote: A quick note, in the Java world (obfuscation aside), the source and binary is really the same thing. The fact that Fortify analizes source and Veracode analizes class files is a fairly minor detail. It seems to me that would only be
Re: [SC-L] Static Vs. Binary
First, I generally agree that there are many factors that make the true and factual fidelity of static analysis really REALLY difficult. However, I submit that by debating this point, you're belaboring the correct angle of survivable Neptunian atmospheric entry with people that don't generally value the benefit of flying humans past the moon. The point being, if you're debating the minutiae of static analysis vis-a-vis compile time optimizations, you're convincing people to let good be the enemy of perfect. There are few (if any) perfect technologies, but we use them because they're needed and provide a ton of great value. Anyone who doubts this should glance at the device you're reading this on and imagine yourself refusing to use it because it doesn't have perfect security (or reliability, or usability, etc.). p. ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: John Steven jste...@cigital.com Date: Thu, 30 Jul 2009 17:20:52 To: Secure CodingSC-L@securecoding.org Subject: [SC-L] Static Vs. Binary Something occurred to me last night as I pondered where this discussion¹s tendrils are taking us. An point I only made implicitly is this: The questionfor yearshas been ³conduct your SA on source code or binary?². You can see that there are interesting subtleties in even those languages that target intermediate representational formats (like Java and the .NET family of languages that compiles to MSIL). The garbage-collection-optimization problems that plague those asking ³How do I assure password String cleanup in Java² are of the same ilk as the gcc optimizations that trouble the C/C++ realm. Yes, this question is still pertinent. It_is_ interesting to those looking for thorough/sound analysis to consider fidelity and resolution at this level. People are beginning to echo what I've been saying for years, this problem extends beyond the initial compile into the runtime optimizations and runtime compilers. My previous post reiterates that there's a lot more to it than most people consider. I think I allowed that clarification to muddle my more strategic point: - Whereas THE question used to be source code vs. binary representation, the question is NOW: What set of IOC-container/XML combos, aspect weaver results, method/class-level annotations, and other such tomfoolery governs the execution of my application beyond what the compiler initially output? - As Fortify, Veracode, and others punch out this 'static analysis on binaries via SAAS' battle, they and the organizations they serve would do well to keep this question in mind... Or risk the same failures that the current crop of parser-based static-analysis tools face against dynamic approaches. -jOHN On 7/29/09 8:44 AM, John Steven jste...@cigital.com wrote: All, The question of ³Is my answer going to be high-enough resolution to support manual review?² or ³...to support a developer fixing the problem?² comes down to ³it depends². And, as we all know, I simply can¹t resist an ³it depends² kind of subtlety. Yes, Jim, if you¹re doing a pure JavaSE application, and you don¹t care about non-standards compilers (jikes, gcj, etc.), then the source and the binary are largely equivalent (at least in terms of resolution) Larry mentioned gcj. Ease of parsing, however, is a different story (for instance, actual dependencies are way easier to pull out of a binary than the source code, whereas stack-local variable names are easiest in source). Where you care about ³a whole web application² rather than a pure-Java module, you have to concern yourself with JSP and all the other MVC technologies. Placing aside the topic of XML-based configuration files, you¹ll want to know what (container) your JSPs were compiled to target. In this case, source code is different than binary. Similar factors sneak themselves in across the Java platform. Then you¹ve got the world of Aspect Oriented programming. Spring and a broader class of packages that use AspectJ to weave code into your application will dramatically change the face of your binary. To get the same resolution out of your source code, you must in essence Oapply¹ those point cuts yourself... Getting binary-quality resolution from source code therefore means predicting what transforms will occur at what point-cut locations. I doubt highly any source-based approach will get this thoroughly correct. Finally, from the perspective of dynamic analysis, one must consider the post-compiler transforms that occur. Java involves both JIT and Hotspot (using two hotspot compilers: client and server, each of which conducting different transforms), which neither binary nor source-code-based static
[SC-L] Software protection
hi sc-l, Christian Collberg (an important pioneer in software protection) just published a great book called Surreptitious Software. It's just plain good. http://www.amazon.com/Surreptitious-Software-Watermarking-Tamperproofing-Addison-Wesley/dp/0321549252 I blogged about the book on Justice League today: http://www.cigital.com/justiceleague/2009/07/29/is-software-protection-software-security/ Who agrees that software protection is part of software security? Who disagrees? gem http://www.cigital.com/~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. ___
Re: [SC-L] Source or Binary
On Jul 29, 2009, at 4:17 PM, Brad Andrews wrote: Realizing that java binaries hold a lot more is a mental shift that probably must be actively kept in mind. Those with only Java experience may think it is obvious, but how many developers did not start with Java and have not purged this concept from their mind. Fair enough, but understand too that a Java class file (like those in a typical jar file, which is just a fancy word for ZIP format) can be trivially decompiled into quite legible Java source. Numerous open source Java decompilers (e.g., Jode, Jad) exist that make this extremely easy. And FWIW, that's exactly how the Etisalat Blackberry software update was analyzed and proven to contain spyware last week. Note that, there are many options to distributing these trivially decompiled class files... Cheers, Ken van Wyk smime.p7s Description: S/MIME cryptographic signature ___ 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] IBM Acquires Ounce Labs, Inc.
Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com wrote: Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE= Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ 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] IBM Acquires Ounce Labs, Inc.
Right now, officially, I think that is about it. IBM, Veracode, and AoD (in Germany) claims they have this too. As Mattyson mentioned, Veracode only does static binary analysis (no source analysis). They offer dynamic scanning but I believe it is using NTO Spider IIRC which is a simplified scanner that targets unskilled users last I saw it. At one point I believe Veracode was in discussions with SPI to use WI, but since the Veracoders haunt this list I'll let them clarify what they use if they want. So IBM: soon. Veracode: sort-of. AoD: on paper And more to come in short order no doubt. I think we all knew this was coming sooner or later. Just a matter of when. The big guys have a lot of bucks to throw at this problem if they want to, and pull off some really nice integrations. Be interesting to see what they do, and how useful the integrations really are to organizations. -- Arian Evans On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisherm...@piscis-security.com wrote: Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -Original Message- From: Prasad Shenoy prasad.she...@gmail.com Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk k...@krvw.com Cc: Secure Coding SC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com wrote: Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE= Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -Original Message- From: Prasad Shenoy prasad.she...@gmail.com Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk k...@krvw.com Cc: Secure Coding SC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com wrote: Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE= Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ 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. ___
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
Ah sorry didn't mean to leave you out Tom. -Original Message- From: Tom Brennan t...@owasp.org Sent: July 28, 2009 1:24 PM To: Matt Fisher m...@piscis-security.com; sc-l-boun...@securecoding.org sc-l-boun...@securecoding.org; Prasad Shenoy prasad.she...@gmail.com; Kenneth Van Wyk k...@krvw.com Cc: Secure Coding SC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Fortify (www.fortify.com) has Partnered with WhiteHat Security (www.whitehatsec.com) too Tom Brennan Board Member - OWASP Foundation Url: www.owasp.org | Tel: 973-202-0122 http://www.linkedin.com/in/tombrennan -Original Message- From: Matt Fisher m...@piscis-security.com Date: Tue, 28 Jul 2009 11:29:30 To: Prasad Shenoyprasad.she...@gmail.com; Kenneth Van Wykk...@krvw.com Cc: Secure CodingSC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -Original Message- From: Prasad Shenoy prasad.she...@gmail.com Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk k...@krvw.com Cc: Secure Coding SC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com wrote: Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE= Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
Fortify (www.fortify.com) has Partnered with WhiteHat Security (www.whitehatsec.com) too Tom Brennan Board Member - OWASP Foundation Url: www.owasp.org | Tel: 973-202-0122 http://www.linkedin.com/in/tombrennan -Original Message- From: Matt Fisher m...@piscis-security.com Date: Tue, 28 Jul 2009 11:29:30 To: Prasad Shenoyprasad.she...@gmail.com; Kenneth Van Wykk...@krvw.com Cc: Secure CodingSC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -Original Message- From: Prasad Shenoy prasad.she...@gmail.com Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk k...@krvw.com Cc: Secure Coding SC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com wrote: Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE= Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] IBM Acquires Ounce Labs, Inc.
A quick note, in the Java world (obfuscation aside), the source and binary is really the same thing. The fact that Fortify analizes source and Veracode analizes class files is a fairly minor detail. Jim Manico On Jul 28, 2009, at 7:40 AM, Arian J. Evans arian.ev...@anachronic.com wrote: Right now, officially, I think that is about it. IBM, Veracode, and AoD (in Germany) claims they have this too. As Mattyson mentioned, Veracode only does static binary analysis (no source analysis). They offer dynamic scanning but I believe it is using NTO Spider IIRC which is a simplified scanner that targets unskilled users last I saw it. At one point I believe Veracode was in discussions with SPI to use WI, but since the Veracoders haunt this list I'll let them clarify what they use if they want. So IBM: soon. Veracode: sort-of. AoD: on paper And more to come in short order no doubt. I think we all knew this was coming sooner or later. Just a matter of when. The big guys have a lot of bucks to throw at this problem if they want to, and pull off some really nice integrations. Be interesting to see what they do, and how useful the integrations really are to organizations. -- Arian Evans On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisherm...@piscis- security.com wrote: Pretty much. Hp /spi has integrations as well but I don't recall devinspect ever being a big hit. Veracode does both as well as static binary but as asaas model. Watchfire had a RAD integration as well iirc but it clearly must not haved had the share ounce does. -Original Message- From: Prasad Shenoy prasad.she...@gmail.com Sent: July 28, 2009 12:22 PM To: Kenneth Van Wyk k...@krvw.com Cc: Secure Coding SC-L@securecoding.org Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc. Wow indeed. Does that makes IBM the only vendor to offer both Static and Dynamic software security testing/analysis capabilities? Thanks Regards, Prasad N. Shenoy On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com wrote: Wow, big acquisition news in the static code analysis space announced today: http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE= Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com (This email is digitally signed with a free x.509 certificate from CAcert. If you're unable to verify the signature, try getting their root CA certificate at http://www.cacert.org -- for free.) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com ) as a free, non-commercial service to the software security community. ___ ___ 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] IBM Acquires Ounce Labs, Inc.
At 8:39 AM -1000 7/28/09, Jim Manico wrote: A quick note, in the Java world (obfuscation aside), the source and binary is really the same thing. The fact that Fortify analizes source and Veracode analizes class files is a fairly minor detail. It seems to me that would only be true for those using a Java bytecode engine, not those using a Java compiler that creates machine code. -- Larry Kilgallen ___ 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] Large scale development with Ruby
Not so much about secure-coding, but more about how we take unit testing and TDD very seriously: http://labs.mudynamics.com/2009/07/23/large-scale-ruby-development-with-tdd/ Are there people on the sc-l that have a comparable large-scale ruby project? I would love to hear about the gotchas of using Ruby in production environments and what to watch out for... Thanks, K. --- http://labs.mudynamics.com http://www.pcapr.net ___ 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. ___
