[SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
So, how can we edit current basic programming college books to present secure code, a couple of words of the correct way of doing things, and a whole new chapter on secure coding (which may be redudndent?) How do we start? Some Whiley book for introduction to CS? Any volunteers to get this on the road? Gadi. On Wed, 11 Oct 2006, Kenneth Van Wyk wrote: > So here's a lovely statistic for the software community to hang its > hat on: > > http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed > > Among other things, the article says, "Atlanta-based ISS, which is > being acquired by IBM, predicts there will be a 41 percent increase > in confirmed security faults in software compared with 2005. That > year, in its own turn, saw a 37 percent rise over 2004." > > Of course, the real losers in this are the software users, who have > to deal with the never ending onslaught of bugs and patches from > their vendors. We've just _got_ to do better, IMHO, and automating > the patch process is not the answer. > > Cheers, > > Ken > - > Kenneth R. van Wyk > 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
Re: [SC-L] darkreading: voting machines
Jeremy Epstein: > Interesting point. I'm on the Virginia state commission charged with making > recommendations around voting systems, and we watched the Princeton video as > part of our most recent meeting. The reaction from the election officials > was amusing and scary: "if this is so real, why don't you hack a real > election instead of this pretend stuff in the lab". Pointing out that it > would (most likely) be a felony, and people like Rubin, Felten, and others > are trying to help security not go to jail didn't seem to impress them. > Also pointing out that the Rubin & Felten examples used out-of-date code > because vendors won't share anything up-to-date doesn't seem to impress > them. [This in response to Diebold's claim that they were looking at old > code, and the problems are all "fixed".] I'm willing to believe that the ELECTIONS are fixed. Since they lack a voter-verifiable paper trail, _no_ DRE can be trusted. Period. I used to do magic tricks, and they all work the same way - misdirect the viewer, so that what they think they see is not the same as reality. Many magic tricks depend on rigged props, where what you see is NOT the whole story. DREs are the ultimate illusion - the naive THINK they know what's doing, but in fact they have no way to know what's really going on. There's no way to even SEE the trap door under the box, as it were... DREs are a great prop for the illusion. Printing "zero" totals and other stuff looks just like a magic show to me - it has lots of pizazz, and it distracts the viewer from the fact that they have NO idea what's really going on. > I frankly don't think anything is going to impress the election officials > (and some of the elected officials) short of incontrovertible evidence of a > DRE meltdown - and of course, we know that there could well be a failure > (and may have been failures) that are unproveable thanks to the nature of > software. I'm of the opinion that elections using DREs have ALREADY been manipulated. No, I can't prove that an election HAS been manipulated, and I certainly can't point to a specific manufacturer or election. And I sincerely hope that no elections HAVE been manipulated. But there's a LOT of money riding on big elections, and a small fraction of that would be enough to tempt someone to do it. And many people STRONGLY believe in their cause/party, and might manipulate an election on the grounds that it's for the "greater good" - it need not be about money at all. It's crazy to assume that no one's done it, when it's so easy and the systems are KNOWN to be weak. The whole problem is that DRE designs make it essentially impossible to detect massive fraud, almost impossible to find the perpetrator even if you detected it, and allow a SINGLE person to control an entire election (so there's little risk of a "squeeler" as there is with other frauds). And if an unethical person knows they won't be caught, it INCREASES the probability of them doing it. Anyone who thinks that all candidates and parties are too honest to do this need to discover the newspaper and history books. Ballot-stuffing is at least as ancient as ancient Greece, and as modern as Right Now. These voting systems and their surrounding processes would not meet the criteria for an electronic one-armed bandit in Las Vegas. Yet there's more at stake. The state commissions cannot provide any justifiable evidence that votes are protected from compromise if they use DREs. And that is their job. DREs are unfit for use in elections that matter. They should be decommissioned with prejudice, and frankly, I'd like to see laws requiring vendors to take them back and give their purchasers a refund, or add voter-verified paper systems acceptable to the customer at no charge. (The paper needs to meet some standard too, so that you can use counting machines from different manufacturers to prevent collusion.) At no time was this DRE technology appropriate for use in voting, and the companies selling them would have known better had they done any examination of their real requirements. The voters were given a lemon, and they should have the right to get their money back. --- David A. Wheeler ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Google code search: good or bad?
Fair enough. It's pretty darn fun to search for silly things. My favorite so far is to search for "**cker" (you fill in the blanks yourself). Surprising how many people curse in their comments. Given the importance of config files for most modern frameworks, searching for XML config foo is interesting as well. gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: mikeiscool [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 4:50 PM To: Gary McGraw Cc: SC-L@securecoding.org; Neil Daswani Subject: Re: [SC-L] Google code search: good or bad? good or bad, it's quite old. www.koders.com has been doing it for years. considering the source is available for anyone to download anyway, and investigate themselves, i don't see the big deal. the engines just let you search a whole bunch at once, and why would any one company/product care about that? if you want to target them, you do. if you just want to find a bug in any given open source product, then one of these may be slightly useful. if the main concern is that code can accidently get online, well that problem has been around forever and will never go away. better to expose it and have it dealt with, really. all in all, no big deal. jmho. -- mic On 10/12/06, Gary McGraw <[EMAIL PROTECTED]> wrote: > Hi all, > > I spoke to Dennis Fisher about the Google code searching stuff that's > been floating around on the list for a few weeks (since the original > Bugle posting). Here's the resulting article: > > http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1 > 222898,00.html > > BTW, I wrote about this idea in my own article on darkreading back in > August: > > http://www.darkreading.com/document.asp?doc_id=100643 > > What do you guys think about the capability? Is it good or is it bad? > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > book www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Google code search: good or bad?
good or bad, it's quite old. www.koders.com has been doing it for years. considering the source is available for anyone to download anyway, and investigate themselves, i don't see the big deal. the engines just let you search a whole bunch at once, and why would any one company/product care about that? if you want to target them, you do. if you just want to find a bug in any given open source product, then one of these may be slightly useful. if the main concern is that code can accidently get online, well that problem has been around forever and will never go away. better to expose it and have it dealt with, really. all in all, no big deal. jmho. -- mic On 10/12/06, Gary McGraw <[EMAIL PROTECTED]> wrote: > Hi all, > > I spoke to Dennis Fisher about the Google code searching stuff that's > been floating around on the list for a few weeks (since the original > Bugle posting). Here's the resulting article: > > http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1 > 222898,00.html > > BTW, I wrote about this idea in my own article on darkreading back in > August: > > http://www.darkreading.com/document.asp?doc_id=100643 > > What do you guys think about the capability? Is it good or is it bad? > > gem > > company www.cigital.com > podcast www.cigital.com/silverbullet > 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] Google code search: good or bad?
Hi all, I spoke to Dennis Fisher about the Google code searching stuff that's been floating around on the list for a few weeks (since the original Bugle posting). Here's the resulting article: http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1 222898,00.html BTW, I wrote about this idea in my own article on darkreading back in August: http://www.darkreading.com/document.asp?doc_id=100643 What do you guys think about the capability? Is it good or is it bad? gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] A banner year for software bugs | Tech News on ZDNet
... the patch process is not the answer And neither is adding new features when the old ones don't work. It's time to major on the majors, and quit messing with the minors. Give us features that work (do what they should do, and don't do what they should not do) - not just more features. Who cares if your icons have round or square corners - if someone else can take over your machine? Mike Hines [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk Sent: Wednesday, October 11, 2006 10:38 AM To: Secure Coding Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet So here's a lovely statistic for the software community to hang its hat on: http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed Among other things, the article says, "Atlanta-based ISS, which is being acquired by IBM, predicts there will be a 41 percent increase in confirmed security faults in software compared with 2005. That year, in its own turn, saw a 37 percent rise over 2004." Of course, the real losers in this are the software users, who have to deal with the never ending onslaught of bugs and patches from their vendors. We've just _got_ to do better, IMHO, and automating the patch process is not the answer. Cheers, Ken - Kenneth R. van Wyk 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
Re: [SC-L] A banner year for software bugs | Tech News on ZDNet
It's probably worth mentioning that the statistics are for OTS software. What keeps me awake at night (other than the usual trivialities) is the volume and severity of flaws/bugs in software that companies have developed or customized in-house/internally. It gets more complicated when these apps are public-facing. Yikes. /cm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Van Wyk Sent: Wednesday, October 11, 2006 7:38 AM To: Secure Coding Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet So here's a lovely statistic for the software community to hang its hat on: http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed Among other things, the article says, "Atlanta-based ISS, which is being acquired by IBM, predicts there will be a 41 percent increase in confirmed security faults in software compared with 2005. That year, in its own turn, saw a 37 percent rise over 2004." Of course, the real losers in this are the software users, who have to deal with the never ending onslaught of bugs and patches from their vendors. We've just _got_ to do better, IMHO, and automating the patch process is not the answer. Cheers, Ken - Kenneth R. van Wyk 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] A banner year for software bugs | Tech News on ZDNet
So here's a lovely statistic for the software community to hang its hat on: http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed Among other things, the article says, "Atlanta-based ISS, which is being acquired by IBM, predicts there will be a 41 percent increase in confirmed security faults in software compared with 2005. That year, in its own turn, saw a 37 percent rise over 2004." Of course, the real losers in this are the software users, who have to deal with the never ending onslaught of bugs and patches from their vendors. We've just _got_ to do better, IMHO, and automating the patch process is not the answer. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com PGP.sig Description: This is a digitally signed message part ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
