Five Ways Secure DevOps is Easier Than It Looks
The need to secure the enterprise is hardly news, but in 2015, we’ve witnessed an increasing emphasis on the need to better address security in the development environment itself. Coined ‘DevSec’, it highlights the fact that despite companies spending considerable amounts of money over the years on traditional software security tools, the ‘insider threat’ still remains and that the development environment is potentially one of the riskiest areas of all. The consequences are not just hacks, viruses and leaks: software-based theft, in other words stealing code and other assets usually for financial gain, is an ever growing concern.
Software development environments are notoriously hard to monitor with traditional security tools, so it can be very hard to track who, where or how a security breach or hack is occurring. While most incidents are likely to be accidental, there is still a very real threat of internal staff also abusing their privileged access for nefarious gains.
This is not alarmist speculation: while no-one talks about the scale of the problem publicly, there are some known cases within the industry. For instance, in 2014, one of the world’s largest chip manufacturers suffered significant IP theft of its source code. The company spent a year trying to identify the root of the problem and it was only when behavioural analytics tools were applied that some rogue employees were proven to be the culprits.
This is – hopefully – an extreme example and it is hard to put numbers against the global cost of software-based IP theft, but according to Kaspersky Lab, one in five manufacturing firms reported a loss of IP in 2014. In the UK, a Detica report estimated the cost of IP theft, to UK businesses, to be over £9 billion.
DevOps brings DevSec
Another driver of interest around DevSec is the exponential rise of DevOps. Although this approach has many benefits – not least of which is the way in which better collaboration between the developer and operations teams brings products to market more quickly – there are concerns to make sure that reduced release cycle times does not mean reduced security.
Regardless of whether or not DevOps is involved, the risks around developer security are exacerbated by the volume and variety of contributors involved in many software projects, making it increasingly hard to keep track of who is doing what, where and how. Even traditional security tools such as privilege management access – which are designed to mitigate the ‘insider threat’ - find it hard to get any real visibility of what is happening in the software development department. Code repositories are typically siloed and while developers may be part of a team, they are often isolated from the rest of the organisation in the way that they work.
The good news is that there is a new solution to IP threat detection, based on putting the spotlight on how contributors interact with code and assets across software and hardware teams. At its base is behavioural analytics, one of the hottest areas in security prevention right now.
It works by approaching the problem in a very different way. Let’s go back to that earlier example of the global chip manufacturer who suffered IP theft. The company was aware that software engineers had stolen large amounts of high-value data, but it could not prove the case or detect the known suspects’ activity, despite spending over £1 million with a large consulting and services firm.
Using the unique algorithm technology in Helix Threat Detection, it was possible to run historical log data from the Perforce Helix version control engine through its behavioural analytics. This involved turning 9.1 billion ‘events’, executed by 20,000 software developers, into useful and actionable data. The result was that in less than a fortnight, concrete evidence was found against the two suspects, but also, a further 11 unknown developers who had been replicating up to 500,000 files per day.
What’s clever about behavioural analytics is that it does not just surface unusual activity, but uses other factors to calculate the actual risk, preventing companies from being overwhelmed with security ‘noise’ that is hard to interpret. For instance, behavioural analytics might pick up that a software developer is working at an unusual time of day, or checking out, but then not checking back in, large amounts of code, or accessing types of files that are not core to their roles.
Five questions to ask
Of course, any technology is only as good as the application. Working with customers and partners, here are five ‘best practice’ questions to ask when looking how to have a better ‘DevSec’ strategy:
- Where and what are your most important IP assets? - Understand where this IP lives and which tools are being used to manage IP. Many companies struggle with this one because having IP living in different systems can make it hard to have a single picture.
- Who should have access? - Traditional privilege management tools have a role to play here, but other tools also have access control built-in. Version control tools typically include features that control who has access to what within the repository of assets, which might include source code, CAD drawings, support documentation, image files and so on.
- Are you using multi-factor or continuous authentication? - This is basic good ‘housekeeping’ security practice and while these traditional approaches are not 100 per cent successful, it makes sense to put in place as many barriers as possible, particularly where staff might be accessing assets remotely or on the move.
- Can you encrypt data at rest and in transit? - Again, this is nothing new, but it makes sense to batten down the hatches in as many areas as possible.
- Is access to software-based IP continuously monitored? - It is good practice to have detailed audit logs implemented in a secure SCM repository, with the support of behavioural analytics tools.
Protecting the developer environment is a combination of constant vigilance, adopting rigorous processes and using the right tools. Furthermore, in tune with the current zeitgeist that ‘the bad guys will always get in’, it makes sense to spend to put as much effort in to identifying internal risks, as it does in protecting the perimeter.
