CS4NSP Episode 6: How to establish trust when connecting systems together

We connect systems together to realise value that is greater than the sum of the parts. But each integration introduces additional risk. How can you manage that?

Brief at the Start

Go straight to the full length version

Every link in a chain can represent a vulnerability. When you connect systems together to can deliver greater benefits, but it only takes one weak link to place your email, financial data or other information at risk.

Businesses try to avoid stovepipes, and connecting or integrating different systems is a great way to break them down. However, this also increases risk because a bad actor can now look for vulnerabilities in more than one system in order to get to the underlying assets.

The connection may be obvious – connecting your CRM to your email, contacts and calendar. It may be emerging – making use of new Generative AI tools to drive greater productivity. Or it may be run of the mill – exchanging emails with a conventional supplier. In each case the benefits of establishing the connection need to be balanced against the degree to which you can trust the additional entity and the risk that it presents.

Get the Full Version

Why are systems connected together and what are the risks?

Without even thinking about it we naturally want to connect things up and automate them. We get frustrated when it’s not possible. For example, most people want to connect their phones to their cars so that they can play music and make calls. And why shouldn’t we? What are the risks?

In this example, you are telling your phone to trust the car, so that the car is able to access your contacts. The more advanced in-car systems will increase the extent of this integration so that they can access features such as the navigation app, messaging systems, and audio streaming services. This makes a lot more of your information available to the car. And these days, the car will have a lot of compute power in it and probably a digital connection back to the manufacturer.

So what could possibly go wrong?

Well at an extreme, the manufacturer might be malicious or might be under the control of a malign nation state. Even if the vehicle manufacturer is trustworthy, the thousands of digital systems onboard will have been procured from across their supply chain. It only takes one bad apple supplying a smart component for the entire system of systems to be at risk. But even if you have complete confidence in the original manufacturer and their management of risk in the supply chain, there is always the risk that someone has hacked a vulnerability in a part of the system. They might do this over the air; or may have had direct physical access to the car.

Any of these scenarios could enable the simple act of plugging your phone into the car you are driving to be the precursor to information being stolen from, or malware being installed on the phone.

Perhaps this sounds a bit too much like a James Bond script. But in certain quarters the risk is considered high enough to restrict cars from sensitive areas and advise staff not to connect their phones¹. I’m not suggesting in this article that everyone should stop connecting their phone to their car. But it is an illustration of the risks that arise from every integration, and the questions about trust that should be considered.

Assessing Trust

To assess the risk you first need to understand the extent to which you can trust the new system or entity.

If it is a solution that is within your control then you follow the steps described in Chapters 3, 4 and 5. Does the new system have controls over the People using it, the Devices they will be using to access it, and its own Environment, that are proportionate to the asset(s) that it is going access.

If it is outside your control then you need to conduct adequate due diligence to assure yourself that the responsible supplier applies adequate and equivalent controls.

To illustrate this further this article explores a number of examples, the risks that they present, and the controls that can be put in place to reduce the risk where the benefits don’t warrant it. You will see from the examples that they can vary significantly, from deep technical integrations to more conventional cases where you are just interacting digitally with a supplier.

Note: These examples are illustrative, and the observations in this article shouldn’t be taken as explicit recommendations.

Example 1 – Connecting your CRM up to email, calendar and contacts

Most businesses have some form of a Customer Relationship Management (CRM) application or service. It may be an off-the-shelf service like Hubspot or a highly customised application built on Salesforce or Microsoft Dynamics 365. The original intent may start out as a simple directory to hold details of customers. But it quickly exposes more opportunities and potential benefits, which in turn leads to the solution holding increasing quantities of sensitive information.

By keeping track of emails being sent to and received from customers the CRM can measure the effectiveness of marketing campaigns, and track active customer engagement. Access to address books ensure it is kept up to date more easily. Progress through the sales pipeline can be tracked more accurately and elements of the workflow automated if calendars are accessible.

