CIE Components in Electronics
At this year’s InfoSecurity Europe show in London a new term was frequently referenced: DevSec. An abbreviation of the phrase ‘development security’, it highlights the fact that there are increasing concerns around the security processes surrounding software development, increasingly at the heart of many electronic design projects.
Several factors contribute towards this focus. First, there is a growing awareness of the ‘insider threat’ as one of the biggest sources of security vulnerabilities – software development environments are notoriously hard to monitor with traditional security tools. The ‘insider threat’ does not necessarily mean staff acting with malicious or illegal intent: they could simply be careless, making it possible for someone externally to hack or impersonate their online identity to perpetrate IP theft.
This is not just theory. Last year, 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 behavioral analytics tools were applied that some rogue employees were proven to be the culprits. Of course, very few companies want to publicise IP theft, so it’s hard to measure the overall size of the problem, 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.
With DevOps comes DevSec
Another factor contributing to ‘DevSec’ concerns are modern development practices, particularly the exponential rise of DevOps, which is wheredevelopment and operational teams work in a more collaborative way to bring software projects to fruition more quickly. Organisations are concerned that as release cycle times reduce with the adoption of Continuous Delivery, they don’t reduce security nor slow down deliveries.
The problem is 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. Traditional security tools – even those designed to address the ‘insider threat’, such as privilege access management systems – find it hard to get real visibility of what is happening in the software development environment. 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.
So if that’s the problem, what is the answer? A new approach to protecting software development projects from security vulnerabilities, one that is not dependant on defending the perimeter but instead, is more data-centric, accounting for how contributors interact with code and assets across software and hardware teams. Here are five steps to consider:
1. Identify the most important IP assets in your organisation – 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.
2. Choose which groups and/or individuals should have access to this IP – traditional privilege management tools have a role to play here, but other tools also have access control built-in too: for instance, 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.
3. Use multi-factor and/or continuous authentication and fine-grained access control to protect access to critical assets – 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.
4. Provide ability to encrypt data at rest and in transit – again, this is nothing new, but is good ‘best practice’
5. Ensure that all access to IP is continuously monitored – it is good practice to have detailed audit logs implemented in a secure SCM repository, with the support of behavioural analytics tools.
This last point is particularly relevant. Behavioural analytics is one of the hottest areas in security prevention right now and is gaining a lot of interest, because it approaches identification of security vulnerabilities in a different way. To illustrate that, let’s go back to that earlier example of the global chip manufacturer who suffered IP theft. The company in question 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.
The culprits were eventually traced using behavioural analytics, based on applying an algorithm that looks at the activities of individuals within the organisation and then calculating the likely risk of threat. The company ran history log data from its Perforce version control system through a behavioural analytics engine from a company called Interset, turning some 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.
Behavioural analytics is based on not just surfacing unusual activity but just as importantly, other factors that calculate the risk. This prevents companies being overwhelmed by the sheer volume of security ‘noise’. 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.
This approach is also in tune with the growing acceptance that however robust the castle walls, the ‘bad guys’ will find a way in. The key is how to identify them and stop them in their tracks. However that is achieved, it is clear that as electronics development become ever dependent on software, security risks – including IP theft – cannot be ignored.
Author Biography
Mark Warren is product marketing director Perforce Software. Worldwide, the version management and code collaboration portfolio from Perforce Software is used by thousands of customers, including Salesforce.com, NVIDIA, Samsung, and EA Games. Mark has over two decades” experience in the software industry with roles as a provider and consumer of advanced development tools.
