Posted by David Harvey on October 13, 2016
Software security training is an important part of software development. In the latest Ponemon study on data breaches, training and awareness programs are the number one control implemented after a data breach. However, as with any security control, it’s possible to incorrectly implement training. Within this post, I’ll discuss several common software security training hurdles that organizations often experience, and explore how to prevent and/or overcome these problems.
An all too frequent training paradigm prescribes a ‘scattershot’ approach. This approach requires all employees to attend the same training, regardless of their role. A (possibly extreme) example of this is a course on common attacks and defenses for Web applications written in Java. All software developers doing mainframe client-server maintenance in COBOL are required to attend. (Unfortunately, this was actually the case for a course I was brought in to lead.) An instructor always tries to focus material to the level of expertise and the needs of the students. When a vast range of roles and areas of expertise all attend the same course, this becomes incredibly difficult.
To implement the most effective training experience, the course must be complementary to the role(s) of the attendees. Software developers and testers require training with a heavy technical focus. On the other hand, project managers require training opportunities with more of a business focus. Even training carried out to ‘check the box’ for compliance (e.g., SOX, PCI, HIPAA) should be customized based on role. Otherwise, it is very likely to be a complete waste of time and money.
I often see training programs that are static year over year. Since software security is a facet of software engineering, it is constantly evolving. This is true of all aspects of software. With few exceptions, training offerings involving frameworks and languages that haven’t been updated within the last five years should be examined carefully to ensure they’re still relevant. Even if the technology or practices in use aren’t evolving, attackers most definitely are. Additionally, they’re using new or novel attacks and pivots on previously used attacks to break into legacy systems.
If appropriate, and if the audience is sufficiently technical, it’s important to include technical details of recent breaches. In my experience, students find these discussions to be very interesting, even when the technology involved in the breach isn’t that of which they’re currently working.
As a technologist, I’ve been asked to develop content that a professional trainer with a background in something other than software development could present. This is ostensibly to trim the training budget. However, this approach has always been a waste of time and money. It’s not that the person carrying out the training is incompetent in some way. As with anybody receiving training, software developers and others in the software development practice like to know that the instructor is someone who has experienced similar challenges. For example, it is relatively simple to describe a SSL certificate management strategy based on the Java KeyStore. It makes a world of difference to trainees if the instructor can also give useful information about common KeyStore issues and how to debug them. Otherwise, they can simply use Google to get the necessary information.
As with any security control, budget allocation is a requirement for the implementation of security training. It’s often helpful to frame the discussion in terms of the potential data breach cost to secure training funding. There is no shortage of data from Ponemon, Forrester, and others that quantify the cost of a data breach. The 2016 data from Ponemon describes an average cost of $221 per stolen record across the board. Additionally, there’s a much higher per-record cost for industries such as healthcare, life science, financial services, and transportation.
The abstract from the Forrester Research report from January 2015 states that we are in the midst of the golden age of hacking. If Forrester is correct and this is indeed the golden age, there will undoubtedly be a platinum and a dilithium crystal age of hacking too. We are only beginning to see Internet of Things devices (e.g., your dishwasher, your self-driving car, your smart roads) and cloud computing at scale. Thus, hacking will continue, new threats will emerge, and risk will continue to rise. In the last five years or so, software security training has emerged as a fundamental part of software development. Your competitors, especially those that have experienced a data breach, have made software security training a priority. Don’t wait for a breach before making effective training a priority.
Get the latest Software Integrity news, thought leadership, and more.