There are three typical sources of training and skills in the workforce; higher education, on-the-job training, and specialised professional training.
Security is a bit of everything, not a specialty executed by specialists. When looking at how to make developers better at building secure software, the same principle holds true: build security in.
Teaching is most effective when it isolates the lesson from all distractions. A topic like algorithmic complexity is hard to see in the real world when there are so many factors interfering with software’s performance.
>See also: Mind the gap: Solving the skills shortage in software development
Academic education pushes aside the real-world distractions and teaches a principle, like “big O notation”.
This fundamental concept pays dividends over a career. Big O notation came home to roost when Microsoft employees designed a software update system with exponentially increasing complexity.
Industry complains, however, that students are ill-prepared for the challenges of the real world because they spend their academic careers building pedagogical, throwaway programs.
The catch-22 is obvious: adding real-world complexity to academic lessons makes the lesson less effective, conversely pedagogical software doesn’t prepare people for the real world.
Security professionals have long bemoaned the classic text A Book on C by two icons of computer science (Brian Kernighan and Dennis Ritchie) because so many examples in the text were vulnerable to classical security bugs like buffer overflow.
Can secure C code be written? Of course it can. It will never resemble the examples in this classic text.
What is academia’s role? The definition of “correct” must be broadened. Software is not simply correct if it implements an algorithm correctly on good input. As students progress, they should be held to increasingly high standards for handling errors and bad input.
Many security concepts (confidentiality, integrity, availability, privacy, authentication, authourisation) justify an academic treatment. However, they should not be lumped into a single, catch-all course labelled “security”.
Collecting these topics all together means that students either take the course or don’t. Instead, these topics should be distributed across the core modules that are required for a degree. In this way, the basic security topics are covered, to some extent, by every student.
Industry must not only train developers on specific domain knowledge (e.g., financial, geological, medical, accounting, etc.) but it must also keep their software skills up to date.
Industry cannot rely on academia to teach something as fleeting as using an integrated development environment (IDE) or even best programming practices in a particular language.
A student entering a four-year degree programme this year will find that, a year after they graduate, the software they learned has been replaced by a later offering.
>See also: CIOs scared mainframe skills shortage will hurt their business
Security changes over time, too. Concepts change very slowly, but the details can change rapidly. For example, salting and hashing passwords to store them was a best practice for many years, but today that is no longer sufficient.
Given the rapid pace of change in technology, training should be short and frequent, not long and occasional. Every developer must receive regular training in the technologies the firm uses. There is reason to believe industry has heard this message and is increasingly investing in training, with research revealing that global spending on corporate training grew to $130 billion in 2013.
Teaching secure software development should be left to specialist training firms whose job it is to keep up with trends in technology and security. Likewise, professional education sources must incorporate security across each lesson, not in one lesson labelled “security”.
Day-to-day developer education falls to professional training organisations. A big firm might appoint an in-house or on-site training firm, whereas a small firm needs to send its developers individually to open-enrolment training.
It is important that professional education systems also distribute security across all their course work. Developers and firms are less likely to seek out entire courses on security, judging that most individuals don’t need specialist training in security.
Thus, a bit of security must be part of every training course, since those may be the only bits that most developers get.
Developers are technical and turn readily to technological solutions like computer-based training, massively open online courses (MOOCs), and online references. Whatever the delivery method, it is vital that security appears in every development course in some way. No meaningful topic of software development is free from concerns of security.
It is increasingly clear that software developers’ educations are not complete when they finish a degree programme.
Like saving for retirement, software developers must make frequent, small investments in their education, once they enter the workplace. Also, like a pension plan, they need to seek employers who make matching investments.
Employers collectively benefit when they all train their developers. Professional certifications (e.g., the Certified Secure Software Lifecycle Professional) help employers and professionals agree on whether someone possesses knowledge of a given concept.
As training becomes more frequent and granular, it seems likely that smaller and more frequent recognitions will become necessary so that everyone agrees on what an individual does or does not know.
Training developers on the core technologies they use is a clear and obvious requirement. Whatever is on their CV from their previous job is probably already obsolete.
If the professional training companies and universities incorporate security topics within all their other topics, then they will be reflecting what is done in real world software development, that is; building security in by invoking security activities in every phase, not just in one specialised, localised effort.
Sourced from Paco Hope, principal consultant at Cigital
