Header
1 results were found... happy reading.

Fri, 10 Jul 2009

Wishlist for graduates
@

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:

  1. Secure coding techniques
    • Never trusting user-input
    • Exposure to common attack vectors
    • Assertion and return-code checking
  2. Pen-and-paper analysis (threat models, attack trees)
  3. Destructive testing
  4. SDLC modifications
  5. 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.

[public slides]

Blog
Video
Research
QotW
Categories
about:us (31)
blackhat (5)
blog (10)
broadview (2)
build-it (1)
cloud (12)
community (15)
conferences (60)
crypto (3)
fail (3)
foos (1)
fun (51)
goodbye (1)
hackrack (2)
Hope? (2)
howto (8)
imsojaded (2)
infosec-soapies (25)
infrastructure (3)
local (5)
mac (15)
management (7)
materials (3)
memcached (2)
mindless-politics (4)
mindmaps (1)
PCI (2)
post-it (1)
privacy (6)
product (2)
programming (5)
public (275)
qo[w|m|?] (5)
README (1)
real-world (14)
research (37)
reversing (4)
security-fyi (8)
security-news (6)
silly-yammerings (19)
tech-toys (3)
time-waster (6)
tin-foil-hat (6)
tools (46)
training (18)
travel (1)
tricks (1)
Uncategorized (3)
vendors (6)
videos (6)
vulnerability (7)
wasc (1)
webapps (6)
web_x.0 (2)
writing-advice (1)
zen-hacking (6)
Archives
August 2010 (4)
July 2010 (1)
June 2010 (4)
May 2010 (3)
April 2010 (3)
March 2010 (7)
Feburary 2010 (2)
January 2010 (3)
December 2009 (4)
November 2009 (4)
October 2009 (3)
September 2009 (5)
August 2009 (9)
July 2009 (1)
June 2009 (5)
May 2009 (4)
April 2009 (10)
March 2009 (13)
Feburary 2009 (12)
January 2009 (11)
December 2008 (9)
November 2008 (8)
October 2008 (5)
September 2008 (5)
August 2008 (6)
July 2008 (6)
June 2008 (6)
May 2008 (2)
April 2008 (3)
March 2008 (7)
Feburary 2008 (12)
January 2008 (9)
December 2007 (8)
November 2007 (4)
October 2007 (9)
September 2007 (14)
August 2007 (18)
July 2007 (13)
June 2007 (17)
May 2007 (2)
July 2006 (1)
April 2006 (1)
August 2005 (1)
June 2005 (1)
May 2005 (2)
Archives
Conditions of use Privacy statement
Top of Page Legal stuff