Figure 1 – An example of the permissions requested by a CRM to integrate with Microsoft 365

If you want to make use of these features in your CRM you will be giving it access to all of your email, contacts and calendars. Not just the information related to customers, but absolutely everything that you have in your account. This requires you to balance the benefits delivered against the increased risk.

The change will introduce additional risks to the information held in your email, contacts and calendars, such as the following:

The risk that a malicious party is able to log into a user’s CRM account and access the contacts’ information it leading to regulatory fines, reputational damage and potential legal action from parties involved
The risk that a malicious party is able to log into a user’s CRM account and send email on their behalf leading to fraud in the company’s name, reputational damage and potential legal action from parties involved
The risk that a malicious party is able to log into a user’s CRM account and conduct a marketing campaign in the company’s name promoting offensive, illegal or competitor products leading to reputational damage and potential legal action
The risk that a vulnerability in the CRM enables a malicious party to gain control and in turn gain access to all contacts, emails and calendars of all connected users

The first three of these risks relate to identity security, as discussed in Chapter 3. An easy way to address this, if the CRM allows it, is to introduce Single Sign-On (SSO) so that users log in through their main account (e.g. Microsoft 365 / Entra ID). This way you avoid needing to ensure the CRM has all of the controls in place to prevent easy passwords and enforce Multi-Factor Authentication. It also means that when an employee leaves you only have one place to disable their account to prevent them retaining access to other services, such as this CRM.

Risk 4 demands a degree of due diligence into the security of the CRM’s environment as described in Chapter 5. Not only do you need to be satisfied that the environment is secure but also that the supplier can be trusted to develop and maintain secure code. In many situations there will be limits to the assurances you can achieve, leading to some uncertainty and material residual risk to your data.

One very easy way to reduce this residual risk without significantly impacting on benefits is to limit the scope of users who can connect their CRM accounts to their business information accounts. The marketing and sales teams will gain the most benefit from the integration. Other stakeholders may benefit from access to the CRM and the ability to view the reporting, without needing full integration.

For example, the COO may have interest in the CRM reporting but won’t be involved in sales or marketing activities at scale. The COO is also likely to have far more sensitive information in their email accounts – potentially information that is share-price sensitive and protected under legal privilege. By restricting full integration to only the marketing and sales groups you can gain most of the benefits while reducing some of the more extreme risk.

Example 1a – Apply caution to single sign-on (SSO) approvals

As described in Example 1 above, there are significant benefits in using the main business account, such as Microsoft 365 or Google Workspace, to log users into secondary services has significant benefit. You can invest your effort once in securing the main business identity services, enforcing strong passwords and MFA, and applying controls to guard against the impossible journey². You can also disable an account in one place and immediately deny the user access to any of the other services.

So “Log in with [Google | Microsoft | Apple | Etc]” is not just convenient for the user, it can improve the security of the business.

But when this is approved, it builds a connection between the third-party application and the main business service. And this connection will come with a set of permissions that determine what the third party application is able to do. It might just be the ability for users to sign in, and for the application to get some basic information about them. But Example 1 describes giving an application full read and write access to all of the user’s email, contacts and calendars, and the an example of these permissions can be seen in Figure 1. It is essential that these permissions are checked before the connection is approved. You can find greater detail in an article on this topic³.

Example 2 – Those useful browser extensions

An increasing amount of our business is conduct through our web browser. SaaS applications, like the CRM discussed in Example 1, are only accessible that way. Other applications frequently have web based options if the full-fat alternative isn’t installed on your computer, such as the office applications in Microsoft 365.

Unfortunately we also use the browser for a wealth of other, less work related (and, at times, possibly more dubious) activities. This is why the browser is one most frequent entry points for attacks.

