When we think about information security, the tendency is to focus on stolen customer data, fraud and malicious software attacks. While these continue to be concerns, right now there’s increasing focus on another area: the theft of software-based intellectual property (IP).
Motivations might include selling that information to a competitor or a criminal organisation - given the existing trade in computer fraud, there’s no reason why criminals can’t extend their activities to software theft and resale - or to undermine launch plans for a new product.
At the very least, theft of software-based IP could severely damage the bottom-line and could even lead to job losses and the demise of an organisation.
This is not scare mongering. A recent Intel Security/McAfee report cited this example: [A] “firm with 800 employees had to cut its workforce in half after hackers stole its IP and a competing product appeared on the market.” A US Department of Commerce report found that IP theft (all kinds, not just cybercrime) costs US companies $200 to $250 billion (£127-160 billion) annually, while the Organization for Economic Development (OECD) estimated that counterfeiting and piracy costs companies as much as $638 billion (£407 billion) per year. Similarly, a PWC report into global cyber security discussed the increasing incident of Intellectual Property (IP).
Software-based IP theft should be a universal concern. Given that these days most organisations have software integral to some – or even most – of their IP, clearly this is too important an issue to ignore. While there are some more obviously vulnerable companies, such as computer games firms, most products or services depend on software to one degree or another.
So who’s perpetrating these actions? Like so many aspects of IT security, the spotlight increasingly falls on the ‘insider threat’, with data breaches or leaks caused accidentally or maliciously. Indeed, the same PWC report cited earlier also found that most security incidents are caused by company insiders. The perpetrators are wide-ranging, but here are three typical categories:
The hacktivist – these are insiders who capture sensitive data and share it, while remaining anonymous. He or she may be selling that information on to a third party.
The careless employee – most of us will have known colleagues who move data to insecure locations in order to make working processes that bit easier for them. However, this can be highly risky, because they may be inadvertently opening up holes in the security framework, allowing external parties to imitate legitimate employees.
The leaving employee – alarmingly, a Symantec study found that 56 per cent of workers believe it is acceptable to take data with them and use it at a competitor. This includes not only customer contact lists, but also the IP and trade secrets related to the programs with which these employees were involved.
Of course, existing SIEM tools are designed to identify and monitor software security and they have a role to play. However, there is a big difference between flagging potential attacks and identifying where the real risk lies, hence why so many security leaks and breaches continue to make news.
Plus, there is one very fundamental aspect of software IP with which they struggle: software developers and their activities. This is largely due to the very siloed way in which software developers work, typically with processes and tools not shared with the rest of the organisation. Code repositories do not lend themselves to close scrutiny and thus have been something of a security black hole to date, something that is quite alarming, when considering how fundamental software development processes are to many organisations’ survival.
So how do you better protect your software-based IP? Fortunately, there are ways in which to overcome this challenge - but what does that mean in practice? Here are 4 essential tips for better protection of software-based IP assets.
- Work out where those software-based assets live
In many businesses, data is stored in a wide array of places and often in very different formats, so it may sound obvious, but having an overall picture of where sensitive or valuable data is stored has to be the starting point, together with how those assets are being protected.
Code should be a particular area of concern, because the code may be stored in an insecure version management repository or – in many instances – in multiple repositories. So the first step should be to find the code and then consolidate it into a single version management system, one that has robust security options and audit trails. For example, does the system offer file-level access control and immutable history logs? Who is allowed to access what? And when did they last access that data?
- Put context around the risk
Again, this is particularly true of any code assets, because traditional SIEM tools are typically not designed to provide an understanding around the file types, tool usage and processes used in software development.
A vulnerability management system might flag up an overwhelming number of false positives, or require huge amounts of continual fine-tuning to discover real risks. The answer is to put some context around the risk, by looking at user behaviour, content type, and activity and very importantly, compare that with whatever is agreed to constitute ‘normal’.
- Focus on the real risks, ignore the noise
Today’s software development environments inevitably generate a huge amount of data and that is not about to change any time soon. A version management system for a large corporate could easily be processing millions of transactions per day. Again, the solution is to have solid context and analysis. Behavioural analytics is increasingly being adopted to achieve this, because it can narrow down thousands of potential incidents and identify the ones that are most likely to be a real risk.
Human behaviour plays a big role in behavioural analytics: ‘wanderers’ could be developers who are checking out large amounts of code from projects on which they do not usually work, while ‘hoarders’ might be downloading code which they then do not check back into the versioning repository. Of course, there may be perfectly acceptable reasons for these actions, but at least the organisation has a starting point for further investigation.
Other aspects to consider might also include looking at staff accessing data outside their usual working hours, or automatically assuming that staff about to leave the organisation has a higher risk factor associated with them.
- Detect and react
While perimeter-based security tools are necessary, evidence shows that they are not a 100 per cent guarantee, and are unlikely to be so. Plus they don’t really address the issue of the trusted insider abusing their access rights. As numerous high-profile information security stories demonstrate, the ‘bad guys’ are still getting in. Since prevention can’t be guaranteed, many organisations are turning more towards a ‘detect and react’ mode of operation.
Once behavioural analytics tools are used to scrutinise data from the version management tool and apply algorithms to identify risky behaviour, the next step is to take action and fast. This might include locking down access and then forensically examining log data from the version management system.
Here’s a real-life example of how that works: a well-known global chip manufacturer knew that its software IP was being stolen and passed on, but could not prove who was carrying out the theft, where or when. It spent over a million dollars with a large consulting firm, but one year later, the cause of the theft was still not determined. The breakthrough came when a behavioural analytics tool was applied to the Perforce version control log data and not only was concrete evidence found against the two suspects within a fortnight, a further 11 unknown developers were found to have been replicating up to 500,000 files per day.
To give some perspective, the behavioural analytics engine examined over nine billion events, covering some 20,000 software developers.
Protecting IT assets a fundamental part of risk mitigation strategies
The chip manufacturer is a perfect demonstration that however strong the security processes, regardless of how many sophisticated security systems are in place, or awareness by employees of risky behaviour, security risks are going to happen. While prevention is obviously better than cure, having a secondary line of attack in the form of ‘detect and react’ has to be integral to any security plan.
Given that software is a core part of many organisations’ IP, protecting IT assets should be a fundamental part of risk management strategies.
Mark Warren, Product Marketing Director, Perforce Software