Re: [SC-L] Vulnerability tallies surged in 2006 | The Register
You also are not taking into account the number of vulnerabilities that are discovered by security consultants under NDA which are never published. I have lost the count on the number of vulnerabilities (at the time zero-days) that I have discovered in commercial software and where never published (and in some cases even patched or communicated to their clients/users). And when talking to my peers, I would estimate that if these vulnerabilities discovered under NDAs where reported, the number below would be much, much, much bigger. Maybe one day when companies are forced (by law) to disclose the vulnerabilities that they know exist in their products (maybe in a format similar to http://research.eeye.com/html/advisories/upcoming/), we will have a good picture of what is really going on. Dinis Cruz Chief OWASP Evangelist http://www.owasp.org On 1/24/07, pete werner <[EMAIL PROTECTED]> wrote: This strikes me as largely meaningless, bordering on good news. More bugs found = more bugs fixed = more secure software. I dont really think you can compare the numbers from 2001 and 2006 though. There's way more people looking for bugs now than there were in 2001. Maybe there were more bugs around in 2001 as secure coding practises still weren't well known, and security was nowhere as mainstream as it is now, so your average developer was less aware of secure coding practises and techniques. Also, nowadays people rush to disclose vulnerabilites, no matter how minor they may be. There were plenty of vulnerabilites discovered in 2001 that weren't publicly disclosed, and some that probably still remain undisclosed. I would be interested to see what conclusions you can actually draw from these figures (really). On 1/23/07, Kenneth Van Wyk <[EMAIL PROTECTED]> wrote: > > 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. > ___ > > > > ___ 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] Vulnerability tallies surged in 2006 | The Register
This strikes me as largely meaningless, bordering on good news. More bugs found = more bugs fixed = more secure software. I dont really think you can compare the numbers from 2001 and 2006 though. There's way more people looking for bugs now than there were in 2001. Maybe there were more bugs around in 2001 as secure coding practises still weren't well known, and security was nowhere as mainstream as it is now, so your average developer was less aware of secure coding practises and techniques. Also, nowadays people rush to disclose vulnerabilites, no matter how minor they may be. There were plenty of vulnerabilites discovered in 2001 that weren't publicly disclosed, and some that probably still remain undisclosed. I would be interested to see what conclusions you can actually draw from these figures (really). On 1/23/07, Kenneth Van Wyk <[EMAIL PROTECTED]> wrote: > > 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. > ___ > > > > ___ 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
Benjamin Tomhave wrote... > 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. I think many in the security community have had similar thoughts for years. IIRC, I think Gary McGraw even made a prediction at one point that agile development methods would be the worst setback to information security in years, or something to that affect. (At least I think it was Gary. If not, my bad memory is at fault. Or perhaps I should say... my bad...memory?) Agile development is good at things when their users have some idea of how they'd like to see the system work, so it usually works fairly well for things like laying out screens, workflow, etc. as well as many business applications which are presently being done manually. However, generally these users are clueless when it comes to security. If the developers were using a more traditional SDLC and their users were writing up business requirements, the typical requirement (ones I have actually seen) are things like "The user must login" and "The system must be secure". That's about as sophisticated as they get. If your have developers are know a lot of security, then they _might_ make it work, but the agile development methods, which emphasizing working closely with your users, doesn't work well for security matters because most users don't even know what to ask for. IMO, another reason why agile development fails miserably to result in secure programs is because security cuts across the grain of the entire application. While you can have a trusted kernel or whatever be a logically isolated component, much of security has to be DESIGNED IN, FROM THE START. Because all it takes is a single incorrectly functioning piece to ruin your entire security. Most agile development teams that I've seen here think that they can leave security issues to the end that then put in in that special "security module". One problem is that security must be anywhere that untrusted input can come from which is usually quite a few places. In that sense, trying to add in security to an application developed using agile methods is similar to attempting to add concurrency / multi-threading to an application after-the-fact. Sure, you _can_ do it, but what it results in is a system with a few course grained locks and very little concurrency. Concurrency cuts across various aspects, just like security does. That's why I don't see it as a particularly good fit for agile development. (OTOH, I think it should be a great fit with Aspect Oriented Programming, but that's another topic.) And while I'm on a roll (at least in the ego of my own mind ;-) one other place that I think is a rotten match for agile development. If the software you are developing is supposed to be a reusable class library, I don't find agile development a particularly good fit. Publish the interfaces of a reusable class library for the first release and then go ahead and just try to refactor those interfaces after you have a 1/2 dozen clients using release 1.0. If they don't skin you alive, they certainly won't be your clients for your next release. But enough rambling. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 "The reason you have people breaking into your software all over the place is because your software sucks..." -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit 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. ___
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. ___
