Our family office’s cyber threat model
In this post, Peter Burchhardt shares his thinking about the cyber threats facing our firm and our mitigation strategies for a few particularly relevant ones.
Why write about this topic now? In our discussions with other investment firms, cyber threat modelling has often emerged as an area where our peers are keen to learn from our experience.
Some real stories we’ve heard:
A victim paid the ransom to attackers in a ransomware attack.
An attacker tricked staff into buying gift cards.
We’ve heard several cases of firms being tricked into wiring money to the wrong recipients and losing those funds.
Our friends at Blackpanda regularly see dozens of cases like these. Blackpanda is a cyber insurance and incident response company that helps companies identify, contain, and investigate attacks. They remind us that these incidents don’t hit the news often, but they do happen.
We hope what we share here will help others reduce their risks. Depending on a firm’s in-house IT abilities, implementing some of these mitigations may be the job of an IT security service provider. Understanding the basics described here might help when it comes to selecting and managing a vendor.
Cyber threats facing our family office and other investment firms
Because of the nature of our firm, we will always face the following threats, no matter how well we mitigate them:
Theft of money, either with our participation (i.e., an attacker tricks us into wiring funds to the wrong recipient) or without our involvement (i.e., an attacker gains control of our bank accounts or tricks our banks).
Financial loss, such as via unauthorised trades that perform poorly, arising from an attacker or our own mistakes.
Ransomware, which is malicious software that blocks access to our data until a ransom is paid.
Destruction of data, whereby data becomes irretrievable either through our own mistakes or through the execution of malware.
Theft of information. We’re concerned about the theft of employee data (i.e., to defraud/impersonate them) and other sensitive data being leaked to embarrass us (i.e., our investment portfolio, research notes, process documentation, data that our partners and vendors trusted us to keep confidential, etc.).
Loss of access. We might get locked out of our systems if too many staff members forget our passwords, lose our YubiKeys or devices, or become unavailable.
Wasted time in recovering from an incident.
Our adversaries
Generally, we consider our adversaries to be criminals who either come across us opportunistically or who are specifically targeting family offices or investment firms.
Attack vectors and our mitigation strategies
Below are some ways in which we think that some of the threats we just mentioned might come about, and how we go about mitigating them.
Phishing emails
Attackers can use phishing emails to trick staff into disclosing their login credentials or downloading malware.
Using Okta SSO with YubiKeys — to neutralise credential phishing
Wherever a SaaS service supports it (and we try hard to only select services that do), we use single sign-on (SSO) via Okta. Then, within Okta, we require the use of YubiKeys. The YubiKey hardware only works when paired with the correct website; it won’t work with fake websites. That makes it one of the very few effective mitigations against phishing.
Other forms of multi-factor authentication (MFA) are still vulnerable to phishing. For example, when one-time passwords (OTP) are sent via SMS or email or shown in authenticator apps, the attacker can still ask the victim to enter their OTP into a fake website and then pass the correct values to the real website, thus gaining access to an account. Many MFA methods where one clicks in an app to authorise a login also have this problem.
Training staff to recognise phishing and not to open links in emails
Unfortunately, not all services support SSO, meaning we cannot use our YubiKeys and we still need to manage separate credentials for them and might be quite vulnerable to credential phishing.
We train our staff to:
Learn to recognise phishing. We recognise, however, that well-crafted phishing campaigns have a non-zero success rate against even the most well-trained and cautious among us.
Avoid clicking on login links in emails. Instead, we use 1Password or Okta to reach the correct websites for login. Even when Okta cannot log our staff in automatically, it can still ensure they go to the correct address.
Malware
Another attack vector: Bad actors trying to trick staff into installing malware.
Typically, malware can find its way onto workstations via:
Phishing emails, such as:
An email that appears to be from one of our software service providers invites a staff member to install a malicious app.
An email containing a disguised attachment. Our staff expects to open a PDF but actually installs a malicious application.
An email contains an attachment that exploits a code-execution security vulnerability in another app, such as for opening PDFs or Microsoft Office files. The act of opening the file allows malware to install itself on the device.
Web browsers. For example, a staff member browses to a website that’s been compromised by a hacker to serve malicious content that exploits an unpatched code-execution vulnerability in the web browser.
Other apps with security vulnerabilities.
The following are some strategies for protecting against malware.
Configuring staff workstations defensively
Defensively configuring staff workstations can make it more difficult for malware to take hold. Machines can be set to:
Enforce fast automatic software updates of all apps and the operating system
Limit the execution of macros in Excel
Remove admin access from workstations so staff members cannot install software, and only company-approved software can run on their machines
And many more
Opening attachments in the cloud
As much as possible, we try to open email attachments in Google Drive, through Gmail’s preview feature, or elsewhere in the cloud where malicious code cannot execute. We consider opening anything on a local workstation quite dangerous.
Using anti-virus software
Anti-virus software on staff workstations can block the execution of some known malware.
Monitoring usage logs on workstations
While we can make it slightly harder for malware to take hold, we can’t rule out the occasional presence of malware. Therefore, we also need abilities to detect it quickly. Software on our workstations can collect usage data and stream it to a central database, where a combination of robots and humans can detect patterns indicating the presence of malware.
The team monitoring such logs is called a security operations centre (SOC). The SOC uses security information and event management (SIEM) technology to detect threats. The SIEM and SOC also collect and analyse data from other log streams (e.g., logs generated by cloud services), providing overwatch for the entire organisation.
Collecting such data obviously raises questions about employee privacy. That’s a topic for another post. We have an internal policy describing what levels of privacy our staff can expect, and we make sure we operate consistently with that policy. In general, the balance is quite reasonable: the data needed to detect malware are relatively benign when workstations are only used for work purposes.
Keeping browsers up to date
Because malware can sometimes take hold of a machine simply when a user visits a compromised website, keeping browsers up to date is critical. All major browsers fix several such bugs each year, so we are careful not to ignore these browser update notifications.
Using isolated ephemeral environments for “dangerous” browsing
Ideally, we want to restrict relatively risky web browsing (such as to sites serving ads or user-generated content) to isolated ephemeral environments that are “OK to be hacked.” We’ve used Silo Browser, AWS Workspaces, and locally run virtual machines (VMs). This can involve a tradeoff between risk-levels and productivity.
More on our “OK to be hacked” philosophy below.
Being tricked into wiring money to the wrong account
There are many ways in which this might play out, for example:
We fall for a well-constructed phishing email.
A vendor is compromised (e.g., a fund we’ve invested in), and attackers send us capital-call notices from the fund’s IT systems but with incorrect bank account information.
Our own IT is compromised, and the attacker tampers with the contents of an email or a PDF.
The challenge is twofold:
We must ascertain a recipient’s correct bank information.
And then ensure that we only ever wire to those verified destinations.
Our solution involves several steps:
Step 1: Verify bank information over multiple communication channels
First, we verify the banking information with multiple people over multiple communication channels, also taking into account that people’s voices can be faked convincingly.
Step 2: Save verified bank account details in 1Password
Then we save the verified bank information in 1Password. Doing so makes the details relatively difficult for attackers to modify and very difficult for them to hide their tracks if they could modify them.
1Password helps in the following ways:
1Password keeps audit logs so the SOC (security operations centre) can alert when bank account details are changed.
The person in charge of verifying a bank transaction can also see the change history in the 1Password interface.
Step 3: When wiring funds: only send to the bank details stored in 1Password
The details depend on the bank, but in general, we make use of the “stored recipients” features in the banks’ portals, and for each transfer again double-check that the recipient matches what’s stored in 1Password.
We keep clear documentation about our wire-transfer process to make it easy to follow and difficult to deviate from. We’ve also built a culture of strictly and pedantically following this process end to end.
Strategy: Make things “difficult to hack” and also “OK to be hacked”
It’s impractical to rule out malware taking hold in any device and humans making mistakes. Since we can’t prevent problems entirely, we must be ready for them to happen occasionally and only create acceptably low damage.
Our general strategy, therefore, combines “making things difficult to hack” with “making things not a big deal if they are hacked”. The latter involves minimising what an attacker can do with any one compromised asset and, through early detection and fast response, minimising the amount of time during which they can exercise control.
Final thoughts
We could go into more depth with these topics, but for now, we hope this overview is already useful food for thought for some readers.
If you’re interested in reading more about the tools in our arsenal (like 1Password, Okta, YubiKeys, and Google Workspace), please check out our blog post: Our single family office tech stack.
We’ll keep publishing content, so please follow us on LinkedIn and subscribe to our newsletter for updates.
