The 3rd party security nightmare

Posted on by Keith Marlow

It appears 3rd party integrations are the flavour of the month for security incidents at the moment. The latest being Ticketek Australia, where some of its customer may have had their personal details exposed, including names, date-of-birth and email; all of which was managed by a “reputable, global third-party supplier”. In other words, a global SaaS or infrastructure supplier dropped the security ball and hackers ran off with customer data as a result.

So why does this keep on happening? Well…

Hackers love 3rd parties…

This may come as a surprise to some, but hackers will always preferentially target 3rd party integrations and associated services, for the following reasons:

  • There is a security responsibility disconnect between those using the 3rd party and the 3rd party themselves. In other words, the integration between the customer and the 3rd party is often a point of security weaknesses as you have two parties responsible for each half of the integration. This makes it very likely that there is little meaningful security co-ordination between the two, so security coverage gaps can exist.
  • In a similar way, hackers have double the surface to probe and test; the security surface of the customer wrt to the 3rd party, and the security surface of the 3rd party wrt to the customer. They can try their hand at pretending to be the customer or the 3rd party, or play one off the other, etc. Many ways to skin the cat and find a weakness.
  • 3rd party providers often provide services to many customers and sometimes the separation between each customer is weak if none existent once you get into the systems. This means for the effort of hacking one customer you could end up hacking them all, extra bonus!
  • The 3rd party integration might allow the hacker to move into other customer services or points of integration with other 3rd parties. Especially if that 3rd party is providing authentication or Single Sign-On services – in essence an ‘open sesame’ moment for the hacker.

The above diagram shows these points clearly. In this case a Customer is using some 3rd party service that provides an API to integrate with their in-house system. As shown this provides at least 4 ways the hacker can interact with either system or either businesses staff to get access to the data. Note how the security surface (the blue box) for the Customer is distinct to that of the 3rd Party, neither has visibility or a tight security interaction with the other; they are, in essence, security black boxes to each other, and the hacker understands this and exploits it to the full.

What can you do to protect yourself?

Given the degree of integration modern businesses have with all sorts of cloud services it can often look impossible to improve your security position, but there are a few simple things you can do:

  • First off, identify what is your core data and where it exists. This is the data you never want a hacker to get their hands on, it’s the data life blood of your business.
  • For each system that contains core data, check the following:
    • Only you and no other systems can access that data. In other words are there restrictions in place to ensure your way of access to that data only works for you. It should be impossible to use corporate credentials on the public internet to access those systems. If this cannot be implemented, move to another provider who does, this is key.
    • All backups are stored encrypted, and the encryption key is NOT stored with the backups. May sound obvious, but do not assume all is right.
    • The data must be stored on an encrypted medium (encrypted file system).
    • Check that the provider has a security policy and people in their organisation with specific security responsibilities and the associated skills (both operational and technical).
  • Make sure your employees are only using SaaS products approved by IT, there should be no ‘Grey SaaS’ – as there is no corporate control over the data in such services. Also there is no control over how security is implemented in such services.
  • In a similar vein, before using a 3rd party, do some form of security review of the service and check it meets your minimum security requirements first.

You should also strongly consider if bringing a service back ‘in-house’ would be a good move, this guarantees that the way it is set up will always meet your security expectations and you are not forced to compromise and share that service with anyone else. This also means the uptime of that service is completely under your control. With the advent of private clouds and cost effective virtualisation services that can run on site, this gives businesses new options in combating security risks.

Now I know some people would consider it sacrilege to consider bringing services in-house, but there are many ways of doing this that do preserve availability and are not cost prohibitive. You can combine on-site with private cloud a lot easier (and at a lower cost point) these days than was possible a few years ago.

When you are using cloud services in any form, you must always remember you are renting services from a 3rd party in a highly shared environment, which may not fit your real and evolving business risk profile. Especially if you are using many cloud services, as each is a point of exposure and weakness that a hacker can exploit.

The cloud, like all services, has a risk/return curve, which can be quickly exceeded as your usage grows, especially when multiple services are being employed (in effect your efficiency of usage declines with size and complexity, this is how cloud providers make their money, as most customers do not track this).

It must always be remembered that when you use a 3rd party to provide services that are manipulating your key business data, you in effect entrusting your ‘crown jewels’ with a 3rd party via an often at-arms-length contractual relationship. They may even be in another country and operating under a completely different legal framework, which might void or seriously perturb your ability to obtain recompense when something does go wrong. Often contracts will contain extensive clauses limiting liability and compensation to an amount probably not worth the effort of claiming (compared to the damage caused). Ideally, all of this needs careful consideration prior to engaging with a 3rd party, its an important part of the risk management process that you need to undertake.

If you would like to learn more about how to improve data processing security, I suggest you read my book, available on Amazon.