Posted on 2020-05-13 by Matt Strahan in Business Security
How many organisations have access to your customer data?
As software-as-a-service and cloud-based environments become more standard within organisations, this question becomes harder to answer. In the modern interconnected security world, though, it’s a question that needs to be answered for all organisations.
Data spreads out everywhere. Most organisations they don’t really know who has access to their data. If I ask for a list of suppliers with access to sensitive information, the list they provide me is usually not complete. I usually have to provide prompts to help the organisation brainstorm for potential access:
- Do you have any managed services providers?
- Who does your finances and accounts?
- Who does your auditing?
- Who provides legal services?
- Do you have any marketing providers?
- Do you have any third party sales support?
- Do you have any vendor support accounts?
- Do you have any hosting providers?
- Do you have any business analysts?
- Do you use any Software-as-a-Service providers?
- Do you have any contractors or third parties in your service delivery?
- And so on…
All these organisations could either hold customer data, have privileged access to customer data, or have on-demand access to customer data. A breach at one of these companies could result in your customers’ data being exposed, and since your customers deal with you it’ll be you who is blamed. It becomes vital that you ensure these organisations are acting as custodians of your data and keeping it safe.
In our compliance and security strategy services we’ll end up having a rather large brainstorming session with the main stakeholders of the business, and from this we end up with a number of suppliers. This can be fed into a supplier assessment or incorporate part of a risk assessment on your supplier risk.
It’s easy to be comfortable after that meeting and think “job’s done, we’ve gotten all the suppliers together”. Are we really done though?
Let’s say we end up with 15 suppliers that could have access to your customer data (a figure that’s actually on the low side). Does that answer the question at the start? Does that mean that 16 organisations (15 suppliers plus your own organisation) have access to your customer data?
The suppliers’ suppliers
What would happen if I went into one of your suppliers and had a similar brainstorming session, what would be their result? Would they say “no we have no suppliers who have access to our customer data”? Would they say “Nope, it’s just us!”
More likely, they’ll have 15 suppliers of their own. And each one of those 15 suppliers will have another 15 suppliers you might have to worry about!
After all this filters down your organisation’s security relies not just on your security, but the security of your suppliers, and the security of your suppliers’ suppliers, and the security of your suppliers’ suppliers’ suppliers. The number of organisations with access to your data starts to multiply out exponentially. Your managed service provider might have hosting providers who use a physical security provider who might just have access to your data or be able to affect your security.
It’s for this reason I always felt that the term “supply chain” is a bit misleading. The supply chain acts more like a supply tree, and that’s the way it should be TREEted (sorry everyone but Alexei insisted on that pun).
Trimming the supply tree
This becomes a potentially overwhelming issue. For example, even if you didn’t use Wipro as a managed service provider during their 2019 hack, if one of your suppliers used Wipro then you could still be under risk. What’s more, even though the security of that organisation put yours under risk, you don’t have a direct relationship with them so you might not even be notified that your data was part of the compromise.
An effective example of managing the supply tree has been the PCI DSS. Although you don’t normally link in your mind “PCI DSS” and “supply chain management”, that is exactly the way it works. The PCI DSS is a contractually enforced standard that has as one of its conditions that the organisation’s suppliers must also comply with the PCI DSS. The standard then cascades down so that all organisations that handle credit card data in any way must be compliant otherwise they’ll be dropped as a supplier.
The credit card companies understand that their risk doesn’t just spread to the organisations that they have a direct contractual relationship with (the banks and direct channel merchants). Instead, those organisations have suppliers, and suppliers of suppliers, and suppliers of suppliers of suppliers.
Although these kinds of clauses are common for the handling of classified information with potential legal consequences, the PCI DSS seems to be rather unique in the corporate world as far as I’m aware. I feel it may be something that becomes more common as the problem comes to a head – you may have to be audited against ISO27001 or NIST for example. Most organisations, though, do not have the market power or push of the credit card companies so they cannot use this type of clause.
A contract clause that is a bit more practical, though, is to build in guidelines around the security of your data. When can your data be used with third parties? What due diligence must be done in the selection of suppliers? What happens in the event of a breach? All of these things can be negotiated.
The modern interconnected world means that you don’t just have to make sure you’re secure. Giving data to any third party should be done with absolute caution.
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn