Managing the risk of cloud-enabled products

Organisations are increasingly deploying software to both servers and end user devices that make use of cloud services. This may be an explicitly stated feature of the product (such as cloud storage for data backup or synchronisation between devices), an implicit function (such as a line-of-business application reporting usage statistics to the developer), or an anti-malware product using a cloud service to analyse suspicious files. It’s easy to overlook the nature of these cloud interactions, and the security implications. 

This guidance helps organisations to:

• understand how products interact with cloud services
• understand the security implications for your systems
• decide on approaches to help manage the risks

We’ve also included an example that demonstrates how you can apply this guidance to a common product class (in this case, antivirus software).

Understanding how products interact with cloud services

You should understand if and how your deployed products interact with cloud services – almost all of them will in some way. This begins with the operating system itself, as well as the products installed on it.

Regardless of your source of information, the key questions you should seek to answer are:

1. What information does this product collect from my systems on a regular basis?
2. What information is the product capable of collecting from my systems?
3. What changes is this product able to make to my systems if commanded to by the cloud service?
4. What controls do I have over what the product can do regarding 1-3 above?

Three sources of information you may wish to consider are given below.

1. Vendor statements (including terms and conditions or privacy policies)

Reputable product suppliers will generally be happy to provide you with information on how their products interact with internet-based services outside of your direct control, and any third party services they make use of. They should make clear how and when data might be collected from your systems, and what the control mechanisms are for such interactions. NCSC frameworks such as the 14 Cloud Security Principles can then help inform you of risks you may need to be aware of.

You should pay attention to contractual terms and agreements you are entering into with the vendor. These agreements can grant potentially far-reaching permissions to the vendor, and give them scope to do whatever they wish to your systems and data in the future.
 

2. Independent research

Well-known products may have been tested by third party security researchers to investigate the nature of their interaction with cloud services. This can provide useful additional information to validate claims by vendors. This research can also be useful in exposing flaws in data protection mechanisms (such as ineffective cryptographic protection, or a protocol which allows for more information to be collected from your systems than the vendor may have intended). You should also:

• check whether the research is still current (as products can change quickly), and how thoroughly the product was examined
• remember that not all reviews for products are independent, so use multiple sources for a better understanding of the product
• note that products with weaknesses identified by independent researchers do not necessarily make the product any less secure than other similar products
• check if the product vendor responds positively to issues identified in their product, as this can identify if the vendor has a mature attitude towards resolving weaknesses in their product

3. Your own investigations

Performing your own tests on products can help quickly identify information flows that you weren’t aware of, and which may need more detailed investigation, such as discussion with the vendor. As a simple first step, consider configuring the product in a test environment, and then monitoring the traffic flows to and from the product’s servers. Tools like Wireshark can help with this.

Testing a product, the configuration and the deployment environment will provide a more representative sample of data flows. However, you should note:

• You might not see all relevant information flows – some may be triggered by sporadic events (such as a malware heuristic being triggered, or an update being pushed by a vendor).
• The data flow may be encrypted so you cannot see what data is being transferred, only that a transfer is occurring. Depending on circumstances, this can still be useful. For example, it can prove that data is being exchanged with a cloud service, and correlation with other information may allow you to infer what is happening. Depending on how the encryption is performed, it may be possible to install your own root certificate onto the end user device being tested, and inspect the traffic.
• Without comprehensive analysis, testing only reveals what is regularly happening, not what is possible. For example, an anti-malware product might open a communications channel with a cloud service for the purpose of sending extra information for detailed analysis of suspicious files. However, the mechanism used might allow the cloud service to request additional information from the product, such as reading the contents of arbitrary files on the machine. 

Understanding the security implications for your systems

The fact that a product exchanges information with a cloud service (or provides an ability for the service to interact with the product) does not necessary mean it is a significant risk. Your assessment of the risk must consider:

• where the product is used in your organisation
• what you have discovered about its capabilities
• what this means for your information security

What information can the product access?

Think about where you will be deploying this product, and the amount of information that it is therefore able to access. A product installed at a network choke-point, or on a core server, will naturally have much greater potential access to your information than a product installed in a sandbox on a small number of end user devices. A scanning engine that runs with high privilege on an end user device can access any files that any user of that device can access.

What do you know about the cloud service(s) involved?

The fact that a cloud service is involved isn’t inherently good or bad; you should use the NCSC’s Cloud Security Principles to consider whether the service in question is an appropriate place for your information to be stored and processed. This will depend heavily on what the product can do, and the information that it collects and sends to the service. Your requirements for a service that processes small amounts of usage information will naturally be lower than for a service that has frequent and privileged control over deployed products.

It is important to understand the privilege level the software on the end user device runs at. Some applications which use cloud services, such as AV products, require very high privileges to allow them the access they require. This level of privilege means that the cloud service provider will have significant control over end user devices. You should also consider the security heritage of the product developer, as any vulnerabilities in their product could allow an attacker to gain access to any data the product can access.

Depending on the data that the service is collecting and where that data is being stored, protection of the data may be governed by different legal jurisdictions. For this reason, it is important to know what data is being collected and where it is being stored to ensure continuous compliance with all applicable legal requirements. Inappropriate protection of user data could result in legal and regulatory sanction, or reputational damage.

Managing the risks of cloud interactions

With an understanding of what a product and service are doing with your information (and what data assets are accessible to them) you can take any necessary steps to minimise the potential harm to your organisation. This may include some (or all) of the following:

1. Use in-built controls to control data flow and remote access

Most well-designed products and services include controls that enable system administrators to tailor the amount of information that is shared with cloud services, and the level of intrusion, notification, and logging that remote management protocols include. You should consider whether integration with remote services is appropriate, given what you know about the cloud services in question, and adjust controls as appropriate. 

The effectiveness of some products (in particular anti-malware products) depends on real-time information sharing and cloud-based analytics. Disabling or restricting such features can dramatically reduce the protection they provide. A product configured in an ineffective mode may provide a false sense of security.

2. Use network-level controls to manage data flows with services

If a product does not contain sufficient management controls to restrict the information it exchanges with remote services, it may be possible to use network-level flow controls instead. Such controls (such as blocking end user devices from talking directly to particular vendor services) generally lack granularity, and can cause products to malfunction. For example, if the product believes it is connected to the internet but cannot communicate with an expected service. Maintaining such rules requires a long-term commitment as they need to stay synchronised with how products and services interact.

3. Use network monitoring to maintain awareness 

As products and services evolve, the nature of their communication flows is likely to change too. A vendor may spot an opportunity to perform additional analytics in the cloud, or migrate processing to a different service to improve your user experience. Ensuring you have sufficient monitoring of your network (and understand what normal data flows between products and their remote services look like) means that you are more likely to notice when things change, and can investigate any consequences. 

4. Consider contractual controls

Before agreeing to procure a product which is backed by a remote service, you should consider whether the contractual agreement you have with the vendor provides suitable clarity over the remote service aspect. 

5. Enable automatic updates

Many products include automatic update mechanisms to help you keep the latest version of the product deployed. These mechanisms are extremely helpful in avoiding the need to manually apply patches to a large enterprise, and as a general technique, provide a security benefit in helping reduce the number of vulnerable products in operation. However, the ability for a vendor to arbitrarily replace executable files on your deployed devices needs to be considered as it may lead to incompatible software.

6. Consider data sharing mechanisms

Many anti-malware products use cloud services to provide more detailed analysis of suspected malware samples. They also use such services for reputation purposes. For example, if many organisations have executed a file with a particular set of metadata and no ill-effects have been reported, then the product will determine the file is likely to be trustworthy, compared to a file no one has executed before.

By contributing data to such services, your organisation benefits from the actions of others. You should consider whether the information that is shared with such a service is genuinely sensitive (often it will be just executable files or cryptographic hashes of executable files) and if possible look to benefit from the wider protection. This type of data may already be leaving your network if you have deployed certain types of network monitoring solutions.
 

