5 Steps to Get Your Developers to Care More About Security
Table of Contents
The relationship between security and developers has traditionally been like two teams competing at a tug-o-war. On one end developers are pulling to produce functional products at breakneck speeds, whilst at the other security is pulling to ensure the product is as secure as possible. However, does it have to be this way?
Below are 5 points on how to ease tensions between developers and security by getting your developers to care more about security. After all, no one wants a secure application if it’s unusable, just as it’s unfeasible to have a beautifully crafted app which is ridden with vulnerabilities.
1. Moving security to the top of the corporate agenda
As a security manager, you probably get frustrated when your developers don’t give security the attention it deserves. Well, before expecting developers to make security a priority, first management needs to. However, how do you get the big wigs to place more value on security when companies are under increasing pressure to push their product to market before their competitors?
As you know, most executives are concerned with the overall effectiveness of an organization, and they don’t really drill down into the bits and bytes of an issue. Therefore, in order to get them engaged with software security, you first need to speak their language. Present the potential risks and business impacts of security vulnerabilities, and then they will be more open to your proposed security solutions.
In order for your arguments to hold the most sway, be armed with a clear security analysis. Your aim is to convince management on how increased software security prioritization will both make the software development lifecycle more agile, whilst also boosting your company’s revenue due to negating the need for any preventable last-minute software security remediation. Also, if you can, win over someone from Finance to back up your proposals– this will be sure to make management’s ears prick up and listen. Ultimately, once you have management on board with security, the rest of the organization should dance to the same tune.
2. Getting developers engaged
Ok. Now management are pushing for increased security, logic dictates so will your developers, however they can be an unruly bunch. If developers cannot see the actual risks and consequences of security vulnerabilities, they are less likely to see the importance of adding potential traction to the software development lifecycle.
The Shellshock bug is a great example of how developers can take the initiative when solving a software security issue. After all, only two days after the bug was discovered, developers at Red Hat, Ubuntu amongst others pushed out a second fix. Not only that, the bug shed much-needed light on the need for shell scripting security, and as a result, many developers shifted towards using secure scripting languages tailored for the task at hand rather than for general purposes. In short, once developers come to see the real threat of security vulnerabilities, they will naturally look to produce more secure code in future.
3. Training your developers to deal with security issues
A Ponemon Institute report showed that 71% of developers believed that security was not adequately addressed during the software development lifecycle. This figure is revealing as it demonstrates developers often wish to engage with security issues, yet they feel unequipped to do so. This highlights the drastic need for developer security training.
Before security go gun-ho and start telling developers how to do their job, it is essential for any training to take into account the time and remediation constraints that developers face. An excellent example of what developers can do in regards to remediation is open source and proprietary product vulnerabilities.
With proprietary vulnerabilities, it is the developers themselves who wrote the code, therefore it will be a lot easier for them to identify and remediate any potential security issues this is not the case with open source.
As open source components originate from a third party, in-house programmers can only identify a pre-existing vulnerability, and in turn it can only be remediated when the third party source has released a patch/fix. Furthermore, when developers choose open source components, functionality is at the top of their agenda, meaning they rarely check if the libraries they are about to integrate into their software have vulnerabilities.
Finally, when engaging developers, you should ensure you’re approaching security issues from a developer’s perspective. Therefore, for any training to hold sway, it needs to be grab developers’ attention. Share newsworthy updates of high-profile cyber-attacks, data leaks or other security issues that caused real damage to software – just think of the stir Heartbleed caused amongst developers!
4. Gamification – Sliding security through the backdoor
A great way to improve your developers’ security awareness is Gamification. The whole idea centers around getting your developers to seek out additional security not because they have to, but because they want to – I know this might sound a little far fetched but stay with me.
Gamification basically means applying game principles (competition, points, levels and rewards) as a way of solving non-game problems such as business challenges. In order to do this, every game has to have clear goals, rules, incorporate feedback and of course participation has to be voluntary.
Microsoft had a challenge, how to get developers to engage with the often tedious task of assessing software security diagrams – as I’m sure you can relate. They found the answer in their card based Elevation of Privileges game.
Players first draw or obtain an architectural diagram of a system they want to threat model, they are then dealt out a set of cards with names like Three of Tampering with descriptions such as ‘An attacker can manipulate data because there’s no integrity protection for data on the network wire’. As each player takes their turn, they must read the threat on their card aloud and explain how it applies to the system being threat modeled. By playing the game, the team gets to assess all the potential vulnerabilities which could affect the system without overlooking anyway. This game became so popular and effective, it has migrated online and it can now be played remotely.
As can be seen from Microsoft’s example, gamification is a great way for developers to embrace security, for you don’t realize you’re learning when you’re having fun, right?
5. Stopping developer headaches – Security as a mainstay of the software development lifecycle
Everyone knows that fixing security issues once software has been released, compared to at the development stage, is a pain for developers and security alike. So, what is the solution? The answer is simple; security should maintain a constant presence throughout the software development lifecycle.
As a security manager, you should lead the way in ensuring that security assessments are performed at each design milestone. For example, straight after the initial architecture build and development, source code should be analyzed and any issues fixed. After the next hurdle, perform the analysis again and compare the number of issues raised and squashed compared to the first milestone – and repeat. At the end of the process, you can identify common issues and integrate lessons learned into your next developer security training. Not only will more issues be eliminated earlier on in the development process, but developers will get to hone their secure coding skills.
The final result will be fewer headaches and tension between security and developers. After all, no one wants to build a house only to learn it needs to be pulled down due to unsafe foundations.
Bridge over troubled water
And there you have it, a step-by-step to of how to get developers and security pulling in the same direction.
By making security a top company priority, implementing topical, appropriate, inclusionary and engaging developer security training and ensuring security isn’t just an afterthought along the software development lifecycle, you can ensure that developers are no longer hiding behind their desks the next time a member of your security team drops by.
