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.
What Happened?
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.”
How Was Ledn Able To Protect Itself?
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.
How Else Can Companies Protect Client Data When Using Third-Party Service Providers?
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:
- Directly disabling/restricting the vendor’s employee access to data.
- Ask the third-party vendor what kind of internal controls they have when it comes to limiting access to client data. Things to look for are:
- Use of hardware tokens (such as Yubikey, Titan Security Key or other smart-card device or personal hardware security module, or HSM device).
- Mandates for use of Fast Identity Online, or FIDO authentication protocols.
- Dual control or n-of-m authentication to prevent individuals from having sensitive, privileged access.
- What their access recovery process looks like; if it’s not rigorous enough, that can be used to circumvent their authentication mechanisms.
- Whether they have a “production engineering” practice, where engineers who access critical infrastructure use hardened machines with limited network access to complete any tasks that require interacting with production systems.
- Certificate-based authentication: using cryptographic certificates limits the access to an asset to only those who hold the certificate. You can think of it as a special file that binds access only to the devices which hold legitimate certificates. It’s recommended to use certificate-based authentication for critical services, such as a single sign-on (SSO) provider or for gating access to important services using mutual transport layer security (mTLS). You can learn more about certificate-based authentication here.
- IP safelisting: services frequently offer the ability to limit access to only specific IP addresses. To take advantage of this you need a static IP: one way to achieve this for a group of users is by using a virtual private network, a VPN.
- Using your own keys for encryption. One can often use their own keys to encrypt data that is stored with a third-party vendor. This is an additional assurance which helps reduce risk in the case they are compromised, because the keys that are used to decrypt the data are stored with you — outside of their system — and you have the ability to revoke access to them in the case of an emergency.
- The type of multi-factor authentication (MFA) they support for users of their service; asymmetric cryptography-based authentication is the best we currently have available. It’s akin to using a hardware wallet for cryptocurrency. WebAuthn/Universal 2nd Factor is preferred; Yubikey and Titan Security Key are some popular devices that support the FIDO family of authentication protocols. If you don’t use this technology yet and care about security, we highly recommend getting one. Ledn will be rolling out support for this type of MFA in the near future.
- Single sign-on support: SSO technology allows one to impose controls across many services from one centralized point. It’s important to be careful and configure SSO properly as it can be a large single point of failure otherwise. As previously mentioned, using certificate-based authentication as an additional layer of gating access to SSO is recommended, preferably in a mTLS setup.
- Password management: using a password manager is a basic security best practice. The idea is to use a strong master passphrase (at least 16 characters in length), and all passwords stored in the password manager should be very long and complex (42 characters or more, and generated using the typically available built-in password manager). The rule of thumb is: “If you remember all of your passwords, you’re doing it wrong.”
A Service Provider Leaked My Personal Data During The Recent HubSpot Incident. What Can I Do?
There are several steps that can be taken to reduce the risk of attacks:
- Ensure you have 2-factor authentication on every account that has the ability to process financial transactions. It is good practice to use a security token like Yubikey or authenticator-based 2FA (also known as TOTP) over SMS as your 2FA method. Since you’ve made it this far, here is a little pre-announcement for you: Ledn will be releasing WebAuthn support this quarter.
- Second, activate anti-phishing phrases for platform emails on every service that allows it. You can learn more about anti-phishing phrases here. Use something that would be hard to guess. Adversaries will often build a profile on their target to figure out things they like or talk about via social media to allow them to build more effective and sophisticated attacks against their target.
- Activate safelists on every service with the ability to process a financial transaction. This will restrict withdrawals from your accounts to previously specified addresses. A proper implementation of this feature will include a “cooldown” period after adding the address within which the address can’t be sent to, typically for 24-48 hours, which gives you more time to react.
- Contact your service provider to ensure that they have now limited third-party vendors from accessing client data unless for the time windows that are absolutely necessary.
- An added recommendation is to use a unique email for each cryptocurrency platform you use, as this makes it much more difficult to target you across different platforms in case one is compromised. Treat your username/email similar to a password for sensitive services.
- Listen to episode 112 of Darknet Diaries. It will give you a great insight into how adversaries in the cryptocurrency industry think. Start at 45 minutes if you want the TL;DR.
- Additionally, you can use this excellent resource, which has an extensive list of recommendations on how to improve different aspects of your security and privacy posture: https://github.com/Lissy93/personal-security-checklist
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.
Ecosystem
Research
News Network
About