Recent research claims that a quarter of third party apps are high risk and although they're banned in some organisations, policing that ban is difficult. Third party apps and especially open source ones are great and play a very important task in today’s development practices, however, in order to ensure they are not putting your applications at risk, developers need to learn how to code securely.
Unfortunately, in most cases, developers are measured on how fast they can write code rather than how securely they write code, so how can we change that? It starts with changing the culture from within and through a step-by-step programme including gamification.
One of the main reasons why applications are so risky is because they are not developed with security in mind. This is primarily because companies are under pressure to release applications and updates as quickly as possible. In reality, this means that the developer finishes writing the code as quickly as possible and then it's passed on to the security team who normally employ various black box testing methods to find vulnerabilities.
Once this process is complete, the developers are asked to fix the vulnerabilities at which point they are much less familiar with the code. This is a time-consuming process and in some cases, there is simply not enough time to fix the vulnerabilities and the bugs that impact the user experience and this is where security falls down as vendors make the hard decision between fixing everything and releasing to the market on time.
Security vs development
In addition to this problematic state of play, security managers themselves say that the biggest problem for them is a lack of application security (AppSec) skills. In the recent SANS Application Security Survey completed by over 400 security managers, 38 per cent said that 'lack of application security skills, tools and methods' was one of their top challenges.
So even if the process could be changed, there aren't enough developers out there that can write secure code. Security professionals are outnumbered by developers which leads to bottle necks before release and the two are siloed with developers wanting to code and security wanting to test. So, with this in mind, how can we change the status quo? For me, it has to be about getting the code more secure to begin with and to achieve this, we have to tackle some of the keys challenges head on.
I believe that by exposing developers to security as part of the coding process, they can learn more about creating secure code and so reduce the time needed for testing while also bridging the gap between themselves and the security teams to avoid the natural frustrations of not understanding the importance of each other's roles. So much was my belief in this that we created a secure dev kit to inspire developers to get more interested in and acquainted with secure code.
Running the programme
To gain more insight into the process we ran the program initially at our HQ. The experience was fantastic but we are a security company and aware of the need for secure coding so it was probably easier for us than others. So when we had one of our customers ask us to help them with their education program, we got the chance to see how it works in a “regular”, non-security centric organisation.
We ran the programme at a publicly held American technology company, with development teams in various different locations globally, developing products for online messaging, marketing, and analytics. A group of 200 developers were selected to pilot the secure dev kit programme which aimed to effectively educate developers on secure coding best practices. This is how it worked and what we found:
The first week was fully dedicated to creating engagement. The objective was to trigger curiosity and provide context. A formal email was sent to the relevant development teams launching the programme while we used gamification to create excitement. Teasers with basic quiz questions were posted on kitchen and bathroom walls and left on keyboards. Posters with application security tips were posted around and stickers and printed tips were also provided.
The second week was about education. While fun and games are important, the priority of the programme was to enhance the skill set of the developers so we pushed out materials for education based on the languages developers used. Before you announce another quiz, announce the winners from the previous quiz and what they won. We found that even a small prize achieves a positive effect.
For the third week, we needed to create a more challenging quiz. At this stage, we could see the developers already in healthy competition. We hung “Spot the vulnerability” posters which resulted in groups of developers sitting and competing to see who could spot the vulnerability first. We brought this phase to a close while making a big deal of those who spotted the vulnerability and then announced the final challenge.
For the grand finale in week four, an external speaker was brought in to add another dimension to the challenge and give something back to the developers by giving them the opportunity to hear an expert speak. In this case, that expert was me. The challenge then covered questions of a variety of levels with both theoretical questions and real code vulnerability samples. Attendance wasn't mandatory but almost 200 developers participated for a chance to win a trip to BlackHat proving that providing the right environment and incentives and using gamification really does result in developers being much more engaged with security.
There are now over 400 organisations using the secure dev kit to kick off their AppSec education programmes and while the feedback we get is amazing, it wasn't always easy to get things started. While the security team were very enthusiastic, developers who see security as a burden that slows them down were sometimes reticent to take part so getting management buy in did prove tricky.
Starting small and making the programme fun with gamification and small prizes does get people on board and it's a programme that can be run on a very small budget that will show a clear ROI in the long term. The key after that is to keep the environment going and continue to encourage security awareness in coding.
Amit Ashbel, cyber security evangelist at Checkmarx