While so many public sector organisations are (rightly) focused on data leaks and managing the overall insider threat, they may often omit to look after the value and risk of protecting public sector IT systems themselves.
In particular, they may be overlooking the risks around highly privileged users, including the software developers themselves. After all, the source code these people use to create public sector systems and applications is valuable not only because of the investment made to create it, but also because of the highly sensitive nature of the information being handled. A breach of the source code for any of those systems could have consequences far beyond the economics of software-based IP theft.
While the exact scale of the problem is hard to pin down – in either the public or private sector – a Kaspersky Labs survey in 2014 found that just over one in five global organisations had experienced a loss of intellectual property during a cyberattack (across some 4,000 IT managers in 27 countries). Similarly, a US Department of Commerce report found that IP theft of all kinds (not just cybercrime cost US companies as much as $250 billion, while In the UK, a Detica report estimated the cost of IP theft to UK businesses to be over £9 billion.
While public sector systems are not about commercial advantage, they are certainly focused on serving citizens in the best possible way, including protecting valuable, sensitive information. This is why security risk mitigation is already something that CIOs, CTOs, CSOs and IT managers across government departments, local authorities, the health sector and education, view as an important area of technology investment. However, as a number of high profile security breaches have proven, current security strategies are certainly not bulletproof.
Privilege management and other security tools have long been deployed to help reduce risk and while they may do a great job of knowing what Jane Bloggs in the accounts department is up to, they find it difficult to monitor exactly what is happening in the software development function itself. This is due to the way in which developers tend to work. Traditionally, this has meant a fairly siloed approach from the rest of the organisation, with repositories often containing vast amounts of code from many different contributors, possibly all working with different platforms and tools. Plus, software developers tend to have elevated levels of access to data compared to other employees.
More recently, the problem has potentially been exacerbated by the increased use of open source development tools originally designed for open source environments, such as Git and GitHub. These are great tools, but they lack basic capabilities such as file-level access control, immutable change history and protections that are easily viewable and managed. A recent Gartner report highlights the risk around these tools. http://info.perforce.com/report-gartner-sccm-offer.html
Furthermore, there are concerns that while the growth of ‘DevOps’ is generally a good thing, if not executed properly, security might be compromised in the haste to get a software project completed, due to the very fast, intensive release cycles involved.
The ‘insider’ threat can have different causes and motivations: the hacktivist with a grudge against the government, the employee who is leaving and has decided to take some software IP with him or her, whether for their own use or to sell to a third party, the remote developer who may be sharing their credentials when working for a contractor, or an employee whose accounts credentials have been compromised by phishing attacks.
The focus on certain personalities who might present a risk, plus their behaviour, is increasingly being used as a means to identify where the risks may lie. Known as behavioural analytics, it is one of the hottest trends in cybersecurity right now and while it can apply to any part of any organisation, its ability to effectively monitor software developers is driving much of the interest. It works by putting the spotlight on how contributors interact with code and other assets across software and hardware teams.
As well as uncovering unusual activity, it then uses other factors to calculate the actual risk, thus removing the risk of hundreds or thousands of distracting false positives. For instance, behavioural analytics might pick up that a software developer is checking out large amounts of code for no clear reason, or accessing files not core to his or her role, or working at an unusual time of day.
One example – albeit from the private sector – involved a large chip manufacturer that knew IP theft was taking place, but had no proof, despite having spent $1 million on the problem. When behavioural analytics were applied to its source code version control log files, not only were the two suspects proven to be the cause, so were a further 11 unsuspected employees.
However, on its own, behavioural analytics is not enough: public sector organisations also need to build the right processes around software IP protection, including being clear about exactly where the most important assets sit. This is something that alarmingly many do not have a clear handle on, largely because those assets might reside on a variety of different systems—yet is too important an issue to ignore.
Similarly, basic good practice around access management is important, not just privilege management software but also version control tools, which typically control who has access to what within a repository of assets, such as source code, support documentation, databases and so on.
Already ubiquitous in the software development environment, version control tools are increasingly prevalent in more mainstream departments. When they are combined with the new breed of behavioural analytics tools, they take insight into risks to a new level.
‘Back to basics’ security housekeeping may not be exciting, but it makes a difference: multi-factor or continuous authentication may not be 100 per cent fool proof, but it goes a long way towards establishing some barriers, as does ensuring that data is encrypted both ‘at rest’ and in transit.
There is no one-size-fits-all solution to better security in the public sector and inevitably, a multi-layer approach is required, as already advised by the Cabinet Office’s Security Policy Framework (SPF). Protecting against software IP theft and having better control over the ‘insider threat’ – including software developers - is not the whole answer, but it should certainly be an important part of any public sector security strategy.
Mark Warren is product marketing director at Perforce Software, a supplier of source code management (SCM) and collaboration platforms
(c) 2015 24n.biz