[SC-L] Fwd: IEEE W/NV Computer Society Presentation
fyi - of potential interest to this crowd (even if it does sound a bit sales-pitchy)... Original Message Subject: IEEE W/NV Computer Society Presentation Date: Tue, 15 Mar 2011 07:00:00 -0400 From: IEEE E-Notice owner-ieee-e-not...@bmsmail3.ieee.org Reply-To: sta...@ieee.org To: fal...@secureconsulting.net Quality Security Mesh within the Systems Development Life Cycle by: Rhonda Farrell Tuesday March 22, 2011 Synthesizing security throughout the SDLC takes the same concerted effort as implementing quality programs across an organization. Oftentimes, this requires that EVERYONE be empowered and responsible for enabling and implementing these new processes in a rational, phased approach. This discussion highlights the benefits of ensuring security is built in at every step of the SDLC versus bolted on at the end. Learn how your organization can take the next step towards achieving higher levels of both quality and security, by involving each and every person! Rhonda Farrell Associate, Booz Allen Hamilton, is a Certified Software Quality Engineer (CSQE), a Certified Information Systems Security Professional (CISSP), and a Certified Secure Software Lifecycle Professional (CSSLP). She recently earned her JD from Concord Law School and is currently pursuing her Doctorate in Information Assurance at the University of Fairfax. Rhonda is a Senior Member of the American Society for Quality (ASQ) and is a Member of the Executive Board (Membership Chair; co-chair for the LSS-SIG), for Section 509. She also holds a board level position with the Information Systems Security Association Northern VA (ISSA-NOVA) organization, as the VP of Education. Additionally she participates as an officer, volunteer, or basic member with the following organizations: Association for Computing Machinery (ACM), Institute of Electrical and Electronics Engineers (IEEE), Information Systems Audit and Control Association (ISACA), International Information Systems Security Certification Consortium, Inc. (ISC2), National Marine Corps League (MCL), Software Development Forum (SDForum), Silicon Valley Software Quality Association (SSQA-SV), and Woman Marines Association (WMA). She brings a wide breadth of experience in the operations, engineering, security, marketing, and training areas from having previously worked within private enterprise, state government, non-profit, educational, and military organizations. 6:30 PM Networking and Pizza(*); 7:00 - 8:00 PM Program (*) There is no cost to attend at McLean and Silver Spring. Locations: The presentation will originate at the McLean facility, with video tele-conferencing (VTC) between: MITRE, room 1N100 7515 Colshire Drive McLean, VA 22102 host: Scott Ankrum cell: 240-731-7581 FDA, Bld 66, room G512 10903 New Hampshire Ave Silver Spring, MD 20993 host: James Simpson cell: 301-996-4976 MITRE, room 2503 260 Industrial Way West Eatontown, NJ 07724 host: Richard Eng cell: 703-201-9112 MITRE, room 1M306 202 Burlington Rd (Rt. 62) Bedford, MA 01730 host: Tim Rice cell: 978-758-2704 If you can host another location via VTC, please contact Scott Ankrum Registration Website: http://www.asq509.org/ht/d/DoSurvey/i/26913 For more details and driving directions, see: http://www.asq509.org/ht/a/GetDocumentAction/i/58243 You have received this mailing because you are a member of IEEE Northern VA/Washington Computer Chapter http://ewh.ieee.org/r2/wash_nova/computer/cms/. To unsubscribe, please go to http://ewh.ieee.org/enotice/options.php?SN=TomhaveLN=CHAPTER and be certain to include your IEEE member number. If you need assistance with your E-Notice subscription, please contact k.n@ieee.org IEEE, 445 Hoes Lane, Piscataway, NJ 08854 USA -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] There are two kinds of people in the world, those who believe there are two kinds of people in the world and those who don't. Robert Benchley ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] BSides Austin 2011 CFP / CFS
Greetings and solicitations! We're pleased as punch to announce the 2nd annual Security BSides Austin 2011: Keep Security Weird! Planning is well underway for this year's event, which will be held March 11-12 in Austin, TX, conveniently during the same time SXSW Interactive (a major developer conference). One of our primary objectives in hosting opposite SXSW is to provide FREE appsec training and presentations to developers who are in town for the event. Our long-term goal is to become an officially sanctioned SXSW event. To make this event as outstanding as possible, we need your help! Here's how: * Speak! The CFP is open. Please register and submit your talk, or just leave a comment if you don't want to register on the site. * Attend! Register to attend at http://bsidesaustin2011.eventbrite.com/ * Sponsor! BSides events are free to attendees, which means we rely exclusively on sponsors. If you're willing to contribute, please drop us a note and we'll follow-up. Sponsorship is a great way to make a low-cost investment in the industry while getting your name out there and associated with one of the hottest events around! In addition to traditional talks and unconference sessions, we are also in the process of setting-up an AppSec Guerrilla Camp track where free hands-on workshops will be provided on appsec topics. These 1-2 hour sessions will be technical in nature and specifically oriented to developers. More information is available from the official event website: http://www.keepsecurityweird.org/ Please feel free to contact me directly (off-list) if you have questions or are interested in helping out! Thank you, -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Computers are like very dumb people, but they're very fast at being dumb, says Jason Hong, a professor at Carnegie Mellon's Human-Computer Interaction Institute (HCII). Washington Post (10/7/07 p.M01) This Is Your Life: As Determined by Confounding Identity-Protection Safeguards By Monica Hesse ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] RSnake's final post
In case you don't follow his blog... Rob RSnake Hanson has concluded his security blog, though he says he will continue in security for the time being. Nonetheless, a reasonably notable event anytime a prominent persona in this small community decides to all but walk away. http://ha.ckers.org/blog/20101201/and-beyond -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Champions aren't made in gyms. Champions are made from something they have deep inside them - a desire, a dream, a vision. They have to have last-minute stamina, they have to be a little faster, they have to have the skill and the will. But the will must be stronger than the skill. Muhammad Ali ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] Java: the next platform-independent target
All these platform-independent attacks are starting to get exhausting, no? Now that Adobe has come up with sandboxing for Reader and actually started responding to threats, it seems that the smart adversaries have moved to a new platform: Java. Stories are below, mostly deriving from Microsoft's latest Intelligence Report (this one has a botnet focus - a topic on which they've invested a ton of resources). If I understand this all correctly (never a safe bet), it seems these are actual attacks on Java, not on coding with Java. Ergo, this isn't something ESAPI can fix, but rather fundamental problems. What do you think? Overblown? Legit? Solutions forthcoming? The rise of Java exploits http://www.net-security.org/secworld.php?id=10014 Have you checked the Java? http://blogs.technet.com/b/mmpc/archive/2010/10/18/have-you-checked-the-java.aspx Java: A Gift to Exploit Pack Makers http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/ Announcing Microsoft Security Intelligence Report version 9 http://blogs.technet.com/b/mmpc/archive/2010/10/13/announcing-microsoft-security-intelligence-report-version-9.aspx cheers, -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] I ran into Isosceles. He had a great idea for a new triangle! Woody Allen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] free scans from Google...
I guess we can all retire now, eh? I find it so exciting that the app is written in pure C... and coming from Google, I'm sure it won't leak info back to the mothership at all... Meet skipfish, our automated web security scanner http://googleonlinesecurity.blogspot.com/2010/03/meet-skipfish-our-automated-web.html -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Do you think that when they asked George Washington for ID that he just whipped out a quarter? Steven Wright ___ 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] sponsors still needed for BSides Austin
Hi folks, We need your help. We're still looking for sponsors for this weekend's Security BSides Austin, which is set to occur the same day as the kickoff for SxSW Interactive (a major developer conference). We have official sponsorship from Astaro and Panda, plus a couple unofficial sponsors. We'd love to see your organization involved, too! Unconference details here: http://www.securitybsides.com/BSidesAustin Here are some benefits for sponsoring: * Being part of the media conversation: As people talk about us they talk about you or at least see you. Security B-Sides has been covered in magazines, podcasts, videocasts, blogs, and even inscribed on microchips. Get caught up in the conversation and be part of what people are talking about. * Brand recognition and awareness: Depending on the level of sponsorship, you may recognize your brand placement at some or all of the following: t-shirts, signage/lanyards, lunch sessions, or attendee badges. Based on your level of participation, create and custom branding may be arranged including transportation, banners, and podcast interviews. * Big Fish in a Small Pond: For some, sponsoring large events is not within their price range leaving them with no option for communicating their message. BSides is just the place for you! This small, community atmosphere brings together active and engaged participants who want to absorb information. Sponsoring a BSides event enables to be that big fish in a small pond and better communicate your message to an active audience. * Stay in touch with the industry: BSides enables its supporters and participants to identify and connect with industry leaders and voices. These participants represent the social networking of security. They are the people who you want to engage to solicit feedback and bring voice to your conversation. * Targeted and Direct Audience: You didn't enter the secrutity industry selling your product to everyone the same way, so why approach events that way? Instead of marketing to the broader security community connect directly with the security practioners who write about, talk about, recommend, and implement security products and services. * Be associated with the next big thing: Nobody knows what the “next big thing” will be, but these events are community driven with presentations voted upon by the industry. There is no magic to how it works, but we believe that listening to the underground can help prepare you and help identify what the next big thing might be. Thank you, -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] How young can you die of old age? Steven Wright ___ 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 apps are homogenous?
Jon, I think you're getting out of the scope of the costing exercise. The research and estimates around time to fix are based on the cost associated with developing the patch, not with deploying it. One could argue that the cost of fixing bugs - particularly major ones - is much higher for web applications given that they are more likely to be rapidly deployed and that the discovery of the bug is more likely to be widely publicized (especially if it leads to a breach). Everybody has a reasonable expectation that widely deployed commercial software is going to have various bugs over its life (e.g. Windows, Adobe products), while people seem to still be generally surprised when holes pop-up in web apps. Now, that being said, it is still a valid question as to if there is a cost differential between fix classic compiled code and modern web code. Toward that end, I would recommend looking into Laurie Williams' work at NCSU. She has inherited John Musa's Software Reliability Engineering legacy, is active in the field, and has published a number of articles and papers potentially relevant to this field. See: http://collaboration.csc.ncsu.edu/laurie/ fwiw. -ben On 2/25/10 1:56 AM, Jon McClintock wrote: On Wed, Feb 24, 2010 at 10:46:56AM -0500, Paco Hope wrote: I don't think webness conveys any more homogeneity than, say windowsness or linuxness. What part of being a web application provides homogeneity in a way that makes patching cheaper? In a word, control. Let's compare two different organizations: a commercial software development company, and a web commerce company. They both develop software, but how the software is deployed and managed is widely different. Commercial software is created by one party, and consumed by multiple other parties. Those parties may run it in widely different operating environments, with different network, software and harware configurations. They may be running old versions of the software, or using it in novel ways. If the commercial software development company has to patch a vulnerability, they need to first determine which releases of the software need to be patched, develop and test a patch for each supported version, test it across the plethora different configurations their customers may be running, develop release notes and a security advisory, make the patch available, and support their customers while they are patching. For a web commerce company, however, the picture is entirely different. While their production fleet may comprise hundreds, or even thousands, of servers, they're likely all running the exact same software and configuration, using a configuration management system to deploy the website software and keep it in sync. If the web commerce company identifies a vulnerability in their website, they can debug the running stack, create a fix, test it against an exact replica of the production stack, and use automated tools to deploy the patch to their entire fleet in one operation. -Jon ___ 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 tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Oh, so they have internet on computers now! Homer Simpson ___ 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] seeking hard numbers of bug fixes...
Ah, excellent - very helpful! It appears that Laurie Williams at NCSU has inherited John Musa's Software Reliability Engineering legacy, and is still active in the field, and has a number of relevant security articles/papers listed under Publications. http://collaboration.csc.ncsu.edu/laurie/ On 2/22/10 11:22 AM, Wall, Kevin wrote: Benjamin Tomhave wrote: ... we're looking for hard research or numbers that covers the cost to catch bugs in code pre-launch and post-launch. The notion being that the organization saves itself money if it does a reasonable amount of QA (and security testing) up front vs trying to chase things down after they've been identified (and possibly exploited). Ben, Not sure if this is what you are looking for or not, but back in the mid- to late-1980s or so, John Musa, a DMTS at Bell Labs, wrote up a couple of papers that showed this data, although this was in the more general context of software quality assurance and not specific to security testing. I'm pretty sure that Musa published something in either one of the ACM or IEEE CS journals and included some hard data, collected from a bunch of (then ATT) Bell Labs projects. IIRC, the main finding was something like the cost was ~100 times more to catch and correct a bug during the normal design / coding phase than it was to catch / correct it after post-deployment. Can't help you much more than that. I'm surprised I remembered that much! :) -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 This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Happiness makes up in height for what it lacks in length. Robert Frost ___ 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] seeking hard numbers of bug fixes...
Howdy, This request is a bit time critical as it's supporting a colleague's upsell up the food chain tomorrow... we're looking for hard research or numbers that covers the cost to catch bugs in code pre-launch and post-launch. The notion being that the organization saves itself money if it does a reasonable amount of QA (and security testing) up front vs trying to chase things down after they've been identified (and possibly exploited). Any help? Thank you, -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Imagination is everything. It is the preview of life's coming attractions. 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. ___
Re: [SC-L] A massive change at DARPA
I think it's a welcome change. It doesn't say so in this article clip, but he is Dr. Zatko, and has worked in instruction and academia, so it's not too far a leap for them. He's also been working in the federal space quite a bit since the L0pht sold out and shutdown. Dan Geer did something similar a couple years ago when he joined In-Q-Tel. On 2/11/10 8:42 AM, Jeremy Epstein wrote: OK, many of you don't care about DARPA, but here's something that happened there you *should* care about. DARPA funds research, and has historically drawn its program managers from the ranks of academia and occasionally the military. This is a massive change in outlook http://news.cnet.com/8301-27080_3-10450552-245.html Peiter Zatko--a respected hacker known as Mudge--has been tapped to be a program manager at DARPA, where he will be in charge of funding research designed to help give the U.S. government tools needed to protect against cyberattacks, CNET has learned. Zatko will become a program manager in mid-March within the Strategic Technologies Office at DARPA (Defense Advanced Research Projects Agency), which is the research and development office for the Department of Defense. His focus will be cybersecurity, he said in an interview with CNET on Tuesday. One of his main goals will be to fund researchers at hacker spaces, start-ups, and boutiques who are most likely to develop technologies that can leapfrog what comes out of large corporations. I want revolutionary changes. I don't want evolutionary ones, he said. He's also hoping that giving a big push to research and development will do more to advance the progress of cybersecurity than public policy decisions have been able to do over the past few decades. [...] ___ 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 tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] What if everything is an illusion and nothing exists? In that case, I definitely overpaid for my carpet. Woody Allen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM update (informIT)
based on past findings. Therefore, I also would challenge BSIMM to publicly make some specific predictions using their model and collected data so that their hypotheses can be tested independently by others. Finally, while I would like, as you did, to blame our Computer Security / software security's Cargo Cult mentality on its relative youth as a field, I believe there is something deeper going on here. For one, computer science / IT / whatever you want to call this much broader field has the same issue. And while computer science is young as measured against most other scientific disciplines, it is by no means an immature field. (As a discipline, it is much older than I, and trust me, I am no spring chicken. :) After observing this field for 30+ years (ouch!), I have concluded that we have not matured into a science because as a discipline we *do NOT really want to!* We can't even decide if we want this study of computers / information processing / etc. to be a science, an engineering discipline, or a craft. (And some even would like it to be an art.) Most of us--myself included--are too lazy to do the disciplined work that true science requires, and that includes having enough guts to challenge the academic culture and *demand* funding to do well-designed scientific experiment in our discipline at our leading universities. IMO, if we fail to do this, CS is doomed to always remain a science wannabe. Some would say that because our broader field of study--whether you call it Computer Science, Computer Engineering, Information Science, whatever--is part science, part engineering, part craft, and part something unique that humanity has never before encountered, attempts to treat it as a science will not succeed. However, surely this does not mean that we should not attempt to add some scientific rigor to it as a discipline. To that end efforts such as BSIMM should be welcomed by all. But is also important for those who prefer _descriptive_ approaches like BSIMM, to acknowledge the importance of _prescriptive_ approaches such as ESAPI, WAFs, anti-malware software, etc. We truly need *both* approaches to be successful. Regards, -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 This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. ___ -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Some of us will do our jobs well and some will not, but we will be judged by only one thing-the result. Vince Lombardi ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM update (informIT)
I challenge the validity of any risk assessment/rating approach in use today in infosec circles, whether it be OWASP or FAIR or IAM/ISAM or whatever. They are all fundamentally flawed in that they are based on qualitative values the introduce subjectivity, and they lack the historical data seen in the actuarial science to make the probability estimates even remotely reasonable. FAIR tries to compensate for this by using Bayesian statistics, but the qualitative-quantitative conversion is still highly problematic. On prescriptive... the problem is this: businesses will not spend money unless they're required to do so. Security will never succeed without at least an initial increased spend. It is exceedingly difficult to make a well-understood business case for proper security measures and spend. I think this is something you guys in insurance (you, Chris Hayes, etc.) perhaps take for granted. The other businesses - especially SMBs - don't even understand what we're talking about, and they certainly don't have any interest in dropping a penny on security without seeing a direct benefit. Do I trust regulators to do things right? Of course not, but that's only one possible fork. The other possible fork is relying on the courts to finally catch-up such that case law can develop around defining reasonable standard of care and then evolving it over time. In either case, you need to set a definitive mark that says you must do THIS MUCH or you will be negligent and held accountable. I hate standards like PCI as much as the next guy because I hate being told how I should be doing security, but in the short-to-mid-term it's the right approach because it tells people the expectation for performance. If you never set expectations for performance, then you shouldn't be disappointed when people don't achieve them. The bottom line here is that we need to get far more proactive in the regulatory space so that we can influence sensible regulations that mandate change rather than relying on businesses to do the right thing without understand the underlying business value. Conceptually, I agree with the idealist approach, but in reality I don't find that it works well at all. I've worked with a half-dozen or more companies of varying size in the last couple years and NONE of them understood risk, risk management, current security theory, or how the implicit AND explicit value of security changes. It's just not intuitive to most people, not the least of which because bad behaviors are generally divorced from tangible consequences. Anyway... :) I can go on forever on this topic... :) -ben On 2/3/10 10:06 AM, McGovern, James F. (eBusiness) wrote: While Wall Street's definition of risk collapsed, the insurance model of risk stood the test of time :-) Should we explore your question of how are risk levels defined in business terms more deeply or can we simply say that if you don't have your own industry-specific regulatory way of quantifying, a good starting point may be to leverage the OWASP Risk Rating system? I also would like to challenge and say NO to prescriptive. Security people are not Vice Presidents of the NO department. Instead we need to figure out how to align with other value systems (Think Agile Manifesto). We can be secure without being prescriptive. One example is to do business exercises such as Protection Poker. Finally, we shouldn't say yes to regulatory mandates as most of them are misses on the real risk at hand. The challenge here is that they always mandate process but never competency. If a regulation said that I should have someone with a fancy title overseeing a program, the business world would immediately fill the slot with some non-technical resource who is really good at PowerPoint but nothing else. In other words a figurehead. Likewise, while regulations cause people to do things that they should be doing independently, it has a negative side effect on our economy by causing folks to spend money in non-strategic ways. -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Benjamin Tomhave Sent: Tuesday, February 02, 2010 10:19 PM To: Arian J. Evans Cc: Secure Code Mailing List Subject: Re: [SC-L] BSIMM update (informIT) soapboxWhile I can't disagree with this based on modern reality, I'm increasingly hesitant to allow the conversation to bring in risk, since it's almost complete garbage these days. Nobody really understands it, nobody really does it very well (especially if we redact out financial services and insurance - and even then, look what happened to Wall Street risk models!), and more importantly, it's implemented so shoddily that there's no real, reasonable way to actually demonstrate risk remediation/reduction because talking about it means bringing in a whole other range of discussions (what is most important to the business? and how are risk levels defined in business terms
Re: [SC-L] NIST SP 800-37
800-37 has been in release for a while, providing the basis for the CA process. My understanding is that CA is evolving (and going the way of the dinosaur) very soon as NIST works with CNSS/JTF on the next big thing. I'm blanking on the rest of the details (not my space), but pinging Mike Smith (@rybolov) or Dan Philpott (@danphilpott) on Twitter would likely be a good starting point. On 2/3/10 1:12 PM, McGovern, James F. (eBusiness) wrote: NIST has created a draft document entitled: Guide for applying risk management framework to federal information systems: a security lifecycle approach. Curious to know if anyone has identified gaps, differences in opinion, etc between NIST and how either SAMM or BSIMM would define the same? 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. ___ -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Opportunity is missed by most people because it is dressed in overalls and looks like work. Thomas A. Edison ___ 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] How a stray mouse click choked the NYSE cost a bank $150K
NYSE has come out with findings on a Credit Suisse initiated DOS issue... something so small, yet so fundamentally flawed... http://arstechnica.com/business/news/2010/01/how-a-stray-mouse-click-choked-the-nyse-cost-a-bank-150k.ars -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Science is facts; just as houses are made of stones, so is science made of facts; but a pile of stones is not a house and a collection of facts is not necessarily science. Henri Poincare ___ 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] Blog skiiers versus snowboarders CISSPs vs programmers
I'm not even sure why we're talking about CISSPs in this regard. Having a CISSP proves nothing; it's merely a blind HR/recruiter checklist item. I've personally met dozens of CISSPs who can't answer the most basic of security questions. The short-term comes down to what Gary talked about recently, which is getting a software security group (or team) established and functioning well. Over time, outreach and education run by the SSG then begins to permeate the organization until, hopefully, some day, the SSG can shrink or dissolve and let security stand on its own. We obviously have a long way to go as an industry before we reach that point. fwiw. -ben Arian J. Evans wrote: The software security problem is a huge problem. There are not enough CISSPs to even think about solving this problem. CISSPs probably should have a tactical role helping categorize, classify, and facilitate getting things done. Scanner jockeys and network security folk will lead the operational charge to WAF and block and such. (good or bad, you're gonna need this stuff, the problem is just too darn big) I don't think many good devs who enjoy building are going to want to change careers to do source code audits. That gets mind numbing awfully fast. Developers definitely have a role to play in solving a lot of the basic syntax-attack stuffs, by proper selection and application of modern frameworks, technologies, and gap-APIs (like ESAPI). Most CISSPs lack the skill to provide much value here. Design issues will always exist, unless users some day wake up and decide they prefer security over usability. But I don't see that happening any time soon. Heck, my password on all my work machines is password. $0.02 USD. --- Arian Evans capitalist marksman. eats animals. On Tue, Jan 12, 2010 at 8:44 AM, Matt Parsons mparsons1...@gmail.com wrote: I wrote a blog in the state of software security using the analogy of skiers versus snowboarder in the early 90's. Please let me know your thoughts and comments by replying to this list or my blog. http://parsonsisconsulting.blogspot.com/ Thanks, Matt Matt Parsons, MSM, CISSP 315-559-3588 Blackberry 817-294-3789 Home office mailto:mparsons1...@gmail.com http://www.parsonsisconsulting.com http://www.o2-ounceopen.com/o2-power-users/ http://www.linkedin.com/in/parsonsconsulting http://parsonsisconsulting.blogspot.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. ___ -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] I have no special talent. I am only passionately curious. 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. ___
Re: [SC-L] InformIT: You need an SSG
Thanks for that excellent and detailed response, Steve. A few follow-up questions: 1) What sort of charter and executive support was/is necessary to establish a group like SSG, and to continue building on it? In particular, I wonder about how the mandate was established, and then supported over the year(s)? 2) How long has it taken to go from no SSG to a well-functioning SSG? What sort of ramp-up time was needed? 3) Is there a way to capture the SSG and IR approach into some sort of copy-n-paste model or framework that could be used to expedite replication within other orgs? Is it even realistic to think that this approach can be easily replicated? (somewhat ties back into mandate/support, I suppose) Thank you, -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke Steve Lipner wrote: Thanks for looping me in Gary - this is an interesting topic and one that I do have an opinion about (no surprise). (My apologies for the long delay responding - holidays and vacation rather than lack of interest). Microsoft created a central IR group before I joined the company, and we feel very strongly that the IR model we have is the right one. As things have evolved today, we centralize response policy, customer communications, security researcher (vulnerability finder) communications, press outreach, emergency response, vulnerability and fix security analysis, and response to complex (multi-product) vulnerabilities.Individual product teams are responsible for building secure code, and if a vulnerability is found they're responsible for fixing it. But we have central policies on update packaging and release so that we protect all customers in the same way and administrators don't have to learn a separate patching process for each product. For IR, the central group lets us speak with one voice to communities who would be confused or bothered by having to deal with a batch of different Microsofts. It also allows us to build a team that can specialize in deep technical security analysis - how bad is the impact this bug, is it an instance of a broader pattern that we should be searching for, does the proposed fix in fact fix the underlying problem? Answering those questions is specialized work, and it's unreasonable to expect that any but the biggest product groups could build or retain the necessary capability. I could share horror stories from 2000 and 2001 when really competent developers told me that a vulnerability wasn't exploitable to run code and then we found that it was. The competence to do that sort of analysis is a lot scarcer than the competence to write secure code - but vulnerabilities still arise, and the IR team needs the scarce kind of competence to plan the right response. For secure development, as I said above, we expect product teams to design and build secure software. But for a company like Microsoft with a central commitment to security, a central SSG allows us to develop and enforce common policies for what secure means. That's part of achieving the accountability (consequences) Ben refers to below. The SSG is also the place where we update policies and requirements, and develop new tools and techniques. The SDL tools (and guidance) that we've released at www.microsoft.com/sdl over the last year or so have all been developed in our SSG - most for our own in-house use. The SSG serves as a consulting resource on secure design - an area where the right solution will vary from product to product, and where it's beneficial for product teams to be able to appeal to folks who are focused on security and see a lot of problems and solutions. The final key role of the SSG is to provide the link back to vulnerability research (again something that only the biggest product teams could afford). Our SSG (Microsoft Security Engineering Center or MSEC) is part of the same organization as our IR team (Microsoft Security Response Center or MSRC) and we work closely as we're analyzing new security vulnerabilities and working to build on them, find patterns, and identify and remove new classes of vulnerabilities. The idea (I used to think it came from Earl Boebert but I believe he was quoting Rick Proto) is that theories of security come from theories of insecurity. We fully understand the need to keep MSEC from getting too large. Our budget and planning process are part of our answer to doing that - we're essentially a support function, and nobody wants that to get too large. We also avoid taking on tasks that should fall to product groups - I guess I could imagine a negative spiral where we did more and more of the work that product groups should do, and then had to get larger and larger
Re: [SC-L] [Esapi-user] [Esapi-dev] Recommending ESAPI?
building any Java app without ESAPI. :) (please note the I statement - I've been deep in the code for years, I'm not saying its easy - it requires significant investment of time to use all of ESAPI as it stands today). Another 18 hour day - I need sleep. :) Regards, - Jim ___ Esapi-dev mailing list esapi-...@lists.owasp.org mailto:esapi-...@lists.owasp.org https://lists.owasp.org/mailman/listinfo/esapi-dev -- Jim Manico OWASP Podcast Host/Producer http://www.manico.net ___ Esapi-user mailing list esapi-u...@lists.owasp.org mailto:esapi-u...@lists.owasp.org https://lists.owasp.org/mailman/listinfo/esapi-user ___ 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 tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] When will I learn? The answer to life's problems aren't at the bottom of a bottle, they're on TV! Homer Simpson ___ 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] new post: The Three Domains of Application Security
Of interest, I hope... http://www.secureconsulting.net/2010/01/the_three_domains_of_applicati.html -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] The unquestionable republicanism of the American mind will break through the mist under which it has been clouded, and will oblige its agents to reform the principles and practices of their administration. Thomas Jefferson to Elbridge Gerry, 1799. ME 10:83 ___ 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] Checklist Manifesto applicability to software security
I think there's lots of applicability. People - especially techies - cut corners. The pressure is usually to get things done in a certain amount of time, and then add on that people like to generally expend as little energy as possible, and viola! you see the problem. Of course, the flip side is that checklists in an area like IT can be detrimental, too. PCI is a great example, where it never made a claim of being comprehensive, yet is treated as such (and codified in State laws for crying out loud), and then orgs still get hacked, leaving them to wonder why the checklist didn't protect them. Perhaps the key, then, is knowing that you need experience+procedures. Procedures allow you to not screw up the mundane and routine, while experience allows you to dynamically respond to issues that don't fit the precise steps of the procedure. Part and parcel to this, then, is needing to empower experienced professionals to be flexible and dynamic in the vast of challenges rather than requiring them to rigidly adhere to procedure in all instances. Within appsec, QA and related security testing is probably a great example. If all QA could be strictly proceduralized, then you could just automate it all. However, testing doesn't always go as expected, requiring a functioning brain to (hopefully) respond and adapt accordingly. You probably need procedures for properly catching those exceptions, but nonetheless, those procedures automatically create a capacity for dynamic response. Sorry, a bit rambly... -ben Jeremy Epstein wrote: Greetings, I was listening yesterday to an interview [1] on NPR with Dr. Atul Gawande, author of Checklist Manifesto [2]. He describes the problem that medical procedures (e.g., surgery) tend to have lots of mistakes, mostly caused because of leaving out important steps. He claims that 2/3 of medical - or maybe surgical - errors can be avoided by use of checklists. Checklists aren't very popular among doctors, because they don't like to see themselves as factory workers following a procedure, because the human body is extremely complex, and because every patient is unique. So as I was listening, I was thinking that many of the same things could be said about software developers and problems with software security - every piece of software is unique, any non-trivial piece of software is amazingly complex, developers tend to consider themselves as artists creating unique works, etc. Has anyone looked into the parallelisms before? If so, I'd be interested in chatting (probably offlist) about your thoughts. --Jeremy [1] Listen to the interview at http://wamu.org/programs/dr/10/01/06.php#29280 [2] The Checklist Manifesto: How to Get Things Right, Atul Gawande, Metropolitan Books. ___ 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 tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Pareto Principle (a.k.a. The 80-20 Rule): For many phenomena, 80% of consequences stem from 20% of the causes. http://globalnerdy.com/2007/07/18/laws-of-software-development/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] seeking sponsors for SXSW Security BSides
Hi folks! For those not familiar, a handful of security people kicked off an unconference styled event during Black Hat this past July in Las Vegas termed Security BSides. The objective was to create a less formal setting where top-notch security speakers/experts could have direct conversations with people about topics of interest. The event was a huge success. Please see http://www.securitybsides.com/ for more details. Building on this success, a few more BSides events have started to emerge. One such place where we hope to try this out as at SXSW Interactive this coming March. Right now we are looking at hosting the event on Saturday, March 13th. In keeping with the BSides tradition, the idea is to find a venue that has adequate space for 100-200 people, as well as lounge space to allow folks to hang out, chill out, socialize, etc. In targeting SXSW, we're hoping to pull in attendees from the conference (especially non-security developers, managers, etc.). In order to make this happen, we need some help! We're looking for sponsors (named or unnamed - up to you) to help underwrite the event. BSides events do not charge attendees a fee in order to keep the format and discussions open. Contributions of any size would be welcomed. Support for past and future events includes monetary contributions, materials, personnel, and transportation. If you think you or your organization can help, please send email directly to me (tomh...@secureconsulting.net) and we can get you more information, discuss further, etc. Thank you! -ben -- Benjamin Tomhave, MS, CISSP tomh...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] It's not whether you get knocked down, it's whether you get up. Vince Lombardi ___ 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: You need an SSG
I think the short-term assertion is sound (setup a group to make a push in training, awareness, and integration with SOP), but I'm not convinced the long-term assertion (that is, maintaining the group past the initial push) is in fact meritorious. I think there's a danger in setting up dedicated security groups of almost any sort as it provides a crutch to organizations that then leads to a failure to integrate security practices into general SOP. What is advocated seems to be consistent with how we've approached security as an industry for the past couple decades (or longer), and I don't see this as having the long-term benefit that was desired or intended. It seems that when you don't make people directly responsible and liable for doing the right things, they then fail at the ask and let others do it instead. It's the old lazy sysadmin axiom that we script repeatable tasks because it's easier in the long run. The question, then, comes down to one of psychology and people management. How do we make people responsible for their actions such that they begin to adopt better practices? The basic response should be to enact consequences, and I think that now is probably an optimal time for businesses to get very hard-nosed about these sorts of things (high unemployment means lots of people looking for work means employers have the advantage). This perhaps sounds very ugly and nasty, and obviously it will be if taken to an extreme, but we have a serious problem culturally in that non-security people still don't seem to think, on average, that security is in their job description. Solve that problem, and all this other stuff becomes a footnote. fwiw. -ben Gary McGraw wrote: hi sc-l, This list is made up of a bunch of practitioners (more than a thousand from what Ken tells me), and we collectively have many different ways of promoting software security in our companies and our clients. The BSIMM study http://bsi-mm.com focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed in the BSIMM was that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities. I wrote about our observations around SSGs in this month's informIT article: http://www.informit.com/articles/article.aspx?p=1434903 Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We're still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.) Cigital's SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception, we've helped plan, staff, and carry out ten large software security initiatives in customer firms. One of the most important first tasks is establishing an SSG. Merry New Year everybody. 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. ___ -- 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: ] The only source of knowledge is experience. 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. ___
Re: [SC-L] new job!
Ditto on the new job for me, too! (thanks for reminder Dave) I've taken a position with Foreground Security and will also be moving back to NoVA. I start Monday and the movers come next Saturday. :) Looks like Dave and I need to put our heads together and host a NoVA-based thank you happy hour. :) -ben SC-L Reader Dave Aronson wrote: Since the Power that Be let me post my plea for job help, I figured I'd let y'all know the outcome. Long story short, I have accepted a position at Comcast, in the National Engineering and Technical Operations group, in Herndon VA (possibly moving to Reston VA soonish), starting in probably a week or two. I will no longer be in a position related to security, but will still participate here, and in the broader secure coding community, as time allows -- and keep trying to spread the gospel. ;-) Thanks for all your help, Dave -- 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: ] Practice does not make perfect. Only perfect practice makes perfect. Vince Lombardi ___ 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] Another WAF in town
Define firewall in this context, I guess, right? Something that controls network and application access, separate from the application itself? I don't recall it being defined in PCI DSS itself, so I'm sure it'll be fine so long as one can properly explain it to the QSA. :) -ben McGovern, James F (HTSC, IT) wrote: Interesting approach. Curious to know if this will satisfy a PCI auditor as a compensating control (section 6) -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Thursday, September 24, 2009 12:03 PM To: Secure Coding Subject: [SC-L] Another WAF in town FYI, some activity in the open source WAF space: http://www.darkreading.com/security/app-security/showArticle.jhtml?artic leID=220100630 Cheers, Ken - Kenneth R. van Wyk SC-L Moderator 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. ___ -- 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: ] Perhaps in time the so-called Dark Ages will be thought of as including our own. Georg Christoph Lichtenberg ___ 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] OT: suddenly out of work
Hi folks! Sorry for the off-topic traffic, but I find myself suddenly without a job today, without warning or severance. I'm currently based in Phoenix, AZ, but am open to travel or relocation. I've been published, including as the cover story for this month's ISSA Journal, have speaking experience, and have been doing this work for nigh on 15 years. Full resume is available here: http://falcon.secureconsulting.net/resume/Ben_Tomhave.pdf Thank you, and again apologies for interloping here, -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: ] The greatest challenge to any thinker is stating the problem in a way that will allow a solution. Bertrand Russell ___ 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. ___
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?
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] Announcing LAMN: Legion Against Meaningless certificatioNs
fwiw, I've interviewed my fair share of CISSPs who didn't have a basic understanding of infosec... with the boot camps these days, people don't learn anything... they cram for 1-2 wks, shoving everything into short-term rote memory, and then they take the test and promptly forget everything... this is especially true since the feds began mandating CISSPs for contractors... at least here in the DC metro, the pool of candidates has become extremely watered down over the last 5 or so years... Joe Teff wrote: I notice certs like CISSP when hiring. It says the person has a basic understanding of all IS security areas. Nothing more. If someone can't pass the CISSP then I have to wonder why. -Original Message- From: Paco Hope p...@cigital.com To: SC-L@securecoding.org SC-L@securecoding.org Date: Thu, 19 Mar 2009 11:36:45 -0400 Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs On 3/18/09 5:29 PM, Jeremy Epstein jeremy.j.epst...@gmail.com wrote: If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it ...then I'd say you have an overly simplistic view of the world. Anyone who believes that a credential automatically conveys some magical knowledge that you didn't have before is just as overly-simplistic as someone who disparages all credentials equally. It just isn't a black and white world. 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. ___ ___ 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 LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] I think there should be something in science called the 'reindeer effect.' I don't know what it would be, but I think it'd be good to hear someone say, 'Gentlemen, what we have here is a terrifying example of the reindeer effect.' 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] BSIMM: Confessions of a Software Security Alchemist(informIT)
I would argue that the security 'bugs' you've described are in fact functional deficiencies in the implemented design. That is, the exploit of them has a direct impact on functional performance of the application, even if it's just a problem with error handling (input validation). I would further argue that treating security as a special case ends up doing us more harm than good. Doing so allows developers, designers, and the business to shrug it off as Somebody Else's Problem (SEP), instead of owning it themselves. The same goes for the requirements, design, etc. As an industry, we've developed segments of specialized knowledge, and then have the audacity to complain about it not being mainstream. It's time we picked one, and I would argue that mainstreaming these concepts will be far more effective than continuing as a specialized bolt-on discipline (which is not to say that specialized research should not occur, just that in real life the application of this knowledge should not be specialized, per se). *shrug* The only way I see to win the game is to change the rules and/or the game play itself. We must never forget that the security industry still relies (heavily) on many of the same concepts that protected us 15 years ago (i.e. signature-based scans and ACLs - AV+firewall). -ben Goertzel, Karen [USA] wrote: No - that isn't really what I meant. There CAN be security bugs - i.e., implementation errors with direct security implications, such as a divide-by-zero error that allows a denial of service in a security-critical component, thus exposing what is supposed to be protected data. But there are also bad security decisions - these can be at the requirements spec or design spec level. If they're at the requirements spec level, they aren't bugs - they are either omissions of good security or commissions of bad security. An omission of good security is not encrypting a password. That isn't a bug per se - unless it's a violation of policy. But if there's no password encryption policy, then the failure to include a requirement to encrypt passwords would not be a bug or a violation of any sort (except a violation of common sense). It would still, however, result in poor security. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: Benjamin Tomhave [mailto:list-s...@secureconsulting.net] Sent: Fri 20-Mar-09 11:04 To: Goertzel, Karen [USA] Cc: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) So, what you're saying is that security bugs are really design flaws, assuming a perfect implementation of the design. Ergo, security bug is at best a misnomer, and at worst a fatal deficiency in design acumen. :) -ben Goertzel, Karen [USA] wrote: Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between software and security bugs? It seems to me that all bugs are software bugs, ... -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Hofstadter's Law: A task always takes longer than you expect, even when you take into account Hofstadter's Law. http://globalnerdy.com/2007/07/18/laws-of-software-development/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT)
So, what you're saying is that security bugs are really design flaws, assuming a perfect implementation of the design. Ergo, security bug is at best a misnomer, and at worst a fatal deficiency in design acumen. :) -ben Goertzel, Karen [USA] wrote: Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between software and security bugs? It seems to me that all bugs are software bugs, ... -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Hartree's Law: Whatever the state of a project, the time a project-leader will estimate for completion is constant. http://globalnerdy.com/2007/07/18/laws-of-software-development/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs
gee whiz, what if you have letters after your name that aren't meaningless certifications (like MS or PhD)? :) also, what if you have meaningless cert letters after your name, but only because of peer pressure? are we still allowed to join? :) Jeremy Epstein wrote: Colleagues, I'm pleased to announce the creation of LAMN, the Legion Against Meaningless certificatioNs. If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it - this group is for you. You can join LAMN on LinkedIn by searching in the groups area. Unlike so many other certifications, LAMN doesn't charge fees, require outrageously overpriced exams, or demand check-the-box continuing education. Hope to see many people joining this group - and feel free to pass this along! --Jeremy P.S. After you join the group, you can proudly write your name John Doe, LAMN - which conveniently also stands for Letters After My Name. I can't recall who suggested the term to me, but would be happy to give credit if someone wants to step forward and claim credit. ___ 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 LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Dusting is a good example of the futility of trying to put things right. As soon as you dust, the fact of your next dusting has already been established. George Carlin ___ 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] Positive impact of an SSG
. Those gains are exclusively the result of having mature and effective controls within our system and software development lifecycle, Routh says. This is a three-year-old initiative that educates and certifies developers in all DTCC environments in security. Developers are also provided with the necessary code-scanning tools and consulting and services help to keep production code close to pristine. --Sammy. Sammy Migues Principal, Technology 703.404.5830 - http://www.cigital.com Software confidence. Achieved. smig...@cigital.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. ___ -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Don't you wish there were a knob on the TV to turn up the intelligence? There's one marked 'Brightness,' but it doesn't work. Gallagher ___ 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] Positive impact of an SSG
either that or go back to making stuff up. BTW, I checked the BSIMM web site after I read your message. It worked for me. Try this? http://www.downforeveryoneorjustme.com/bsi-mm.com Brian On 3/11/09 10:48 AM, Benjamin Tomhave list-s...@secureconsulting.net wrote: I think it's an interesting leap of faith. Statistically speaking, 9 is a very small sample size. Thus, the proposed model will be viewed skeptically until it is validated with a much larger and more diverse sample. Putting it another way, there's no way I can take this to a small or medium sized org and have them see immediate relevance, because their first reaction is going to be those are 9 large orgs with lots of resources - we don't have that luxury. You quoted we can say with confidence that these activities are commonly found in highly successful programs - how do you define a highly successful program? What's the rule or metric? Is this a rule or metric that can be genericized easily to all development teams? My concern is exactly what you speculate about... organizations are going to look at this and either try to tackle everything (and fail) or decide there's too much to tackle (and quit). In my experience working with maturity models as a consultant, very few people actually understand the concept. Folks are far more tuned-in to a PCI-like prescriptive method. Ironically, the PCI folks say the same thing you did - that it's not meant to be prescriptive, that it's supposed to be based on risk management practices - yet look how it's used. Maybe you've addressed this, but it doesn't sound like it. I'd perhaps be better educated here if the web site wasn't down... ;) -ben Sammy Migues wrote: Hi Pravir, Thanks for clarifying what you're positing. I'm not sure how we could have been more clear in the BSIMM text accompanying the exposition of the collective activities about the need to take this information and work it into your own culture (i.e., do risk management). As a few examples: p. 3: BSIMM is meant as a guide for building and evolving a software security initiative. As you will see when you familiarize yourself with the BSIMM activities, instilling software security into an organization takes careful planning and always involves broad organizational change. By clearly noting objectives and goals and by tracking practices with metrics tailored to your own initiative, you can methodically build software security in to your organization’s software development practices. p. 47: Choosing which of the 110 BSIMM activities to adopt and in what order can be a challenge. We suggest creating a software security initiative strategy and plan by focusing on goals and objectives first and letting the activities select themselves. Creating a timeline for rollout is often very useful. Of course learning from experience is also a good strategy. p. 47: Of the 110 possible activities in BSIMM, there are ten activities that all of the nine programs we studied carry out. Though we can’t directly conclude that these ten activities are necessary for all software security initiatives, we can say with confidence that these activities are commonly found in highly successful programs. This suggests that if you are working on an initiative of your own, you should consider these ten activities particularly carefully (not to mention the other 100). p. 48: The chart below shows how many of the nine organizations we studied have adopted various activities. Though you can use this as a rough “weighting” of activities by prevalence, a software security initiative plan is best approached through goals and objectives. Your words (...BSIMM fails...) imply (to me) that you posit organizations attempting to use the collected wisdom in BSIMM will, inexplicably, look at it and say Okay, we have to do all 110 of these things exactly as written, so let's get started without regard to their local need. This is as opposed to, say, looking at it and thinking Here's what nine companies have spent dozens of person-decades and millions of dollars learning about what works; let's see what we can glean from that. Uh, okay. Yes, previous models exist. Although it may have come up in conversation, we did not ask any of the nine something like What model did you start with back in the beginning? because it simply isn't relevant to what we're trying to accomplish (documenting what successful organizations are doing), just as could and should aren't relevant. We asked What *are* you doing now? and documented it so others could
[SC-L] Wysopal says tipping point reached...
An interesting read. Not much to really argue with, I don't think. http://www.veracode.com/blog/2008/11/we%e2%80%99ve-reached-the-application-security-tipping-point/ -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Anticipate the difficult by managing the easy. Lao Tzu ___ 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] 0x000000.com SuiGenchi Demonstration
Has anybody had opportunity to look at this tool for PHP source code analysis? Just wondering about the relative merits vs other tools already available. http://www.0x00.com/?i=530 -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Think off-center. George Carlin ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] quick question - SXSW
First, thanks for that Bill, it exemplifies my point perfectly. A couple thoughts... one, targeting designers is just as important as reaching out to the developers themselves... if the designers can ensure that security requirements are incorporated from the outset, then we receive an added benefit... two, a re-phrasing around my original thought... somehow we need to get security thinking and considerations encoded into the DNA of everyone in the business, whether they be designers, architects, coders, analysts, PMs, sysadmins, etc, etc, etc. Every one of those topics you mention could (should!) have had implicit and explicit security attributes included... yet we're still at the point where secure coding has to be explicitly requested/demanded (often as an afterthought or bolt-on)... How do we as infosec professionals get people to the next phase of including security thoughts in everything they do... with the end-goal being that it is then integrated fully into practices and processes as a bona fide genetic mutation that is passed along to future generations? To me, this seems to be where infosec is stuck as an industry. There seems to be a need for a catalyst to spur the mutation so that it can have a life of its own. :) fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Augustine's Second Law of Socioscience: For every scientific (or engineering) action, there is an equal and opposite social reaction. http://globalnerdy.com/2007/07/18/laws-of-software-development/ William L. Anderson wrote: Dear Ben, having just been at SXSW Interactive (I live in Austin, TX) I did not see many discussions that pay attention to security, or any other software engineering oriented concerns, explicitly. There was a discussion of scalability for web services that featured the developers from digg, Flickr, WordPress, and Media Temple. I got there about half-way through but the discussion with the audience was about tools and methods to handle high traffic loads. There was a question about build and deployment strategies and I asked about unit testing (mixed answers - some love it, some think it's strong-arm micro-mgt (go figure)). There was a session on OpenID and OAuth (open authorization) standards and implementation. These discussions kind of assume the use of secure transports but since I couldn't stay the whole time I don't know if secure coding was addressed explicitly. The main developer attendees at SXSW would call themselves designers and I would guess many of them are doing web development in PHP, Ruby, etc. I think the majority of attendees would not classify themselves as software programmers. To me it seems very much like at craft culture. That doesn't mean that a track on how to develop secure web services wouldn't be popular. In fact it might be worth proposing one for next year. If you want to talk further, please get in touch. -Bill Anderson praxis101.com Benjamin Tomhave wrote: I had just a quick query for everyone out there, with an attached thought. How many security and/or secure coding professionals are prevalently involved with the SXSW conference this week? I know, I know... it's a big party for developers - particularly the Web 2.0 clique - but I'm just curious. Here's why: I'm increasingly frustrated by the disconnect between business/dev and security. I don't feel like we're being largely successful in getting the business and developers to include security as part of their standard operating procedures. Developers are still oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection holes. I then look at SXSW from afar and think: a) shouldn't I be there evangelizing security? and, b) shouldn't a major thread to all these conferences be about how security is integrating with dev processes and practices, making it better? Maybe I'm just too idealist. I'm curious what everyone else thinks. cheers, -ben ___ 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] quick question - SXSW
I had just a quick query for everyone out there, with an attached thought. How many security and/or secure coding professionals are prevalently involved with the SXSW conference this week? I know, I know... it's a big party for developers - particularly the Web 2.0 clique - but I'm just curious. Here's why: I'm increasingly frustrated by the disconnect between business/dev and security. I don't feel like we're being largely successful in getting the business and developers to include security as part of their standard operating procedures. Developers are still oftentimes lazy and sloppy, creating XSS and CSRF and SQL injection holes. I then look at SXSW from afar and think: a) shouldn't I be there evangelizing security? and, b) shouldn't a major thread to all these conferences be about how security is integrating with dev processes and practices, making it better? Maybe I'm just too idealist. I'm curious what everyone else thinks. cheers, -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. Edward P. Tryon ___ 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] PCI: Boon or bust for software security?
Worse than that, I think that until businesses universally understand the value of secure coding practices, they will resist the up-front cost to take on such a transformational program. SOX vs PCI would make for a good case study. SOX is very high level and generic, which led to much confusion and wasted money initially. Some orgs were able to leverage it for the first year or two to drive improved security practices, but it seems that, for the most part, this leverage is gone. PCI, on the other hand, is for the most part quite specific (despite some ambiguity due to poor writing quality). It has primarily resulted in a checklist-oriented approach to compliance and has not seemingly led to transformational change, but rather many spot fixes. While it is still usable to leverage organizations, and it has moved the needle a little bit in terms of baseline security practices, overall I'd put it's effect on par with SOX. Thus, you have two sets of regulations that used very different approaches, but with very similar results: relative ineffectiveness. For me, this raises the question, Can regulation be used to stimulate the business to undertake transformational change to adopt and integrate holistic, pervasive security practices? The problem, I think, is that PCI is too easily relegated by the business to IT. This can be the case because PCI is technically specific. SOX, on the other hand, was not specific enough, and so eventually became almost dismissable by the business, eventually with minimal involvement from IT (perhaps a gross oversimplification). The key, then, seems to be in trying to construct requirements that will stick with the business instead of being easily delegated. Perhaps something risk-oriented would have the desired effect... fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. Edward P. Tryon On Tue, March 4, 2008 09:02, Andy Murren wrote: Overall I concur with Bruce on this. PCI has too broad of a constituent base to cover to be truly effective. Some fixes were added after the TJX breach, but look at how much TJX paid versus how much the laid aside to pay. I am betting that the TJX lawyers produced documents showing that they were PCI compliant, and that Visa had accepted the annual findings. In the end TJX was able to claim that they were not negligent because they were PCI compliant. While PCI 1.1 points to OWASP for in house developed web applications, where are the standards for 'PCI Approved' vendor development? How secure is the development process at the middleware vendor that is part of that web app, how good are the standards those organizations use and are held to? I think until there is an industry wide generally accepts, and pushed, standard for integrating secure development into the SDLC we will see band aid approaches like the updated PCI. 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. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] OWASP Publicity
James, You misunderstood my comments wrt older technologies. My points were: 1) We should not expect people rooted in older technology contexts to naturally understand problems in modern technology contexts if their jobs have not required them to evolve their thinking. 2) In trying to effectively communicate challenges to these business leaders, it may be useful to understand their context and provide correlated examples in the context they understand, rather than stubbornly insisting that they update their context. As people age, change becomes increasingly difficult to handle (this is a truth of psychology and neuroscience), so we should not assume that they will be able to easily adjust their context. As responsible security professionals, we should find a way to bridge the gap, getting the same points across in language that they'll understand. The other point made was that there continues to be a disconnect with business leaders in that they seem fine making business decisions, but then panic when it becomes an IT decision. The point here is that we should be extremely diligent in casting IT/security decisions as business decisions and reassuring them that the thought processes are the same. The only potential downfall is that it then puts additional responsibilities on our security shoulders to make sure we've presented the business risk analysis adequately to properly support a risk decision. Lastly, yes, I agree it's a red flag when execs meddle in the affairs of techies, but it happens a lot, and we should be prepared for dealing with it. This problem becomes especially challenging in light of #1 above, wherein their context is tied to outmoded technologies and the associated ways of thinking. This does _not_ mean we should limit our options to those outmoded technologies, but that we need to be cognizant of the limited thought context and provide adequate explanation that is _understood_ when challenging what is happening and providing alternatives. cheers, -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt On Mon, November 19, 2007 11:00 am, James Stibbards wrote: Ben, Good comments. It may be true that older technology is what today's Sr Managers have the most familiarity with, however... In my opinion, it's not that familiarity that we (or they) should rely on, in order to be well-informed, and thus be making good security-related decisions. It's no longer their job to be into the details of that technology, unless they are the CTO (for example), and if they are into the details... That's actually a red flag to me that they're likely *not* doing their actual job, today, as a Sr. Manager. [Slight rant: It *is* the responsibility of the management team of the organization, overall, to be sure that information which is critical to the organization be conveyed, abstracted or not, up and down the layers of the entire omanagement and individual contributors... to accomplish whatever organizational goals exist. (see more, below).] If a Sr Manager was once familiar with COBOL (I chuckled at the recent COBOL SC-L postings...), but the issues are now WinMobile and AJAX, then it's really the responsibility of someone in the organzation to have synthesized and presented the security issues, opportunities, and costs as they relate to WinMobile/AJAX/etc. to senior management as Business Issues. At other layers in the organization, yes, there are Technology issues, concerns, joy and grief... But not at the Executive levels, because that's not their job(!). As an aside...since security means so many things to so many people, here is a 4-layer model that I use with a lot of my customer to help position what we do, in the vast landscape of security: 1. Business/Mission objectives - what are we trying to accomplish? 2. Systems Architecture - how is this being instantiated, in terms of systems, communication, storage, etc? 3. Security Architecture - what specific technology and processes are we using to reduce risk, introduce control mechanisms, etc. 4. Protection Technology - how do we lock down the #3, so it can be resistant to attack, itself. I've used this over and over again, in helping to frame discussions of what should or could be done, so that they're not confusing. For example, a question of policy with a question of choice of technology selection. A few days early, but Happy Thanksgiving, to all! - James James W. Stibbards Sr. Director - Sales Engineering Cloakware, Inc. email: [EMAIL PROTECTED] phone: 703-752-4836 cell: 571
Re: [SC-L] OWASP Publicity
I agree and disagree with these comments, as I think they possibly represent an outmoded way of thinking when it comes to IT management. Execs and senior mgmt _must_ have a certain understanding of security that will at least give them a basis for making risk decisions. It seems today that they are fine (generally) making business risk decisions, but then believe falsely that making an IT risk decision requires following a completely different set of rules (when, in fact, it's just another kind of business risk decision). I'm of the belief that this directly correlates to their lack of fundamental understanding of IT and security issues. Where I agree is the level of detail that needs to be imparted. OWASP Top 10 is probably too much detail to communicate to the average exec or sr manager. However, we must not overlook that these business leaders were once individual contributors. Yes, it's true that some of these folks came up through a strictly business route, but for the most part these days I see these careers originating in at least a semi-technical role. We should be seeking to leverage those backgrounds to educate them and bring them to modern times. On Crispin's later comments about bad vs good managers, I think he's very much hit the nail on the head (see the quote in my sig). However, there's one aspect that's overlooked, which is outdated prior history. If an executive's understanding of technology is founded in their first contributions as an individual contributor 10-20 years ago, then this means their understanding of modern technology may be severely limited. I'm sure all of us understand how difficult it is to stay on top of current trends as technology evolves, and it's often our job to do so. What if it's not your job to keep current? The times will change while your focus is elsewhere, but only a truly savvy person will think to check that context before making decisions that affect it. This seems to be a rarity. So, to conclude, I think that it would be valuable, in broad brush strokes, to educate leaders about secure coding - and security in general - but perhaps not to the level of detail we might really desire to see. We want execs and sr managers to drive their folks toward secure coding practices, but that doesn't mean they themselves have to know how to code securely. As such, in targeting these other publications, the message should be refined to be business-oriented, extolling the business risks associated with ignoring these practices and providing a big arrow pointing in the direct of orgs like OWASP. fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ [ Random Quote: ] If a man is offered a fact which goes against his instincts, he will scrutinize it closely, and unless the evidence is overwhelming, he will refuse to believe it. If, on the other hand, he is offered something which affords a reason for acting in accordance to his instincts, he will accept it even on the slightest evidence. The origin of myths is explained in this way. Bertrand Russell Crispin Cowan wrote: McGovern, James F (HTSC, IT) wrote: I have observed an interesting behavior in that the vast majority of IT executives still haven't heard about the principles behind secure coding. My take says that we are publishing information in all the wrong places. IT executives don't really read ACM, IEEE or other the sporadic posting from bloggers but they do read CIO, Wall Street Journal and most importantly listen to each other. What do folks on this list think about asking the magazines and newspapers to publish? I am willing to gather contact information of news reporters and others within the media if others are willing to amplify the call to action in terms of contacting them. The vast majority of IT executives are unfamiliar with all of the principles of security, firewalls, coding, whatever. The important thing to understand is that such principles are below their granularity; then are *right* to not care about such principles, because they can't do anything about them. Their granularity of decision making is which products to buy, which strategies to adopt, which managers to hire and fire. Suppose they did understand the principles of secure coding; how then would they use that to decide between firewalls? Web servers? Application servers? If anything, the idea that needs to be pitched to IT executives is to pay more attention to quality than to shiny buttons features. But there's the rub, what is quality and how can an IT executive measure it? I have lots of informal metrics that I use to measure quality, but they largely amount to synthesized reputation capital, derived from reading bugtraq and the like with respect to how many vulnerabilities I see with respect to a given product, e.g
[SC-L] [Fwd: Seeking questions for Panel discussion on website vulnerability disclosure during OWASP-WASC AppSec Conference on Nov 15]
Forwarding with permission... please send feedback directly to Anurag as he is not currently a member of this list. -ben -- [ Random Quote: ] Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts. William Gibson Original Message Subject: Seeking questions for Panel discussion on website vulnerability disclosure during OWASP-WASC AppSec Conference on Nov 15 Resent-Date: Tue, 6 Nov 2007 09:57:45 -0700 (MST) Resent-From: [EMAIL PROTECTED] Date: Mon, 5 Nov 2007 16:46:51 -0800 From: Anurag Agarwal [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] I am not sure if everyone knows about the panel discussion on Website Vulnerability Disclosure during the OWASP-WASC AppSec Conference on Nov 15. I will be moderating that panel and wanted this to be an honest discussion between a hacker, a corporate and govt. I know there was an email thread few days ago on Full disclosure of security vulnerabilities so i thought i will send this to the list as well. I am interested in knowing what people would like to know or what questions they would like them to discuss on. you can find the details of the panelists and other stuff on the following posting. http://myappsecurity.blogspot.com/2007/11/panel-discussion-on-website.html Feel free to send in questions (i dont care how crazy, inciting or provocative it is). You can send it to me directly or post as a comment on my blog or if the moderator of the mailing lists dont mind then reply to the list. Cheers, Anurag Agarwal Blog: http://myappsecurity.blogspot.com Email: [EMAIL PROTECTED] Web: www.myappsecurity.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] Bernstein's new paper on secure coding
Daniel J Bernstein, author of the qmail MTA, has written an interesting, short paper on qmail security and the secure coding practices that went into it. I imagine folks here will find it of interest, too. http://cr.yp.to/qmail/qmailsec-20071101.pdf -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt ___ 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] Sw Dev Laws, Engineers and Feasibility
Ok, rather late in posting these, but thought it might help you get your week off to a good start. The first link is a list of laws of software development. You've undoubtedly heard of many of them, but it's still nice to have a single place of reference for them. Especially when faced with making arguments against silly projects. Speaking of which, I've also added a second link below that is somewhat tongue-in-cheek defining what certain key terms mean to engineers with respect to feasibility of projects. Enjoy! :) Laws of Software Development http://globalnerdy.com/2007/07/18/laws-of-software-development/ Understanding Engineers: Feasibility http://fishbowl.pastiche.org/2007/07/17/understanding_engineers_feasibility cheers, -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil rights and civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt ___ 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] author contends CompSci != Maths
Caught this on /. this morning, maybe you did, too. Pretty interesting reading, really. The fundamental argument is that algorithms are inadequately expressive to suit CompSci today. If you look at all the attempts in 3GL, 4GL, 5GL and beyond to be more expressive, and if you've ever listened to Donal Knuth speak, you might start tending to agree with the argument. What do you think? http://www.itwire.com.au/content/view/13339/53/ --- Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil rights and civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt ___ 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] Technology-specific Security Standards
In my experience, a tiered approach is useful. The higher up you are in the policy framework, the more general and time-enduring the content should be. The farther you progress down the framework to a more detailed level, the more perishable the content will be, out of necessity. The reason that we've adopted specific guidance bound at the technical level is because implementers need it. They're not security experts (usually) and do not necessarily grok security the same way a seasoned (salty?) security person might. A couple colleagues and I actually chatted about this around the same time that the original message here is timestamped, in the context of application security standards. The approach we're planning to adopt is to provide good, minimally-specific guidance in our formal standards documents (e.g. implement input validation) and the produce living implementation guides (possibly in a wiki form) that can be referenced in relation to the standards. We'll see how this works in reality, but it seems to be a nice mix in theory between provide specific requirements without getting so far into the weeds that it will require constant rewriting as the underlying technologies change. fwiw. -ben --- Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil rights and civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Steven Sent: Wednesday, May 23, 2007 2:39 PM To: SC-L@securecoding.org Subject: [SC-L] Technology-specific Security Standards All, My last two posts to Cigital's blog covered whether or not to build your security standards specific to a technology-stack and code-centric or to be more general about them: http://www.cigital.com/justiceleague/2007/05/18/security-guida nce-and-its-%e 2%80%9cspecificity-knob%e2%80%9d/ And http://www.cigital.com/justiceleague/2007/05/21/how-to-write-g ood-security-g uidance/ Dave posted a comment on the topic, which I'm quoting here: - Your point about the ³perishability² of such prescriptive checklists does make the adoption of such a program fairly high maintenance. Nothing wrong with that, but expectations should be set early that this would not be a fire and forget type of program, but rather an ongoing investment. - I agree, specifying guidance at this level does take a lot more effort; you get what you pay for eh? I responded in turn with a comment of my own. I've seen some organizations control this cost effectively and still get value: See: http://www.cigital.com/justiceleague/2007/05/18/security-guida nce-and-its-%e 2%80%9cspecificity-knob%e2%80%9d/#comment-1048 Some people think my stand controversial... What do you guys think? John Steven Technical Director; Principal, Software Security Group 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. ___ 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 defines an InfoSec Professional?
I'm gonna have to go ahead and disagree with you, there, Michael. You're looking at things far too narrowly. And here's a very simple example: Small business. Single DMZ. Hosts DB and Web App on separate platforms. Web app needs to make back-end calls to DB. There's no reason whatsoever why the DB itself needs to be directly exposed to the Internet. Thus, you implement a firewall that restricts ingress access on ports 80/443 to the web server only. This scenario would exist irregardless of the quality of the underlying code, based on principles of default deny, defense in depth, segregation of duties, etc. In other words, don't put all your eggs in the securely coded basket. --- On the original topic... I don't think titles or certifications or even security-related actions make a security professional. I know personnel within security departments who perform access management tasks without a solid understanding of what all is contained within infosec. They don't know the security triad (C-I-A), they don't necessarily have a sound understanding of why they're doing what they do, etc. Yet they have security in their titles. Similarly, I've interviewed many a CISSP who I would not consider to be an infosec professional. Just because you can memorize a few facts within the 10 infosec domains does not mean you get it. I would even go so far as to say that just because a developer reads the OWASP Top 10 and then begins performing input validation does not make them an infosec professional. It makes them a better developer. Bottom line, then, is that a true infosec professional should be defined as someone working in a dedicated security role who distinguishes themselves by their level of knowledge, wisdom, and experience that can be demonstrably applied within the infosec genre. fwiw tgif. cheers, -ben -- Benjamin Tomhave, MS, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/profile?viewProfile=key=1539292 Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt On Fri, March 9, 2007 7:54 am, Michael S Hines wrote: I respectfully disagree. The need for a firewall or IDS is due to the poor coding of the receptor of network traffic - so you have to prevent bad things from reaching the receptor (which is the TCP/IP stack and then the host operating system - and then the middleware and then the application). The reason you have to prevent bad things from reaching the receptor (OS) is because of poor coding practices in the receptor (OS). In terms of state diagrams - you have an undefied state in the code - which produces unpredictable actions. Technically speaking, it's undesireable but predictable actions - that's how the software can be used to gain unauthorized entry. And once someone finds the hole - the very mechanism used for protection (networks) is used to spread the story. Kind of like the farmer eating his seed corn. :) Regarding roles - there are many who do Infosec - in many different roles. Law makers, lawyers, Boards of Directors, management, policy staff, technical staff, network engineers, programmers, quality assurance staff, users, ethical hackers, unethical hackers, et al. I'm not sure we're moving the industry forward by trying to say I am one but You are not - are we? Mike Hines - Michael S Hines [EMAIL PROTECTED] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] differences between Threat Analysis and Threat Modeling
Jason, I differentiate between the two like this: Threat Analysis looks at specific threats (e.g., msblaster, zotob, latest exploit of pick your fav sw/os). Threat Modeling looks at classes of threats (e.g., network-distributed malware, OS vulnerabilities of Type). Threat analysis is used as a component to various assessment techniques (vulnerability scanning, code review, etc.). The aggregation of data from multiple threat analyses within a define class of threat can then be used to develop a model of that threat. Threat modeling can then be used to look at the overall security and resilience of a system, instead of focusing on the minutae of every individual threat. Ergo, foci on anti-virus, OS hardening, patch management, etc. Practices developed in response to the modeling of classes of threats, the models for which were developed from analysis of the threats that resulted in their classification. Or something like that... cheers, -ben --- Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/profile?viewProfile= http://www.linkedin.com/profile?viewProfile=key=1539292 key=1539292 Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil rights and civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Grembi Sent: Wednesday, February 14, 2007 4:12 PM To: sc-l@securecoding.org Subject: [SC-L] differences between Threat Analysis and Threat Modeling Hi Ken, I am currently researching the differences between Threat Analysis and Threat Modeling. I thought your readers on the mailing list may give me a clearer distinction. How I understand it is that both identify security threats, determine risk, and create the right countermeasures by analyzing various types of documentation about the system and looking for vulnerabilities and/or areas of weakness. Threat Analysis - is more informal way of 'eyeballing' system architecture and application design. Threat Modeling [Microsoft SDL] - more formal, every requirement is modeled and scrutinized. Any additional help you or your readers can provide would be appreciated. Thanks Jason Grembi Web Developer ___ 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] WEB2.0 Security Issues
as an agitator? This is not to say that there aren't potential benefits, particularly in terms of unlocking the long tail to market better to consumers. It just provides the start of the slippery slope argument. We need keep in mind the need to balance civil liberties against universal trackability. Why does privacy need to be an illusion? (*Note: A special thanks to my friend Bob Alberti of Sanction, Inc., for proof-reading and providing input on this posting.) --- Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/pub/0/622/964 Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ We must scrupulously guard the civil rights and civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avi Shvartz Sent: Thursday, January 25, 2007 2:06 AM To: sc-l@securecoding.org Subject: [SC-L] WEB2.0 Security Issues Hello list, Lately I read some articles that cover WEB2.0 from various aspects (social, technical etc.). What I am missing is a reference to security privacy issues related to WEB2.0. I would like to hear opinions what are the new security privacy concerns that WEB2.0 Creates and if possible, links to relevant resources Thanks, Avi ___ 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] Vulnerability tallies surged in 2006 | The Register
This is completely unsurprising. Apparently nobody told the agile dev community that they still need to follow all the secure coding practices preached at the traditional dev folks for eons. XSS, redirects, and SQL injection attacks are not revolutionary, are not all that interesting, and are so common-place that it makes one wonder where these developers have been the last 5-10 years. Solution to date: throw out traditional design review, move to agile security testing. Why? Because there seems rarely to be a design to review, and certainly no time to do it in. Overall, it's important that agile apps be built on an underlying publishing framework so that inherited vulns can be found and fixed across the board by focusing on a single platform. Next challenge: new year, new technology fads. Web 2.0 is another code word for that's so last year. Time to play catch-up, and January isn't over yet! *sigh* Oh, and speaking of Web 2.0, who's protecting the customer and their data? Better yet, who owns which data? With mashups being the buzz word du jour, you may think your data is on SiteA, when in fact it's spread across SiteB, SiteC, and SiteD. Wheee. One bit of good news: agile dev has often meant, in my experience, rapid resolution of discovered vulns. Since you don't have the full SDLC (or comparable) process to follow, or even a formalized patch mgmt process, it's often just a matter of finding bugs (through targeted hyper-testing - think flash-bang), sending them to the devies, waiting 10-30 minutes, and watching the vuln disappear like magic. Am curious how change mgmt works on that, though... ;) cheers, -ben --- Benjamin Tomhave, CISSP, NSA-IAM, NSA-IEM [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/pub/0/622/964 Blog: http://www.secureconsulting.net/ We must scrupulously guard the civil rights and civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization. -President Franklin Delano Roosevelt _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk Sent: Monday, January 22, 2007 1:24 PM To: Secure Coding Subject: [SC-L] Vulnerability tallies surged in 2006 | The Register FYI, CERT/CC reported 8064 software vulnerabilities in 2006, for a 35% increase over 2005. See http://www.theregister.co.uk/2007/01/21/2006_vulns_tally/ The article further states, The greatest factor in the skyrocketing number of vulnerabilities is that certain types of flaws in community and commercial Web applications have become much easier to find, said Art Manion, vulnerability team lead for the CERT Coordination Center. 'The best we can figure, most of the growth is due to fairly easy-to-discover vulnerabilities in Web applications, Manion said. They are easy to find, easy to create, and easy to deploy.' Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