7. Review service periodically

Be sure to regularly review the conclusions you have made about a product and associated services, and consider new modes of operation, additional controls offered, and extra functionality that may change your approach. 

Example: applying mitigations to antivirus software

Modern antivirus software tends to feature cloud-based technologies to maximise their effectiveness. For example, many products use cloud technologies to secure endpoints based on data obtained by various sources, such as their end point protection software installations worldwide. This allows for more accurate and reactive detection; in the case of a widespread attack similar to WannaCry, it would be quicker to update the heuristics and detection methods used within a cloud–based antivirus solution than to push updates to all endpoints.

However, these solutions are also good examples of the need to consider the implications discussed above. For example:

• What information can the product access?
  Antivirus software will generally be able to access every file on a system and perform monitoring of traffic, including encrypted traffic if it installs its own certificate. The product needs to have this visibility over the server or endpoint to be able to check for signatures (behaviours, content or metadata used to identify malware) or perform behavioural monitoring. Depending on how it functions, a subset of this data will be transmitted to the cloud to either improve detection rates, or to perform deeper analysis on flagged information.

• What do you know about the cloud service(s) involved?
  Any suspicious files are likely to be transmitted to the vendor for further analysis, this can be done manually by an analyst or through further testing (for example using sandboxes). It is important to recognise that this is a risk: that data from your systems may be transmitted into the jurisdiction and environment that the software vendor operates in; and that the signatures, software updates, and controls within the product may be influenced by authorities if the local law allows it. However, this can allow for more efficient detection and can lead to identification of new or rarely seen malware. Antivirus products are also required to run with high-privileges on systems, this allows them to access all files and perform functions such as traffic monitoring. Some products will even install their own certificates onto an endpoint, allowing them to access encrypted traffic. Data obtained from these processes may also be sent to the cloud in some form – but are vital to the functionality of the software, they need to be able to have visibility over the server or endpoint to be able to detect signaturable activity. It’s important to realise that this high level of privilege means that if the cloud-service or product itself is compromised, then an attacker would possess that same level of privilege.

For risk management purposes, the following are specific considerations for this class of product.

1. Use in-built controls to control data flow and remote access: Cloud-based antivirus relies on having access to data on a system as well as having high-privilege. It is important to make sure that limiting this is carefully considered as otherwise the benefits of the product may not be as advertised.

2. Use network-level controls to manage data flows with services: It may be difficult to determine what endpoints are used within a service if an attempt is made to block transmission of data collected from the system that may prevent the product from receiving updates (and, in the worst case, being able to perform any detection). For example, it may cease to analyse executable files if it can’t reach the cloud-service to transmit findings.

3. Use network monitoring to maintain awareness: As threats evolve, vendors may attempt to use new methods and approaches to perform detection. By monitoring traffic from the product, this can be identified quickly and used to evaluate the risks around continued usage within your environment.

4. Consider contractual controls: Given the high-privilege levels and visibility that these products have, it is important to understand whether the contract is fully clear as to how that information is handled.

5. Enable automatic updates: You should first make sure that there is a robust update mechanism in place for the antivirus software. If the product is compromised then the risk to your organisation could be huge. Similarly, you should make sure that automated update mechanisms are taken advantage of so that the impact of a weakness within the product is limited.

6. Consider data sharing mechanisms: Most data transmitted will not contain sensitive information, for example, hashes of files on your endpoints or which executables are commonly seen. This data has a substantial impact on the quality of the product, by providing it you can help to make sure that malware is detected quickly in both your organisation and within others. If you already are performing network monitoring through a cloud-service then that will likely be transmitting comparable data to what these products will send to the cloud.

7. Review service periodically: Threats are constantly evolving. It may be that the product you choose no longer offers your organisation the best protection or that your considerations around risk have changed. Given what has been mentioned previously in this guidance about this class of product, the impact of selecting the right solution for your organisation is substantial and it is important that this is regularly considered.

Source: NCSC