Automation platforms help companies step up their marketing, but also come with risks. Companies can protect their clients' data with help from this guide.
Over the last weeks and months, a number of cryptocurrency companies, large and small, have fallen victim to data leaks from marketing service providers. The recent data breach suffered by HubSpot is a notable example.
As a result, the personal information of potentially millions of clients from affected companies was exposed. In some cases, this also included additional details about their accounts.
The impacted clients have now been identified as users of specific services, largely within the cryptocurrency and digital assets space, rendering them vulnerable to phishing attacks, social engineering and other types of attacks.
Ledn was not impacted by any of the recent data leaks, including the recent HubSpot incident.
Anton Livaja is the leader of Ledn's information security team.
This outcome is a result of going beyond standard security measures and tailoring company practices to our unique industry risks. We value our clients' data as we do our clients' assets and do everything we can to protect it.
Like other companies across many industries, Ledn uses HubSpot to manage our blog, emails and landing pages. HubSpot is a powerful tool that, if used correctly, can help businesses communicate with clients in an efficient way. Using automation platforms is a great way to level up your marketing, but it's important to always keep security top of mind. Luckily there are ways companies can minimize their risk when interacting with platforms like HubSpot.
In this piece, we break down the recent HubSpot incident and highlight the steps taken that resulted in Ledn's client data being protected. By utilizing these methods, other companies or entities can add extra layers to protect their client data from these types of vectors.
Our hope is that by openly showing our actions and learnings, we can help others avoid a similar incident in the future and enhance their security posture.
Let's start from the beginning.
HubSpot suffered a data breach because one of their employees was compromised. This allowed the adversary to use the compromised HubSpot account to access a number of client accounts, specifically targeting cryptocurrency companies.
The details around how the employee's account was compromised, and why there weren't additional controls in place to mitigate this scenario, are unclear. This is yet another attack in a series of crypto-focused data breaches including the one which Ledger experienced in 2020, which was also due to a HubSpot breach.
The public incident report from HubSpot can be found here.
From the report:
"Why did a HubSpot employee have access to HubSpot customer data?
"Some employees have access to HubSpot accounts. This allows employees such as account managers and support specialists to assist customers. In this case, a bad actor was able to compromise an employee account and make use of this access to export contact data from a small number of HubSpot accounts."
The primary reason Ledn was not impacted by the HubSpot breach was our obsession with protecting our client's data, and by extension, limiting our vendor's access to data.
When we decide to use external vendors, a large consideration for us is whether we have the ability to disable the vendor's employee access to our data. In the case of HubSpot, we always have the employee access disabled, and when necessary, enable it for the duration of a timeframe necessary for HubSpot staff to provide support, and disable it immediately afterwards -- which is simply applying the principle of least privilege.
At Ledn, we assume that when using third-party vendors, we take on risk that's impossible to fully quantify, and for that reason, extra precautions must be taken.
There is a tendency to have a greater degree of trust in larger companies because they presumably invest a lot into security. But while we may trust, we also need to verify; where we can't verify, we must apply all methods available to reduce the attack surface area.
Limiting a platform employee's access to our data is a practice we use wherever this feature is available, and is something we look for during our evaluation period of third-party vendors. Many companies provide this feature, and when they don't, we often request the vendor to add this feature as it is often relatively low effort to implement and improves the security posture of both parties.
Limiting third-party vendor access to end-user data is a best practice in a zero-trust environment.
Ultimately, insider threats are an important consideration for all companies and there should be a focus on eliminating single points of failure, so that even if someone is compromised, they are unable to cause damage. Helpful assumptions to build into your company's threat model are that at any company, at all times, at least one individual is coerced or compromised in every team, all machines are always compromised and your adversaries are well-funded and patient.
Always ensure you only share the data that absolutely needs to be shared with third-party vendors. Sharing personal information with a third-party should be carefully considered, and typically only done if absolutely necessary.
An example would be having to share data due to regulatory requirements. If you decide to share data with a third-party vendor, limit it to only the subset of data that's strictly required for the platform to be functional.
When third-party vendors are needed, due diligence should be executed using a "first principles" approach. This means carefully assessing the risks, considering the type of data the vendor will be interacting with and determining how they will be protecting it.
If the vendor's security fails to protect the required data, you should consider finding a different vendor, or using an alternative option such as building in-house, as we often do at Ledn.
It's important to have a strong culture that continually reminds employees that shadow IT, the practice of using technologies that haven't been vetted and on-boarded by the IT and information security departments, is a dangerous practice that can severely impact the overall security posture of the organization. It should be well understood by all teams that IT and information security must be instrumental in selecting new tools and organizational services.
Additionally, platforms often provide features that add additional layers of security, so it's useful to ask about what is available. In order to mitigate risk on the third-party vendor side, as well as internally, here is some advice regarding what to look for and ask about, and controls to implement:
There are several steps that can be taken to reduce the risk of attacks:
This is a guest post by Anton Livaja. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.