Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Goertzel, Karen [USA]goertzel_ka...@bah.com wrote: If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. A much-too-late entry for the bumper sticker contest we had here a few years back: Works as you wish, under all condish. (Okay, okay, so maybe that kind of abbreviating is a bit out of style... by 70 years or so) -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume other info. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Karen Goertzel wrote... I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. Except, unfortunately, as an industry / profession, we can't even get the far-simpler (IMO) _functional correctness_ right let alone (so-called) non-functional issues such as security, safety, fault tolerance, etc. (Mathematical rigor and proof-of-correctness aside, but in many [most?] cases that's not practical and even if it were, most programmers' brains turn to mathematical mush whenever they see any kind of correctness proof. Meaning that it ain't going to happen if it requires thinking. ;-) In some regard, I think this holds things back. If we don't do a good job testing that the software does all that it's supposed to do under *ideal* conditions, how are we ever to expect developers and testers to test to make sure that the software doesn't do additional things that it's NOT supposed to do under less than ideal conditions. There's a reason why Ross Anderson and Roger Needham talked about Programming Satan's Computer (see http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf). [Yes, I 'm aware that paper was about the correctness of distributed cryptographic protocols, but I think both Anderson and Needham would agree that the term Programming Satan's Computer applies more generally than just to that narrow aspect of security.] Not that I'm advocating of giving up, mind you. If the battle seems hopeless, perhaps we would see more progress if we were to address secure programming issues simply as a related aspect of program correctness. Why? Because the development community seems to be more willing to address those things. (Obviously, part of that is that many programming flaws are rather tangible and something that casual users can experience. Yeah! That's the ticket. Let's teach the general populace how to hack into systems! Pass out free You've been pwnd! T-shirts with every successful pwnage. Now *THAT* would be devious. ;-) -kevin --- Kevin W. Wall Qwest Information Technology, Inc. kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)
Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. I couldn't agree more! However, I have had several discussions with a colleague who is fairly well known in theSoftware Process Improvement Mafia on the topic of how to ensure that security requirements are considered for _all_ kinds of code, not just security software. Particularily in the context of agile development techniques, security keeps getting the short end of the stick, losing every time to working features. His stance on this is that if security were important to the customer, the customer would provide and prioritize security requirements. To me, this is a bit like saying If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it. If we can brainwash the coming generations of programmers into accepting Karen's definition of quality code, we might finally be getting somewhere. -Martin ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Here's an extract from the Information Assurance Technology Analysis Center (part of DTIC) Software Security Assurance: A State of the Art Report (http://iac.dtic.mil/iatac/download/security.pdf): Courses on secure software development, secure programming, etc., typically begin by introducing common attacks against software-intensive information systems and the vulnerabilities targeted by those attacks, then progress to modeling, design, coding, and testing practices that software developers can adopt to reduce the likelihood that exploitable vulnerabilities will appear in the software they produce. The following is a representative sampling of such courses: - Arizona State University: Software Security - Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems - Carnegie Mellon University (CMU) and University of Ontario (Canada): Secure Software Systems - George Mason University: Secure Software Design and Programming - George Washington University: Security and Programming Languages - Catholic University of Leuven (Belgium): Development of Secure Software - New Mexico Tech: Secure Software Construction - North Dakota State University: Engineering Secure Software - Northeastern University: Engineering Secure Software Systems - Northern Kentucky University, Rochester Institute of Technology, and University of Denver: Secure Software Engineering - Polytechnic University: Application Security - Purdue University: Secure Programming - Queen’s University (Kingston, ON, Canada): Software Reliability and Security - Santa Clara University: Secure Coding in C and C++ - University of California at Berkeley, Walden University (online): Secure Software Development - University of California at Santa Cruz: Software Security Testing - University of Canterbury (New Zealand): Secure Software - University of Nice Sophia-Antipolis (Nice, France): Formal Methods and Secure Software - University of Oxford (UK): Design for Security - University of South Carolina: Building Secure Software. As noted earlier, other schools offer lectures on secure coding and other software security relevant topics within their larger software engineering or computer security course offerings. At least two universities - the University of Texas at San Antonio and University of Dublin (Ireland) - have established reading groups focusing on software security. As part of its Trustworthy Computing initiative, Microsoft Research has established its Trustworthy Computing Curriculum program [309] for promoting university development of software security curricula. Interested institutions submit proposals to Microsoft, and those that are selected are provided seed funding for course development. Another recent trend is post-graduate degree programs with specialties or concentrations in secure software engineering (or security engineering for software-intensive systems). Some of these are standard degree programs, while others are specifically designed for the continuing education of working professionals. The following are typical examples: - James Madison University: Master of Science in Computer Science with a Concentration in Secure Software Engineering - Northern Kentucky University: Graduate Certificate in Secure Software Engineering - Stanford University: Online Computer Security Certificate in Designing Secure Software From the Ground Up - University of Colorado at Colorado Springs: Graduate Certificate in Secure Software Systems - Walden University (online): Master of Science in Software Engineering with a Specialization in Secure Computing - University of Central England at Birmingham: Master of Science in Software Development and Security - Chalmers University (Gothenburg, Sweden): Master of Science in Secure and Dependable Computer Systems. In another interesting trend (to date, exclusively in non-US schools), entire academic departments - and in one case a whole graduate school—are being devoted to teaching and research in software dependability, including security, e.g.: - University of Oldenburg (Germany) TrustSoft Graduate School of Trustworthy Software Systems - Fraunhofer Institute for Experimental Software Engineering (IESE) (Kaiserslautern, Germany): Department of Security and Safety - Bond University (Queensland, Australia): Centre for Software Assurance. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw [...@cigital.com] Sent: Thursday, August 20, 2009 2:55 PM To: Neil Matatall; Secure Code Mailing List Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of Software Security http://swsec.com. Remember, this list was created in 2006, and lots of other universities have jumped on the bandwagon since
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Everyone, Thank you for all of the input. Really. This information has been extremely helpful! Neil Goertzel, Karen [USA] wrote: Here's an extract from the Information Assurance Technology Analysis Center (part of DTIC) Software Security Assurance: A State of the Art Report (http://iac.dtic.mil/iatac/download/security.pdf): Courses on secure software development, secure programming, etc., typically begin by introducing common attacks against software-intensive information systems and the vulnerabilities targeted by those attacks, then progress to modeling, design, coding, and testing practices that software developers can adopt to reduce the likelihood that exploitable vulnerabilities will appear in the software they produce. The following is a representative sampling of such courses: - Arizona State University: Software Security - Ben-Gurion University (Beer-Sheva, Israel): Security of Software Systems - Carnegie Mellon University (CMU) and University of Ontario (Canada): Secure Software Systems - George Mason University: Secure Software Design and Programming - George Washington University: Security and Programming Languages - Catholic University of Leuven (Belgium): Development of Secure Software - New Mexico Tech: Secure Software Construction - North Dakota State University: Engineering Secure Software - Northeastern University: Engineering Secure Software Systems - Northern Kentucky University, Rochester Institute of Technology, and University of Denver: Secure Software Engineering - Polytechnic University: Application Security - Purdue University: Secure Programming - Queen’s University (Kingston, ON, Canada): Software Reliability and Security - Santa Clara University: Secure Coding in C and C++ - University of California at Berkeley, Walden University (online): Secure Software Development - University of California at Santa Cruz: Software Security Testing - University of Canterbury (New Zealand): Secure Software - University of Nice Sophia-Antipolis (Nice, France): Formal Methods and Secure Software - University of Oxford (UK): Design for Security - University of South Carolina: Building Secure Software. As noted earlier, other schools offer lectures on secure coding and other software security relevant topics within their larger software engineering or computer security course offerings. At least two universities - the University of Texas at San Antonio and University of Dublin (Ireland) - have established reading groups focusing on software security. As part of its Trustworthy Computing initiative, Microsoft Research has established its Trustworthy Computing Curriculum program [309] for promoting university development of software security curricula. Interested institutions submit proposals to Microsoft, and those that are selected are provided seed funding for course development. Another recent trend is post-graduate degree programs with specialties or concentrations in secure software engineering (or security engineering for software-intensive systems). Some of these are standard degree programs, while others are specifically designed for the continuing education of working professionals. The following are typical examples: - James Madison University: Master of Science in Computer Science with a Concentration in Secure Software Engineering - Northern Kentucky University: Graduate Certificate in Secure Software Engineering - Stanford University: Online Computer Security Certificate in Designing Secure Software From the Ground Up - University of Colorado at Colorado Springs: Graduate Certificate in Secure Software Systems - Walden University (online): Master of Science in Software Engineering with a Specialization in Secure Computing - University of Central England at Birmingham: Master of Science in Software Development and Security - Chalmers University (Gothenburg, Sweden): Master of Science in Secure and Dependable Computer Systems. In another interesting trend (to date, exclusively in non-US schools), entire academic departments - and in one case a whole graduate school—are being devoted to teaching and research in software dependability, including security, e.g.: - University of Oldenburg (Germany) TrustSoft Graduate School of Trustworthy Software Systems - Fraunhofer Institute for Experimental Software Engineering (IESE) (Kaiserslautern, Germany): Department of Security and Safety - Bond University (Queensland, Australia): Centre for Software Assurance. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw [...@cigital.com] Sent: Thursday, August 20, 2009 2:55 PM To: Neil Matatall; Secure Code Mailing List Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? hi neil, For what it's worth, there is a list of universities with some kind of software security curriculum on page 98 of Software
Re: [SC-L] embedded systems security analysis
A colleague and I have been looking at the problem a bit, in the context of need for survivability in safety-critical systems. Below is an extract of the paper Software Survivability: Where Safety and Security Converge authored by Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore Winograd at the American Institute of Aeronautics and Astronautics' infot...@aerospace Conference in Seattle last spring. There's also a brief discussion of security issues associated with embedded software in the DHS/DACS Enhancing the Development Life Cycle to Produce Secure Software - specifically pages 272-275. The document is freely downloadable after quick registration on the DACS (DTIC's Data and Analysis Center for Software) Web site: https://www.dacs.dtic.mil/techs/enhanced_life_cycles/ Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com -- B. Embedded No Longer Means Isolated Before discounting a comparable threat to embedded systems, consider the following excerpt from Chapter seven of Exploiting Software [8] by Greg Hoglund and Gary McGraw: For no valid technical reasons, people seem to believe that embedded systems are invulnerable to remote software-based attacks. One common misconception runs that because a device does not include an interactive shell out of the box, then accessing or using ‘shell code’ is not possible. This is probably why some people (wrongly) explain that the worst thing that an attacker can do to most embedded systems is merely to crash the device. The problem with this line of reasoning is that injected code is, in fact, capable of executing any set of instructions, including an entire shell program that encompasses and packages up for convenient use standard, supporting [operating system]-level functions. It does not matter that such code does not ship with the device. Clearly, this kind of code can simply be placed into the target during an attack. Just for the record, an attack of this sort may not need to insert a complete interactive TCP/IP shell. Instead, the attack might simply wipe out a configuration file or alter a password. There are any numbers of complex programs that can be inserted via a remote attack on an embedded system. Shell code is only one of them. Even the most esoteric of equipment can be reverse engineered, debugged, and played with. It does not really matter what processor or addressing scheme is being used, because all an attacker needs to do is to craft operational code for the target hardware. Common embedded hardware is (for the most part) well documented, and such documents are widely available. One of the most widely publicized successful attacks on an embedded system was the 2002 hack of the flash memory of the Microsoft XBox game cube in order to access the algorithm used by the game cube’s cryptosystem to decrypt and verify its bootloader. [9] Now consider how safety-critical embedded systems—from temperature controls to medical devices to on-board airplane and automotive computers and sensors—are increasingly becoming network-accessible. For example, embedded software in implanted medical devices is now accessible via radio frequency identification (RFID) interfaces. [10] And telemedicine applications in use by DoD enable software-controlled surgical robots located in U.S. military facilities in Iraq to be operated via satellite uplinks by doctors at the U.S. Navy Hospital in Bethesda, Maryland. [11] Consider General Motors’ OnStar and its less familiar rivals (Ford’s RESCU and VEMS, Volvo’s OnCall, BMW’s Assist, Mercedes-Benz’s TeleAid and COMAND). These services all include the ability of call center representatives to perform remote telematic diagnostics of the onboard computers in their subscribers’ vehicles. The data they collect via transmissions from the cars’ computers are returned to the remote call centers via cellular or satellite phone links. Remote monitoring and diagnosis of automotive computers sounds benign enough (though there are significant privacy concerns associated with some of the data being gathered by these services), but OnStar has gone a step beyond simple observation to actual remote control of at least one of the automobile’s safety-critical onboard computers: the one that controls its ignition. As USA Today reported in October 2007, [12] the 1.7 million General Motors 2009 vehicles equipped with OnStar now allow their owners to grant permission for OnStar to cooperate with the police if their vehicles are stolen; specifically, if a police car is involved in a high-speed car chase with a stolen OnStar-enabled vehicle, the police can request that the stolen vehicle’s engine “be remotely switched off through the OnStar mobile communications system”. The objective of this police/OnStar cooperation is laudable: it allows the police to terminate car chases
Re: [SC-L] embedded systems security analysis
I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It might be something like the ability to insert a card in a PC slot (as in the Princeton attack on Diebold touchscreen systems), a USB stick (some of the UC Santa Barbara attacks - I think that was ESS touchscreen machines), Harri Hursti's attacks via a memory card on Diebold optical scanners, Princeton's attacks via a proprietary memory card on Sequoia systems, etc. (There are others too - the machines in my county use USB sticks and run Windows CE, so I believe they're susceptible to even trivial attacks via an autorun.) I also worked with a team that did some attacks on another embedded system in a voting machine, although we didn't get far enough to publish results before we ran out of students to do the grunt work. So I'd 1000% agree with Arian - not only is assuming you're safe dangerous, but it's also wrong. There's lots of attacks on other types of embedded systems - there have been a few against electric power control systems, water control systems, etc. And there are more that haven't seen the light of day I just heard about a very serious attack the other day that hasn't ever made it into the news. --Jeremy On Thu, Aug 20, 2009 at 2:09 PM, Arian J. Evansarian.ev...@anachronic.com wrote: Rafael -- to clarify concretely: There are quite a few researchers that attack/exploit embedded systems. Some google searches will probably provide you with names. None of the folks I know of that actively work on exploiting embedded systems are on this listbut I figure if I know a handful of them in my small circle of software security folks - there have to be many more out there. Assuming you are safe is not just a dangerous assumption: but wrong. Specifically - One researcher I know pulls boards system components apart and finds out who the source IC and component makers are. Then they contact the component and IC makers and pretends to be the board or system vendor who purchased the components, and asks for documentation, debuggers, magic access codes hidden in firmware (if he cannot reverse them). If this fails, the researcher has also befriended people at companies who do work with the IC or board maker, traded them information, in exchange for debuggers and the like. This particular researcher does not publish any of their research in this area. They do it mainly (I think) to help build better tools and as a hobby. (Several of you on this list probably know exactly whom I'm talking about. This person would prefer privacy, and I think the person's employer demands it, unless you get him in person and feed him enough beer.) If I were a bettin' man I'd figure if I know a few person doing this type of thing for quite a few years now -- there are bound to be many, many more Not sure what list to go to for talks on that type of thing. Blackhat.com has some older presentations on this subject. -- Arian Evans On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at -
Re: [SC-L] embedded systems security analysis
Thank you for all the info you guys have sent, it has been very informative... :) It is harder to steal the source (you need more electronical knowledge and expensive debuggers and stuff) but it is possible... Do you guys know some pages with security tips for embedded systems? ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Neil Matatall wrote: So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Secure coding needs to be taught anytime programing is taught. From my experience in my son's boy scout troop, I'm not sure I'd call it out as security and confuse middle school/junior high school students but I'd teach them basics like input validation and bounds checking as basic good programing. The security aspects can wait until later when they can better handle several concepts at once. After that is just needs to be part of the course and called out for what it is. There is room for stand alone security focused training and courses but it needs to be drilled in all along the way. I recall my own computer science instructors telling us *not* to spend time on bells and whistles and concentrate on the concept the lesson was covering. If the lesson was on pointers, adding things like error checking and user friendly features didn't count for anything. I can understand why that was said but it sends the wrong message and begins the development of bad habits. That was 20 to 30 years ago and most computer users' idea of security was locking their car doors but it did set us up for bad habits. Basics need to be drilled in early and always count for something even if the lesson is while loops. -- Mike Lyman mly...@west-point.org ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] embedded systems security analysis
We looked at the problem of voting system security specifically in the context of insider threat for last year's IATAC State of the Art Report on the Insider Threat to Information Systems - some of which involved rogue developers engineering backdoors into such systems. Unfortunately the document is limited distribution and FOUO, so I can't excerpt here. But if you're interested and a government employee or contractor, let me know and I'll get you instructions on how to register with DTIC to obtain a copy. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jeremy Epstein [jeremy.j.epst...@gmail.com] Sent: Thursday, August 20, 2009 5:39 PM To: Arian J. Evans Cc: Secure Coding List Subject: Re: [SC-L] embedded systems security analysis I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It... ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
I think we need to start indoctrinating kids in the womb. Start selling Baby Schneier CDs alongside Baby Mozart. :) Seriously, though, cyberspace is such an integral part of modern life, parents need to inculcate online security into their toddlers the same way they teach them to look both ways before crossing the street, and not to talk to or get into the car with strangers. In essence, we need to teach kids the virtual equivalents of these safe behaviours when they go online - which some of them are doing as early as age 4! If they can be brainwashed that early, they will come to have higher expectations of what SHOULD be present with regard to security properties in software-based systems. Then the notion won't seem alien to them. What will seem alien TO US is that they won't understand the struggles we've had to get people to start adding security. The idea of security having ever NOT been there will be bizarre to them. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Mike Lyman [mlyman-ci...@comcast.net] Sent: Friday, August 21, 2009 8:17 AM To: Secure Coding Subject: Re: [SC-L] Where Does Secure Coding Belong In the Curriculum? Neil Matatall wrote: So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Secure coding needs to be taught anytime programming is taught ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)
Actually CJC, it's often even worse than that. In many cases, the customer or consumer has an implicit requirement for security that remains unstated. Only when the system fails and is successfully attacked does that requirement shift from implicit to explicit. You mean it wasn't secure?? You've got to be kidding... In some sense that's what happened to Microsoft way back in the virus-bag days. History shows that it is best to anticipate implicit requirements and address them as possible. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 8/21/09 8:40 AM, Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com wrote: Martin Gilje Jaatun wrote: Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. If determination of functional correctness were extended from must operate as specified under expected conditions to must operate as specified under all conditions, functional correctness would necessarily require security, safety, fault tolerance, and all those other good things that make software dependable instead of just correct. I couldn't agree more! However, I have had several discussions with a colleague who is fairly well known in theSoftware Process Improvement Mafia on the topic of how to ensure that security requirements are considered for _all_ kinds of code, not just security software. Particularily in the context of agile development techniques, security keeps getting the short end of the stick, losing every time to working features. His stance on this is that if security were important to the customer, the customer would provide and prioritize security requirements. To me, this is a bit like saying If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it. The problem (certainly as I see it) is that the customer is likely to say Make it secure without really understanding what that means. Secure against what exactly? Or you'll get a list of security features that the customer wants, but as we all know security features != secure product. Instead we've taken a combined approach of including customer requirements and adding specific requirements of our own focusing a good Secure development practices. If we can brainwash the coming generations of programmers into accepting Karen's definition of quality code, we might finally be getting somewhere. And that's the trick we've been attempting here. Secure software is nothing more than really good quality code. We already use coding guidelines and have a strong(ish) process of code reviews. So we have augmented our coding and review guidelines to include secure coding aspect such as input/output validation, good memory management etc. That said there is still a lot of scope for improvement in the rest of the software development process (testing and design in particular). CJC ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
On Wed, Aug 19, 2009 at 2:15 PM, Neil Matatallnmata...@uci.edu wrote: Inspired by the What is the size of this list? discussion, I decided I won't be a lurker :) A question prompted by http://michael-coates.blogspot.com/2009/04/universities-web-app-security.html and the OWASP podcast mentions So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Does it help at all to consider how and where most people actually learn to program/develop? I don't have percentages handy of how many people with a job title or informal role as programmer or developer actually took any formal education in this. If we're just trying to reach the group of developers that went through formal training then we've seen some pretty good answers here in this thread already. If we want to cover others though, we need to look elsewhere. Let's look at another few fields where safety is important and yet the work is often done by both professionals and amateurs - Plumbing and/or Electrical Work. My own view is that much software development is actually a lot closer to the work of the amateur electrician than the professional electrician. That is, unlike fields like engineer, architect, lawyer, accountant, we don't rely on professional standards, degrees, certifications, etc. for most programmers. I'm leaving aside for a moment whether we can or should, and just pointing out that it is the case. In the case of the amateur electrician you'll find a wide variety in their knowledge of safety concerns, adherence to code, etc. They probably know enough to not electrocute themselves while they are working (though not always) but don't necessarily know enough to put in wiring that won't burn their house down in a few years. I think our real question isn't just how to reach the professional programmer trained via formal training programs, but also how to reach the amateur programmer trained via books, trial+error, etc. In these cases the best bet is to make sure that the general training manuals, how-to guides, etc. have a lot of safety/security information included in them. That the books people use to learn actually show them safe examples, etc. Obviously there are variations of code requirements per location and such, but basic safety rules will probably be mostly universal. - Andy ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
I think we need to start indoctrinating kids in the womb. Start selling Baby Schneier CDs alongside Baby Mozart. :) I can recommend this book, it was given to me by a client. Enigma: A Magical Mystery Grade 3–6—Someone has stolen the props belonging to the residents of a retirement home for magicians, and Bertie Badger, the grandson of one of the illusionists, vows to find them. As he meets the performers, they each tell him a little about their specialty and what's missing. My top hat, cape, and wand have gone, but there is worse to tell:/My precious magic bunny rabbit's disappeared as well! Bertie discovers the thief, but it is left to readers to find the lost items hidden in the illustrations. Base's visual mystery books have delighted children for years, but this one has the added feature of a moving panel in the back cover that reveals a secret code. Children must turn dials to proper settings before it can be moved. The clues for setting them appear in the illustrations but are not at all obvious. With a little persistence, however, the target audience should be able to solve the puzzle. After readers crack the code, they can search for the missing items hidden in the art and decipher other messages found in the end matter. http://www.amazon.com/Enigma-Magical-Mystery-Graeme-Base/dp/081097245X -gunnar ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Has anyone who holds to this taught a beginning level programming class? Getting students to understand what a loop is can be hard enough, given limited time. Diving into exploits and buffer overflows can be much more difficult. I am sure some things could be put into a basic class, but the ideas are a bit deeper. Security at the Hello World! or Mortgage Calculator program level seems quite difficult. This bears some thinking through, but the security risks seem to be: - Make sure the input amount is in dollars. - Make sure the term is numeric and within reasonable ranges. - Make sure that interest rate is in the form of XX.XX. Other things checked for would be - Proper output. - Pausing at the right point so the output can be viewed correctly. I am sure I am missing things, but this should serve as a base. Where do you inject security there? Sure, you can note the importance of checking the data, but just because someone checks the input here doesn't mean they will have a clue on checking the input on a web form for an SQL injection attempt. I get students who can't loop to start over, they are certainly not going to catch that they need to do deeper input inspection, especially in a completely unrelated topic. I am probably blowing some smoke here and I may disagree with myself later, but I think this discussion is worth having. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Mike Lyman mlyman-ci...@comcast.net: Neil Matatall wrote: So where does secure coding belong in the curriculum? Higher Ed? High School? Undergrad? Grad? Extension? Secure coding needs to be taught anytime programing is taught. From my experience in my son's boy scout troop, I'm not sure I'd call it out as security and confuse middle school/junior high school students but I'd teach them basics like input validation and bounds checking as basic good programing. The security aspects can wait until later when they can better handle several concepts at once. After that is just needs to be part of the course and called out for what it is. There is room for stand alone security focused training and courses but it needs to be drilled in all along the way. I recall my own computer science instructors telling us *not* to spend time on bells and whistles and concentrate on the concept the lesson was covering. If the lesson was on pointers, adding things like error checking and user friendly features didn't count for anything. I can understand why that was said but it sends the wrong message and begins the development of bad habits. That was 20 to 30 years ago and most computer users' idea of security was locking their car doors but it did set us up for bad habits. Basics need to be drilled in early and always count for something even if the lesson is while loops. -- Mike Lyman mly...@west-point.org ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Functional Correctness
I completely agree, though how are we really going to reach this point? We have been talking about this at least since I got into development in the early 1980s. We are not anywhere closer, though we have lots of neat tools that do lots of neat stuff. Unfortunately, our programs are also a lot more complicated, making the correct proof much more difficult. Can we really believe it is just around the corner to prove this? -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com: Martin Gilje Jaatun wrote: Karen, Matt all, Goertzel, Karen [USA] wrote: I'm more devious. I think what needs to happen is that we need to redefine what we mean by functionally correct or quality code. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Customer Demand
While no customer is likely to say they don't care about software working now that we are past Y2K, they don't think about it at all and are unlikely to allow any schedule slippage to allow for making sure that is true. Customers only really care about the things they will pay for. Many companies claim they can't stand poor software or services, but they still pay for them, so they will keep getting them. Until we convince them that good security really is important and that they must demand and pay for it, we won't make the progress we want to make. How many companies wouldn't even be doing the PCI level of effort if they weren't forced to do so? How many strictly limit it to their PCI environment rather than looking at the risk to the whole enterprise? Even major breaches don't help since the it can't happen here attitude is common all over, in spite of the fact it is a risky stance. While part of this is just a cynical rant, I think the base point is that we have a whole lot more selling to do on the need for software security before we can properly place it throughout the curriculum. That sales job is hard. The fact a few people have gotten it doesn't mean most have or that we are completely ready for the next step. I realize many here may not be saying that, but that is the message I get stepping back. And I am a dreamer/visionary. I like to think well ahead of things, but focusing too much there makes us likely to continue to be a niche area, leaving lots of vulnerabilities. Wouldn't a better focus be on the customer demand end? Stirring that up will do more to advance secure development than any number of maturity models. Unfortunately, it is a much more difficult task. I would bet it is also not as conceptually interesting to many. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Martin Gilje Jaatun secse-ch...@sislab.no: His stance on this is that if security were important to the customer, the customer would provide and prioritize security requirements. To me, this is a bit like saying If the customer doesn't explicitly state that the software should be Y2k-proof, he/she is not really bothered about it. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Silver Bullet: Fred Schneider
hi sc-l, The 41st epsiode of Silver Bullet just went live. This episode features a conversation with Fred Schneider, a computer sceince professor at Cornell and a very important thought leader in security research. Fred was the author of the seminal National Academies study Trust in Cyberspace. We talk about the relationship between reliability and security, about fault tolerant systems, and about diversity as a security mechanism. We also talk about writing secure code, outlawing C, and the end of the age of bugs. Fred brings up the idea of categories of attack and the evolution of attacks from configuration, through bugs, to flaws and finally to trust problems. http://www.cigital.com/silverbullet/show-041/ Fred is particularly well spoken and cogent, and it was a great privilege to chat about security with him. As always, your feedback is welcome. gem company www.cigital.com podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
