We were invited to speak at the recent ISSA2009 conference in Joburg, a local mostly academic security conference and I decided to carry a message in addition to the regular demo-style talk with which we try to entertain. By co-incidence, Haroon also had his peer-reviewed talk on Apple Exploitation Defences accepted so there were two SensePosters talking to the tweed jackets. I figured the most important bit of the presentation should be mentioned first, so before we carry on I’d like to present our attacker:
He was quite dashing and very well received. With that out that way, let’s carry on…
The message of the invited talk was this: universities should be doing more to educate Comp Sci graduates with regards to designing and building secure software (actually, anyone who is involved in application dev, including Comp Sci, Informatics, Software Engineering etc.) From an international perspective this is probably self-evident and security courses at undergraduate levels do abound or at least security in integrated into non-security courses in a meaningful way at prominent varsities in the US and EU, however this idea is not wide-spread in local academia. By way of comparison, a brief survey of notable local Comp Sci departments did not yield a single undergraduate course that listed security in any course contents (as in, covered at some point), whereas entire undergraduate courses in compilers, AI, graphics and game design were available. In a recent blog, Matasano’s Ptacek blogged that if you’re typing A-E-S into source code, you’re doing it wrong. Contrast this with my experience of a security course at a ZA university that contained more material on X.509 certs than on secure coding and defensive coding techniques.
It leaves devs in a very bad place. They enter industry without any knowledge on how to design, build or analyse secure applications and, since their first encounter with security requirements is often as a result of an incident, the subsequent impression of security people and requirements is not positive. Even if they are sent on security training by their respective organisations, the training will in all likelihood cover only those aspects of security that pertain to the technologies that the organisation uses leaving the devs with what amounts to bolted-on knowledge. Smarter people than I have differentiated between education and training, with the former taking place at univerisities and training happening ad-hoc when the need arises.
There is definitely room for both education and training in the security space, however when developers solely look to industry training to provide their entire secure development knowledge, such bolted-on knowledge just doesn’t suffice.
Incidentally I don’t pretend to believe that secure coding is completely teachable but that’s not attainable in any subject, just as exposing students to parallel programming doesn’t guarantee they’re writing race-free code. However they will understand races, know what they look like and be able to fix them without tilting over at the first sight of overwritten data. The same goes for fundamental security patterns.
As such, we went to the conference with a wishlist of what we’d like undergraduates to cover at some point in their degree, so that when they leave university after their first degree they are already in a position to at least consider the security implications of a given piece of software in a rigorous manner and identify and try mitigate some of the threats through prior exposure in a friendly environment.
The list below really is basic and I’m hoping will be a starting point for discussion. Actual implementation will require much fleshing out, but the skeleton that flesh should be packed around might look something like:
- Secure coding techniques
- Never trusting user-input
- Exposure to common attack vectors
- Assertion and return-code checking
- Pen-and-paper analysis (threat models, attack trees)
- Destructive testing
- SDLC modifications
- Security libraries
With this out the way, we opened the floor to questions/comments (none) and then invited the gathered attendees to contact us if interested looking to implement these in their undergrad courses.