RE: [SC-L] ACM Queue article and security education
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Blue Boar Sent: 01 July 2004 21:03 To: ljknews Cc: [EMAIL PROTECTED] Subject: Re: [SC-L] ACM Queue article and security education ljknews wrote: I think it will be properly considered when the most strict portion of the software world is using language X. I have used many programs where the flaws in the program make it clear that I care not one whit about whether the authors of that program have opinion about anything I might use. They are simply not competent, either as individuals or else as an organization. By most strict portion, do you mean people that care most about correct code, proofs, and such? I don't deny that the bulk of the heavy lifting will be done by people well-qualified to do so. However, I'm of the school of thought that certain types of people who like to break things, and whose chief skill is breaking things, will always have a decent shot at finding a problem. There are people who couldn't build it, but they can sure break it. You don't typically get their attention until something is really, really popular. So yes, you can write your stuff in Language X, and assume it's secure. It might not actually be until the whole world has had its way with Language X, but (hopefully) that's not a problem. You can still do the dance of patching the last 5 problems in Language X, and end up better off that if you'd just used C. Even Knuth has to write checks ocassionally, and he does a lot of proof work, doesn't he? So, if Language X only has 5 problems total, even if it takes years to ferret them out, butthey are fixable, please proceed with getting the whole world to use Language X. I'm not entirely sure I follow this. I _think_ you are saying: since we can't be sure that X is perfect (because it might have 5 remaining flaws) then there is no point in adopting it. You seem to be saying that it doesn't matter if X is _demonstrably_much_better_ than Y, if it is not perfect then don't change. Have I got that right? This is a variant on the Goedel gambit often used to attack formal verification. It goes since Goedel's Theorem places strict limits on what we can formalize and prove, let's not bother at all and just do a few unit tests instead. It also reminds me of what I call the asprin analogy: aspirin doesn't cure cancer so there's no point in taking it for headaches. The reality is that demonstrable improvements in quality, safety and security can be achieved by using the right tools, languages and methods. It is for those who choose _not_ to use the strongest engineering to justify their position not the other way round. Peter ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. The IT Department at Praxis Critical Systems can be contacted at [EMAIL PROTECTED] This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
RE: [SC-L] ACM Queue article and security education
-Original Message- From: Blue Boar [mailto:[EMAIL PROTECTED] Sent: 01 July 2004 17:11 To: Peter Amey Cc: [EMAIL PROTECTED] Subject: Re: [SC-L] ACM Queue article and security education Peter Amey wrote: There are languages which are more suitable for the construction of high-integrity systems and have been for years. We could have adopted Modula-2 back in the 1980s, people could take the blinkers of prejudice off and look properly at Ada. Yet we continue to use C-derived languages with known weaknesses. So we trade the known problems for a set of unknown ones? [snip] A mindset that would have kept us building aircraft in wood! In any case, we _do_ adopt new languages and methods, frequently. In the time I have been using SPARK I have had people say: that's neat, if only you could do it for X. Where X has been C, C++, Java and C# in that order and at about 5 year intervals. What we _don't_ do is make those choices based on any kind of objective assessment or engineering judgement. [snip] Language X may very well be a much better starting point, I don't know. I do believe that it will never be properly looked at until the whole world starts using it for everything, though. And how will the whole world start using it if everyone waits for everyone else? In any case, I don't expect the whole world to adopt any one method (any more than I build bicycles in carbon fibre even though that is the material of choice for, say, racing cars). What I do expect is that principled engineers, the kind of people who care enough about their profession to contribute to groups like this, will seek to use the best and most appropriate technology for their purposes. Peter ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. The IT Department at Praxis Critical Systems can be contacted at [EMAIL PROTECTED] This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
Re: [SC-L] ACM Queue article and security education
At 1:02 PM -0700 7/1/04, Blue Boar wrote: ljknews wrote: I think it will be properly considered when the most strict portion of the software world is using language X. I have used many programs where the flaws in the program make it clear that I care not one whit about whether the authors of that program have opinion about anything I might use. They are simply not competent, either as individuals or else as an organization. By most strict portion, do you mean people that care most about correct code, proofs, and such? And organizations that hire the people you describe below to test the software they build. I don't deny that the bulk of the heavy lifting will be done by people well-qualified to do so. However, I'm of the school of thought that certain types of people who like to break things, and whose chief skill is breaking things, will always have a decent shot at finding a problem. There are people who couldn't build it, but they can sure break it. You don't typically get their attention until something is really, really popular. Lots of people bring their attention to issues they are paid to test. -- Larry Kilgallen
[SC-L] Education and security -- another perspective (was ACM Queue - Content)
Kenneth R. van Wyk wrote... FYI, there's an ACM Queue issue out that focuses on security -- see http://acmqueue.com/modules.php?name=Contentpa=list_pages_issuesissue_id=14 Two articles there that should be of interest to SC-L readers include Marcus Ranum's Security: The root of the problem -- Why is it we can't seem to produce secure, high quality code? ...snip... I've been thinking alot about some of the statements that Marcus Ranum made in his most recent article in the _ACM Queue_ (Vol 2, No 4)... even before Ken invited us all to comment on it. I mostly agree with Ranum's conclusions, although perhaps for different reasons. Ranum states: It's clear to me that we're: + Trying to teach programmers how to write more secure code + Failing miserably at the task He goes on to say that it [educational approach] flat out hasn't worked. In general, I don't think this is an issue that is unique to _secure_ programming (coding, design, etc.). I think over the past 40 years or so, as a discipline, we've failed rather miserably at teaching programming, period. For the past 25 years, I've worked closely with both highly educated Ph.D. computer scientists and with those whose formal CS education consisted of at most a course or two in something like C or Pascal. In many of these cases, the less educated are beating out those who have had more formal education. (In fact, I'd say this has been true in at least as many as 50% of the cases.) What makes the difference? Well, it goes beyond mere aptitude and general intelligence. I think in part at least, it goes with having a passion for what you do. To some, doing design and coding and other creative aspects is an artistic expression, a noble cause and they would do it even if there weren't paid for its--witness the open source movement which is largely funded by volunteer labor. Others see it as a job or a career path, but not much more. In my 25 year observation, those with this PASSION almost always get it, and those without it are usually left behind after the first few years into the profession. I think that the same can be said for secure coding / design. Not only do those people have a passion for coding / design, but the ones who seem to get it are the ones who have a passion for security as well. Okay, so probably no surprise here, right? Do what you enjoy and you'll excel at it more often than ones who do it out of other motives (no matter how noble--such as making an affordable living to provide for your family). So I agree with Ranum in a sense--that educational approaches to security have overall failed, but I think it is not because the educational process / system per se has failed us (not that I'm arguing that it couldn't be improved), but because we haven't been able to ignite the passion for security in others. (And frankly, I'm not even to what degree that's possible. I'll leave that to another discussion.) In the past two years, I've had the fortune to teach a computer security course that I had the major part in organizing / developing. I have learned two things about the students during that time: 1) All the students do well when it comes to rote memorization. (E.g., questions such as What cipher mode doesn't require an Initialization Vector?, etc.) 2) Only the students that seem to get it seem to do well on the questions requiring thought (i.e., ones requiring reasoning outside the box). Surprisingly (at least at first), I have often been discovered that those who other faculty members often consider the brightest students are ones who do the worst on the questions requiring thought. But in general, by the end of the 12 week period, I usually can tell who is going to take and try to apply what they learned and those who just chalk up the course as another 3 credit hours. I see what I think is a related phenomena in the commercial world as well. I've worked with a lot of developers who have worked on security-related software (e.g., firewalls, crypto, secure proxies, authentication and access control systems, etc.). One would EXPECT that the groups that work on these projects would as a whole do better at developing secure programs than the IT industry as a whole. But overall, I don't think that their batting average is all that much higher than the industry at large. We often hear excuses for this (security software is more complex, etc.), but I'm not buying it. If anything, it's this observation more than anything else that makes me think that formal education is not THE answer (although, I do think it is part of the answer). On a related note to security and education, I was wondering if anyone knows of any experimental data that shows that those with formal education in security develop more secure programs than those who have never had such formal training? If no such experimental data exists, why not? Can no one think of some formal,
Re: [SC-L] ACM Queue article and security education
Peter Amey wrote: I'm not entirely sure I follow this. I _think_ you are saying: since we can't be sure that X is perfect (because it might have 5 remaining flaws) then there is no point in adopting it. You seem to be saying that it doesn't matter if X is _demonstrably_much_better_ than Y, if it is not perfect then don't change. Have I got that right? No. I was claiming that languages that allow for safety and verifiction can't neccessarily be trusted 100%. There will always be a last few bugs. As I said in my note that you replied to, that doesn't neccessarily mean you don't use it. The other part of my note had to do with the last few bugs not coming to light until *everyone* is using that language. Also not a reason to not go ahead and use it now, since the sooner the world starts to switch, the sooner you kill the last few bugs. I think you were reacting to the one sarcastic part of my note, which essentially says good luck getting the world to switch. BB
[SC-L] Best practices training
Hi all, Some of you may be interested in a Tutorial on software security best practices that I will be giving at Usenix security this year. More information can be found here: http://www.usenix.org/events/sec04/training/ See you in San Diego in August. gem This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You.
[SC-L] Risk Analysis: Building Security In #3
Hi all, The third article in my IEEE Security Privacy magazine series called Building Security In is on Risk Analysis in Software Design. This article was co-authored by Denis Verdon of Fidelity National. As a service to the community, we're making advance copies available here: http://www.cigital.com/papers/download/risk-analysis.pdf I am sure many of you already subscribe to SP. If you don't yet, you should...check out http://www.computer.org/security/. gem This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You.
