Re: [SC-L] any one a CSSLP is it worth it?
On 4/12/2010 2:03 PM, Matt Parsons wrote: > > I am a CISSP with programming experience, static code analysis and web > penetration testing. I am thinking about taking the CSSLP. I just > bought the review book. Is it worth getting this certification? Is > it going to raise my rates and help me get more contracts? Is the > GIAC better or should I pursue both or neither? I wrote about the > first concept of the CSSLP on my blog. Any feedback would be greatly > appreciated. > > http://parsonsisconsulting.blogspot.com/ > > It's supposed to be on track to become a US DoD cert in 8570. If you are in that world that will help. Meanwhile it's part of our brag sheet as we work on getting new business in the software assurance area among our DoD customers. We've got two of us on our team from early in the experience assessment phase. Not sure how much it helps sell things over and above our reputation among our customers but we keep it out there. -- 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?
Benjamin Tomhave wrote: > First, security in the software development concept is at least an > intermediate concept, if not advanced. Riffing on Brad's comments, it > seems irrational to think that you can jump straight from structural > basics with which many students struggle (OO anybody?) directly to > concepts that bridge computer architecture, code structure, and various > other problems. > Like most technical skills, there is a range of skills that play into secure software. When you are teaching hello world, you are not coving program architecture and requirements management. In a similar way you are not going to get into advanced secure software concepts when you are teaching hello world. You teach the appropriate skill levels at the appropriate time and some of these are going to be skills that play into secure programming. For students at perhaps the high school level and above, you can probably even begin to introduce them as things that impact security even if the focus is mainly on doing things right. Bad habits develop early and we need to prevent them as early as possible. Earlier I related how I had college instructors tell us not to worry about extras like error handling but to concentrate on the lesson he was trying to teach us. Clearly many of us were able to worry about error handling, we were trying to do it. We tried to do user friendly interfaces (command line at the time) and respond to incorrect input, don't bother with that, just concentrate on the lesson. The wrong lessons were taught those days. Forget the implied requirements, just get the job done as quickly as possible. Wrong lesson. Early on, way back in high school, I learned about problems with dividing by zero and learned to check for it even if it wasn't explicitly in the code. That was the beginning of input validation. Early on I learned the limits of integer types on computers (also in high school), that was the beginning of learning about integer overflow problems. Secure coding needs to be injected into the entire curriculum to keep the bad habits from developing early but it needs to be done at a skills appropriate level. We're not going to teach people to do a threat modeling when they are doing hello world. We can't teach people to validate input when they have not had any lessons on comparison operators, if statements or case statements etc. Once they've had those though, some basic input validation becomes a great programming assignment to test their understanding of those skills. -- 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] Where Does Secure Coding Belong In the Curriculum?
Brad Andrews wrote: > But we are not talking about separate classes. The assertion (which I > probably clipped, sorry) was that it should be woven into the > curriculum. I was noting where and how to do so, starting in the > intro level classes. Just telling a starting programmer to properly > check input length is all well and good, but falls far short of making > a secure programmer. Sorry if this comes across as a misread of the above but it touches on a pet peeve of mine in this business. Falls far short or that doesn't fix the problem is used quite a bit to dismiss steps we could be taking. Since we cannot create truly secure systems or software, we need to embrace efforts that still improve things as long as the cost of the effort is appropriate for the gain in security. Instead of "properly check input length is all well and good, but falls far short of making a secure programmer" I prefer to think of all the security bugs we could have avoided if most programmers has a well ingrained habit of doing just that. We'd still have a lot of problems left to address but we'd have avoided a lot of pain if this little thing had been taught better or even taught at all. (When I do secure development intro type classes, my if you only take one thing away from today, make it Don't Trust Input. You'll learn the rest later but that one thing will fix many problems.) I went to a different type college than most people. It exists to train officers for the US Army. Most of the military training focuses on basic soldier skills and the things we needed to know to lead small units at the lieutenant level with platoons and captain level with companies if we had to. We knew enough of the higher level skills to be able to put what we were doing into context and maybe, if we got into a really bad spot, we could, for a time, command a battalion or brigade until somebody else could get there to take over. We weren't ready to be generals yet but we were reasonably ready for where we were in our careers for the first several years and most knew there was still a lot we had to learn and practice to really be good lieutenants even though we'd spent four years preparing for the job. > Some will sit through a class with glazed eyes and no understanding. We'll always have that. The old doctor joke about 50% of the doctors out there graduated in the bottom half of their class applies to our industry as well with the added burden of plenty doing what we do with no formal training at all. There are reasons we do peer reviews, formal code reviews and testing. This is just a small piece of the puzzle that has not been addressed well enough but it is just a piece. -- 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] Where Does Secure Coding Belong In the Curriculum?
Brad Andrews wrote: > 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. Getting into exploits at this level is probably more than many can handle but it's not a bad time to teach proper bounds checking and making sure any math operations don't result in overflows. Part of the lesson might even be to create loops with math that cause these errors deliberately if students are no longer taught how numbers are represented in memory and what happens when you exceed the limits directly. Might not be a bad idea though to step back on basic courses and rather than dive in to programing concepts right away start with some demonstrations of what happens with bad code and follow up with refreshers periodically through the course. Nothing in great depth unless the students can handle it but showing them what happens after coding errors might raise awareness and start them thinking what happens when this breaks rather than strictly focusing on how do it get it to work. I cringe at the thought of what I used to do in code based on the habits that started in high school and college. > 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. That's a great start at getting them to think about how they have to treat input and validate it. I don't recall any of my instructors ever focusing on making sure the input to anything is what was expected. I'm sure some did but I don't recall it. Even if the students don't always get it right at this point, get them started thinking about it. > 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. You might not touch on this until you get to those type applications. If they were taught to question input all along though, by time you get to something like this the habit might be forming. -- 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] Where Does Secure Coding Belong In the Curriculum?
Andy Steingruebl wrote: > 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. > > One area here is making sure examples are done correctly. The database examples that connected to an MS SQL server with userid=SA;password="" used to drive me crazy. "The sample code does it that way so I better do it that way." It makes for more complicated sample code but it may be the only way to reach these self taught folks. -- 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] 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] Unclassified NSA document on .NET 2.0 Framework Security
Dinis Cruz wrote: > Don't get me wrong, this is a great document if one is interested in > writing applications that use CAS (Code Access Security), I would love > for this to be widely used. When we recommended recommending CAS during a review of the U.S. Defense Information System Agency's new Application Security and Development Security Technical Implementation Guide earlier this year we were met with what amounted to blank stares. (At least it seemed like that since it was a phone conference.) Some on the call understood it and agreed with the recommendation but those hosting the call and doing the writing didn't seem to grasp it. It may be a while before we see too many adopting this or requiring it for a while. -- Mike Lyman [EMAIL PROTECTED] ___ 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] Software security definition(s)
Arian J. Evans wrote: > What is "secure" software? > It is one quality of an application that can be measured > by the emergent behaviors of the software while trying to > meet and enforce its use-case in a given run-time environment. > Fairly new to the list so if I cover things discussed before or breach some list standards here feel free to jump all over me. What is secure software good discussion to help us set our sights on where we need to go. Want to keep it grounded in the reality of today though just a bit. I think one of the problems we have in the security industry is "secure" itself is a bad term. Somebody, somewhere can find a way to attack any computer as long as it exists. I've often told folks I'm beginning to work with that you could power off a computer, encase it in a block of cement, dump in it the ocean to try to secure the data in it it and Robert Ballard could probably located it and retrieve it for anybody willing to pay for it and meanwhile it hasn't been very useful to you. Even short of that drastic of a step, if users can use it, somebody can attack it. Features themselves are double edged swords; "del *.*" or "sudo rm *" can be useful commands or very dangerous ones. Even with draconian input validation, users could mess up the integrity of the data just by fat fingering input or selecting the wrong item in a pick list or a disk controller going bad could cause garbage. Somebody reading over a user's sholder can comprise the confidentially of the data or listening to them at lunch time. (Ever want to know what is going on at Microsoft just go to the opening day of any major science fiction movie at any theater in the Redmond area.) Flooded network pipes or cut cables can create DoS attacks. A user walking away from his desk without locking the computer opens up non-repudiation issues. "Secure" can be successfully attacked in too many ways and proven insecure. I try to focus more on secure enough to do the job it needs to do in the environment it will operate in. That adds a lot of complexity that is difficult to deal with since it makes simple check lists less useful but it can also simplify things. I've had experiences where we removed security features because they were unnecessary for the application and its environment. Had a design team engineer FT Knox to that could have protected data for years when that data was going live on a public website in less than 24 hours. They were rather surprised to have security remove things that were way too costly for the nature of what they were doing. Just started as the security reviewer/lead on a new project yesterday. Went into my standard introductions about how this is an ever changing world and what passes as good enough today may be wide open tomorrow and we just have to live with that fact. We don't have the time or budget to fully inject security into their development life cycle at this time or dive deep into their code but any improvement is still improvement. What we do now will make them better on the next version or the next project. (Have seen that happen in a big way with some of the teams we work with.) We may have a larger budget next time or get more mileage out of the same budget because of what they learn now. As is all too typical, our customers get us engaged after the project is already in progress so we can't inject security considerations from the beginning and help drive the design or the application or the specifications. We do what we can while in progress. It'll be better than it would have been without our efforts. When we are done, will it be secure? No, we couldn't ultimately achieve that anyway but will it be secure enough for its intended use and environment is the better question. Should be but even then I won't give concrete answer. Based on what we know today it probably will be but somewhere somebody may well be crafting that next attack that blows us out of the water. -- Mike Lyman [EMAIL PROTECTED] ___ 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] quick question - SXSW
Arian J. Evans wrote: > Overall security is not a feature or a function that you can monetarize. > It's not even cool or sexy. It's an emergent behavior that is only > observed when it is making your software harder to use. > Maybe it is just the US Department of Defense environment where I am currently working but I see developers start to see this as cool and sexy. Most are picking it up quickly and a few are even interested in diving in deep into the security world. They ask great questions and are doing a lot of independent research on it. We are in an environment where they get security awareness training a few times a year and are constantly bombarded with security messages but some of them really are getting into it. It gives them something new to learn and it is driving them to go deeper into some development subjects that they normally would not ever be allowed to look at due to delivery schedules. Security is giving them a good excuse to go learn more. -- Mike Lyman [EMAIL PROTECTED] ___ 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. ___
