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
And currently being at uni, I see little hope for most of the people around me ever being able to write secure code, thank god most of these people are going to be writing web apps where the damage they can do is limited.
Even some of the brightest students I know don't care whether their code has trivial overflows (they know about overflows, but they just don't care).
I sat through a largely very boring lecture from Alan Palmer (or someone) from SANS (where the guy had the acronym TOCTOU on his slides, but when someone in the audience asked him what it was he had no idea, I lol'd), where he raised an interesting idea for educating developers to write secure code: roll it into all the courses. Not by having lectures on it, but rather by having a 'secure coding office' where students can take their assignments for people to review and tell them where they went wrong, and
how they could do things better, or write code defensively, etc.
However this was based on the premise that developers *want* to write secure code, personally though I think there needs to be someone kind of incentive because, while I'm not sure about other unis, doing 4 COMP courses in a semester (which is a full load), *really* loads me up with lots of assignments.
</rant>
The "teaching security" debate seems to center on whether secure coding is taught separately or is integrated into basic coding courses, and I imagine a mixture of the two would work. That is, teach the basic ideas of assertion checks and destructive testing from the start, and extract threat modeling/attacks/libs into a separate compulsory course. The items on the wishlist wouldn't have to be taught altogether; I foresee that by graduation the graduates would have been exposed to those items at some point.
As to the lack of incentives for writing secure code, this is an area where the varsities need to implement changes. The obvious route is that assignments should have a security component included that features prominently in the mark allocation.
for example, _a_ design might require crypto to hide sensitive data. a _better_ design would not pass the sensitive data around in the first place. that kind of thing.
so the topic could go under analysis...