We all know that we shouldn’t go to questionable websites (and most of us abide by this). But we also like gadgets that make life easier or more convenient. In a browser we can install extensions to fulfil these needs⁴. But they generally don’t require any special permissions and if you aren’t careful you will be giving the little app (and its publisher) complete access to everything that is going on in the browser.

Browser extension permissions sometimes give dangerous powers — Figure 2 – Some browser extensions can ask for powerfull permissions that can be extremely dangerous

For example, there are extensions that make it easier to adjust the playback speed of YouTube videos. This is clearly in demand because I found 39 different extensions when searching for ‘YouTube Playback Speed Control’. I chose one of the more popular ones (4,800 reviews with a 5⭐ rating) and found that it was demanding to be able “Read and change all your data on all websites”. Now the publisher may well be completely honest. The extension may well only use these permissions to speed up or slow down a YouTube video at your beck and call. But it may not be, and there are few ways to confirm it. That permission does what it says – the extension will be able to read every website you visit, every keystroke you type, and modify websites to inject malicious code that might download an attractive (but dangerous) file for you to open.

You can read an article we wrote on this topic alone⁵. To be safe you should prevent (or at least prohibit) users from installing anything other than an approved list of extensions in the browser that they use for work.

Example 3 – Adopting AI tools to help our research and content drafting

There are few products being sold these days that don’t claim to have AI capabilities. Its ability to do tasks far faster, and therefore cheaper, than human beings makes it a very attractive proposition. There are a wide variety of risks associated with current Generative AI capabilities at the time of writing. Most are beyond the scope of this series, but you can read a detailed article we wrote about how to balance risk and opportunity to deliver net benefits⁶.

In this context though, we need to decide whether it is wise to use a cloud (or SaaS) based AI tool to help our staff with research and content drafting. Factors that we need to consider include:

Supplier. Essentially, do we have reason to trust this vendor and its technology with our data? This is a similar question we need to consider for any other supplier that we hand information over to.
Sensitivity of Our Information. How sensitive will the information that we upload to the tool be, and how can we control it so that only the intended information is handed over? If we give the tool access to all of our information then it will not understand the context of a particular document; how can we be sure that it doesn’t expose information from one client when answering a question related to another client?
Model Training Data. Do we have assurances that our data will not be used to train the model except for the services exclusively delivered to us? If not there is the risk that our confidential information will be exposed to other customers of the service. Do we have assurances that the model has only been trained on information that it has authority to access under copyright law? If not there is the risk (not yet proven in case law) that output used by us might be found in breach of copyright law.

Example 4 – Conventional Supplier

Every business will have a multitude of suppliers where the services they deliver don’t in themselves involve an explicit connection between their systems and ours. However, they still come with risks related to their approach to cyber security. The following are a selection of the more common ones:

The risk that a malicious party gains access to the supplier’s systems and in turn accesses confidential information that we have handed over leading to economic damages and potentially breach of confidential agreements between us and our clients.
The risk that a malicious party gains access to the supplier’s email and uses this to communicate with us impersonating the supplier and instructing changes to payment details leading to financial loss.
The risk that a malicious party gains access to the supplier’s email and uses this to send malware that is more likely to be trusted due to the existing trusted relationship leading to a breach of our own systems with significant consequential damage.

Even when you aren’t procuring digital products or services from a supplier you will still be exposed to some level of risk related to the suppliers own cyber security.

Summary

It is natural to seek efficiencies and benefits from the connections that can be made between systems and suppliers. This is how we deliver value that is greater than the sum of the parts. But every connection introduces a new chink in the armour. And the more interconnected everything becomes the more systemic the risk will be.

You can assess the overall risk that an asset is exposed to by considering each system or entity in its own right. When the benefits of a new connection are low and the risks are high you should ask yourself why the integration makes business sense.

And also remember that if the system you are connecting has equivalent security to the original system, the risk has still increased because the surface that a bad actor can attack has increased. Every connection is a link in the chain, and the more links the greater the likelihood that one of them will be successfully attacked.