There has been a lot of hoopla lately around “secure programming skills” – with not-so-thinly veiled condemnations of academicians and the role of the university in addressing the IT security problem.
While it’s tempting to view education as synonymous with training, that really does neither concept justice. I’ll argue that the role of education, (as provided by an accredited college or university) is threefold;
- Refining one’s ability to think critically by exposure to a wide variety of subjects,
- Teaching students “how to learn” and
- Giving deep exposure to the theoretical underpinnings of a particular subject.
On the other hand, training assumes that the prior three conditions are already met, and as a result, focuses on time-bounded transfer of information – with an emphasis on the applied (rather than theoretical) particulars of a concept. Put differently, if I have a degree in physics this does not necessarily make me qualified to work on nuclear reactor design. I need training and practical experience on this subject before I put my education to effective use.
I have been a manager at Microsoft for a number of years, across many teams – given the opportunity, I hire for aptitude rather than skill set every time. That’s a firmly rooted hiring philosophy here at Microsoft. I want people working for me that “grok” security and have the capacity to learn, because this is a rapidly evolving field. Sometimes, I don’t have the luxury of hiring for aptitude and I need someone with specific skills – however, if I have the luxury of smart people, I can tell them “go learn how ‘foo’ works” and have a high degree of confidence that the end result will meet my expectations.
So how does this relate to computer security? Comprehensive system security consists of (among other things) solid design, coding and testing expertise – focusing on one at the expense of the others is simply an incomplete solution to a problem that demands our best efforts. Unfortunately, there’s an assumption held by many in our (IT) community that the road to better security leads to “drinking from the fire hose” – that is to say, employees are rocketed through week long training classes, then drilled and tested on security topics. Without the necessary exposure to secure systems design and concepts, more often than not these classes simply become a blur. Moreover, without the proper theoretical basis, little understanding of core concepts is actually achieved. The notion that time bounded, “point” solutions like training and skills testing alone provide a “better” long-term result is simply a fallacy. We haven’t yet defined what a better long term result is. Is it fewer stack smashes? We could achieve that with managed code, and no security training at all.
It’s absolutely true that there are many applied security concepts (normally classified within the realm of “training”) that can and should be injected into IT focused curricula (CS, EE, SE, CE, MIS) at universities. Exposure to these concepts would not detract from the overall quality or effectiveness of a program of study – indeed many universities are already working on the problem. However, the university is not the place for skills enhancement or job re-training. It’s my view that universities are places to “tinker” – the environments best suited to ask “What if…?” type questions – precisely the type of activity that encourages exploration into things like architecture and system design.
We need both education and training to reach maximum potential in the shortest amount of time.
We require our SDL training to emphasize the basics of secure design, development and test – then allow employees and their management to select the training that meets the needs of their particular product or service. There is one other point that bears mentioning – our training is constantly being reviewed or embellished to make sure that emerging security or privacy issues are being addressed. It’s an approach that is delivering results. We do not skills test. Skills testing is a static process that simply establishes one’s specific conceptual understanding at a specific point in time. It does little to insure that the conceptual understanding is being applied when actually building software. We test our code and our products at various stages of the development process – because that’s what we deliver to our customers. It’s also where we believe validation processes are the most effective.
Circling back to the role of security education versus security training – my request of our colleagues in academia; don’t get distracted by the IT community noise – keep your “eye on the ball.” If you are presented with the opportunity to inject more security and privacy concepts into your teaching, do so – the computing ecosystem needs it and will be the better for it. But, for the sake of real computer security and a continued cycle of innovation – keep sending us the thinkers…