Managing accidental data spills

Andy Swift at Six Degrees explains how to manage accidental data spills, however they are caused

 

In recent months Fujitsu hit the headlines after it spilled private AWS keys, client data and plaintext passwords out into the open and, even more worryingly, this spill went unnoticed for nearly a year.

 

Unfortunately, in today’s golden age of data this type of unintentional exposure is becoming all too common. The larger an organisation is, the more ‘shadow data’ it often has, and the harder it seems to be to keep track of all the different places data is being stored.

 

Regardless of whether it’s because of human error, carelessness or incompetence, the organisational impact of an accidental data spill can be severe. Alongside potentially exposing proprietary or highly confidential data to cybercriminals looking to disrupt operations and perpetrate fraud, data spillage can also lead to regulatory fines, lawsuits, and significant reputational and financial loss.

 

In this day and age, no organisation can afford to overlook the importance of data and cyber security. However, for larger enterprises, applying the correct procedures is often easier said than done.

 

Unfortunately, Computer Security Incident Response Teams (CSIRTs) are all too familiar with cases such as Fujitsu’s. Let’s take a look at some of the common pitfalls that can trip enterprises up – and the steps they can take to address these challenges.

 

Code repositories

In multiple instances, incidents have been uncovered where the root cause of a breach was the public exposure of sensitive data. This could be, for example, public-facing GitHub repositories or even Amazon S3 buckets being used by developers to store code and project data. 

 

Unfortunately, these stored resources often contain hard-coded material such as user credentials, static API keys for public services storing sensitive financial information, and even AWS administration keys for user accounts. All of this creates rich pickings for cyber attackers, who are able to extract and use these credentials without encountering much in the way of a barrier.

 

The growing utilisation of such repositories by developers means that enterprises need to check their security protocols and ensure that DevOps teams are very clear on the ‘do’s and don’ts’.

 

Always know where your data is

Sounds simple right? But in most of the spillage cases encountered by CSIRT teams, not only are the enterprises unaware of the actions of their developers, but it also turns out that the public-facing storage and repositories used by the developer have usually not been authorised or documented.

 

These types of ‘shadow data’ scenarios create significant unmanaged risk, since enterprise security teams are unable to protect data that they don’t know exists.

 

While addressing the structure, governance and documentation around projects and data storage and providing general training for staff will certainly help, there are other actions enterprises can take to stay on top of where their data actually is.

 

These include using threat intelligence and scanning services to monitor and search common public locations for data that relates to their organisation.

 

Keep it private

While we’re not saying that GitHub or other code repositories are bad – far from it – staying secure means enterprises should always keep their code ‘under wraps’ until it’s safe to do otherwise.

 

For this reason, privacy should always be the default until everything being stored has been appropriately checked. In other words, unless the code is intended for public consumption, don’t make it public. And if it is intended for public consumption, don’t make it public until these due diligence checks have been completed.

 

The good news is that there are plenty of freely available tools out there – GitHub even has its own – that enterprises can use to check their repositories before and after publishing. Enterprises should therefore make use of these.

 

Make reporting easy

Enterprises will be missing a trick if they fail to harness the findings of specialist researchers and bug bounty teams. However, these valuable insights will be lost if external third parties aren’t provided with a clearly signposted route for reporting any issues they discover directly to the organisation.

 

To rectify this failure, enterprises can set up something as simple as a monitored inbox or a contact form on their website. They could also initiate a full-blown bug bounty programme that rewards ethical hackers and the wider research community when they successfully discover and report vulnerabilities.

 

Either way, it’s always far better to have a clear method for reporting issues than to find out about these issues post-breach when it’s far too late and the costly damage has already been done.

 

The reality is that the larger and more complex the organisation, the more data it will have, and this raises the stakes and likelihood that something can and will be exposed accidentally.

 

---

 

Andy Swift is Cyber Security Assurance Technical Director at Six Degrees

 

Main image courtesy of iStockPhoto.com and Just_Super