Re: [SC-L] Protecting users from their own actions
Wall, Kevin wrote: Isn't this something that users probably shouldn't be given a choice on? Normally I would think that corporate security policy dictate keeping the AV software / signatures up-to-date as well as dictating the (personal) firewall configurations. Some centrally administered software should do these things... I agree that central administration works best in today's corporate environments, but I was referring also to the more general desktop environments as well, right down to the home and SOHO users that have to install and/or update their own. Aside from that issue, though, the primary point that I wanted to get across is that there are substantial limitations to what we can accomplish through user education. I believe that our software -- from enterprise app servers through desktop emailers and browsers -- needs to do better at protecting users, even when they make decisions that we would think to be unwise. Cheers, Ken van Wyk
Re: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
Dana Epp wrote: I'd be interested to hear what people think of the two approaches (separate security courses vs. spreading security all over the curricula). >> >> Regards. >> >> Fernando. I don't think it's an either/or question; we need both approaches. Students should study security wherever it's relevant in the curriculum, but they also need a security class towards the end of the degree program to integrate what they've learned with a deeper and more theoretical look at security at the level of Matt Bishop's Computer Security: Art and Science. Well, I have been asked to teach a new forth year course at the British Columbia Institute of Technology (BCIT) this fall on Secure Programming (COMP4476). It looks like a good class, Dana. My only suggestion would be to present secure design principles in unit 2, instead of waiting to bring them up until unit 7 (I'm presuming you'll bring up more than least privilege there.) I think you're right to wait until later in the term to bring up buffer overflows; it's a more difficult problem for students than I expected it to be the first time I gave such an assignment. I only wish I could make all these books be textbook requirements for the curriculum. It should be mandatory reading. I think they're all good books, but covering fewer topics and books in greater depth increases learning, so don't succumb to that temptation. You can't teach them everything in one term, but you can point the way to continue learning with those books for students who want to know about security than one class can teach them. Of course, I also think students should have to take at least one course in ASM to really understand how computer instructions work, so they can gain a foundation of learning for the heart of computer processing. And I think they should be taught the powers and failures of C. Since I know many of you think I'm nuts for that, you might want to look at this outline with the same amount of consideration. I agree with you on both of those requirements. You need to have a basic understanding of assembly and how C is translated into assembly to understand the most common types of buffer overflow attacks. There are better languages for secure programming than C, but students are almost certainly going to have to read or write C at some point in their careers, so they need to understand it. -- James Walden, Ph.D. Visiting Assistant Professor of EECS The University of Toledo @ LCCC http://www.eecs.utoledo.edu/~jwalden/
Re: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
Crispin Cowan wrote: Another perspective (overheard at a conference 12 years ago): * Scientists build stuff in order to learn stuff. * Engineers learn stuff in order to build stuff. I think that's about as accurate a summary of the distinction as you can make in 16 words. What makes it even more fuzzy in our case is that computer science does not fit in any one category, as it's a conglomerate of maths, science, and engineering. That may be why some universities are moving from departments of computer or information science to schools of computer or information science. ... however, the programming skills that universities teach is usually a side-effect of something else they are teaching: topics like algorithms, graphics, database, operating systems, networking, etc. They teach you the topic, give you a development project in that topic, and expect you to pick up the programming skills along the way. What is broken about all this is security: the above approach teaches the kiddies to implement software anyway they can, under a lot of time pressure, and with very little QA pressure: graders have no time to rigorously test assignment hand-ins, and certainly not time to pen-test them. I agree that programming being taught as an afterthought is one of the major sources of the problem with security, and it's related to computer science being a conglomerate of disciplines. CS today feels like we're studying natural philosophy in the days before biology, chemistry, and physics became their own disciplines. It worked when computer science was a younger field, but there's so much to study today that we can't fit all of it into a four year curriculum. There are only a few solutions to adding security to the curriculum in this sutation: 1) remove other material to add security in its place, 2) expand the number of required classes and thus time for a degree, or 3) specialize CS into multiple disciplines, at least one of which has room for security in its curriculum. I think the third choice is the likely and best long term solution, and the first is the most workable short term solution. -- James Walden, Ph.D. Visiting Assistant Professor of EECS The University of Toledo @ LCCC http://www.eecs.utoledo.edu/~jwalden/
Re: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
At 9:40 AM -0400 7/7/04, James Walden wrote: >Dana Epp wrote: >> Of course, I also think students should have to take at least one course in ASM to >> really understand how computer instructions work, so they can gain a foundation of >> learning for the heart of computer processing. And >> I think they should be taught the powers and failures of C. Since I know many of >> you think I'm nuts for that, you might want to look at this outline with the same >> amount of consideration. > >I agree with you on both of those requirements. You need to have a basic >understanding of assembly and how C is translated into assembly to understand the >most common types of buffer overflow attacks. There are better languages for secure >programming than C, but students are almost certainly going to have to read or write >C at some point in their careers, so they need to understand it. What is wrong with this picture ? I see both of you willing to mandate the teaching of C and yet not mandate the teaching of any of Ada, Pascal, PL/I etc. This seems like the teaching of "making do". -- Larry Kilgallen
RE: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
Fernando Schapachnik wrote... > I've considered 'secure coding' courses, and the idea always > look kind oversized. How much can you teach that students can't read > themselves from a book? Can you fill a semester with that? I'm > interested in people's experiences here. I suppose that depends largely on how you define "secure coding" and how much depth you want to go into. For the past 2 years I've taught a CS masters level course in computer security. In addition to "secure coding" practices, I also discuss: * fundamental concepts of security (e.g., authentication, authorization, confidentiality, data integrity, nonrepudiation, etc.); * risk management and threat models; * cryptographic foundations; * authentication, access control, and auditing; * common threats and vulnerabilities, and * designing secure systems. For the most part, because of time constraints and the fact that we are trying to cover broader things then simply coding-related issues, the "secure coding" practices are interspersed with the other topics, where and when appropriate. (If you want more detail, you can find the syllabus at http://cs.franklin.edu/Syllabus/comp676/.) > Adding a 'security chapter' to existing courses seems more > appropiate (at least to me). At the end of our Programming II > course, I showcase students the vulnerabilities that can be > understood or are related with what they've saw in > class: these includes buffer overflows, input validation, integer > over/underflows, race conditions, least priviledge, etc. I > stress that these are only samples, and point them to links > (like David's great 'Secure Programming How-To') and books. > I haven't had the chance to evaluate the impact of that, but > it is on my to-do list. I think that is a good approach, although I prefer mixing these issues in where/when they might be more appropriate (e.g., discuss security issues arising from race conditions when discussing multi-threading, etc.) rather then saving them up for the end--if only because there's a chance that they get crowded out if the pace goes slower than expected. > Similary, some other courses where security can be plugged > include operating systems, networking, SE, system's design, etc. Indeed. At the same university, I taught the Distributed Operating Systems masters level course. We used the Tannebaum / van Steen text. The longest single chapter in the book was on security, so the topic naturally fit in. (However, I know of other instructors before me who simply skipped that chapter, thinking it wasn't as important as the rest of the stuff.) > I'd be interested to hear what people think of the two > approaches (separate security courses vs. spreading security > all over the curricula). I don't see it as "either / or", but rather "both / and". I think that we sprinkle discussion of security, where appropriate, throughout core courses (OS, networking, software design, etc.) and also have a course or two at an upper (junior/senior) level. In that way, I see it very similar to the way that we approach software design. Generally there's a specific course or two on design, but we (hopefully) teach it in bits and pieces at the beginning programming levels as well. --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 "The difference between common-sense and paranoia is that common-sense is thinking everyone is out to get you. That's normal -- they are. Paranoia is thinking that they're conspiring."-- J. Kegler
