Design Pattern: Safely Exporting Data
How to implement a secure end-to-end data export solution
Most organisations need to communicate externally, passing data across organisational boundaries. However, enabling this process, without also risking the leak of sensitive data, can be difficult.
This guidance provides an architecture pattern which will help you to share data, while maintaining the security of your core networks and systems.
Implementing an end-to-end export solution
We have split this guide into two sections. The first deals with the techniques underlying the architecture pattern. The second talks through the design of an export solution, using these techniques.
1. Techniques used by the safe data-export pattern
The safe data-export pattern is made up of four basic techniques which combine to form an end-to-end export solution.
Controlling the release of information
Preventing hidden data in documents
Defending attacks over the network
Encrypting data for the recipient
2. Design and management of the export solution
Using the safe data-export pattern, you will need to design, build and then monitor your export solution.
Controlling the release of information
Controlling the release of information requires both appropriate policy and technical measures. These should balance the need to protect sensitive information, with the need to share information quickly and easily.
The risk to manage
If appropriate controls are not in place for authorising the release of information, users might accidentally - or intentionally - export information which should only be available within your organisation.
Depending on the nature of the information, this could lead to reputational or commercial damage, or worse.
Defensive techniques
You will need a release authorisation policy, to help decide which information assets are appropriate for sharing outside your organisation.
Your policy should take account of factors such as:
- Information type – different types of information may have a different value to your organisation.
- The source – where the information has come from.
- The destination – who the onward recipient is, how trustworthy their IT system is, and what you know about how they will handle the data. You may need an information sharing agreement with them to govern how they will protect the data.
- Who is requesting the export – assuming the user (or system if the request is part of an automated process) is authenticated, it will be possible for you to factor their identity into your release decision.
- Multiple authorisations – sometimes it may be necessary for an additional person to be involved in authorising the release of information. This could be another employee, a manger, or the information's owner.
- Classification – a classification or marking may indicate a document is too sensitive for release to a destination.
- Whether a threshold/volume limit has been reached already – if more information is being released than expected, this could indicate a breach has occurred.
Once you have defined your policy, you will need to consider how much of the policy you wish to enforce using technology and how much you will rely on user behaviours and monitoring.
It may not be possible to technically enforce all aspects of your policy. In fact, having technical controls which are too strong may disrupt your organisation's business by blocking information that is acceptable to share.
Practical tips
-
Avoid accidentally releasing information to the wrong person or address
Ensure it is obvious both who the intended recipient is and what system they are using (for instance a corporate vs personal account).
-
If your policy requires a second person to authorise release of information
Consider whether this will be workable for your organisation out of normal working hours. In some circumstances, it may be necessary to allow users to unilaterally release information, but to automatically notify their manager or authoriser.
-
If you use classification markings
When labelling information in need of additional protection, strong user training and tooling will need to be in place to ensure your information has been correctly marked.
-
If you need to release information automatically
You should consider a testing regime that ensures the system is performing as designed and not leaking unintended information.
-
If rate limiting is employed
It will need to be tuned – consider rate limiting on a per user basis to make it more effective.
-
Export controls should be balanced with broader environmental risks
This includes users being able to print data, take pictures with a smartphone, copy and paste into other documents and so on. Export controls which are too onerous on the user could lead to the growth of ‘shadow IT’ and the consequent loss of governance and control.
Preventing hidden data in documents
Modern file formats can be complex, containing many different fields and variables. Often, much of this information is hidden from the user, so there is a risk that they may accidentally release information.
The risk to manage
When a document is exported from a network, there can be additional information remaining hidden in it, that the user is unaware of. This could include sensitive business information.
For an Office productivity document, this could include track changes, comments, undo history or author details. Other file types could also include fields which are not required or intended for export. Accidental release of this hidden data could lead to a damaging data breach.
Defensive techniques
Preventing this type of data breach means removing hidden information before it is sent beyond your organisational or system boundary.
Two techniques can do this:
- Sanitisation – documents can be inspected and hidden information removed.
- Format Transformation – transforming a document to a different file type may remove some of the hidden information. Specifically, converting into a format designed for printing may remove track changes and undo history.
When implementing such controls, you should keep in mind that users may, at times, have a legitimate need to share documents with certain functionality retained (such as tracked changes or comments). Where this is the case, controls that remove this functionality should be made optional.
Comprehensive training will help users to make appropriate decisions, taking security into account. Users should also be able to see the converted version of their document before sending it out. This will allow them to ensure any conversion has not impacted the meaning or the format of the document.
Defending against attacks over the network
Controlling the release of information requires both appropriate policy and technical measures. These attacks could be either inbound from an external system or command and control for malware on the organisational system.
The risk to manage
An export solution requires end-to-end network connectivity, which makes it an attractive target an attack over the network.
There are two ways an export channel can be used for an attack over the network:
- An attacker may use an export channel as a route to perform initial exploitation
- An attacker may use an export channel as a way to steal information, or perform command and control once the network has been compromised by some other means. This can mean:
- Simply using the export channel to send data
- Hiding data within a legitimate export
Defensive techniques
The following techniques can defend against an attack over the network:
- Flow control – you can use data diodes to ensure one-way communication through the export solution. This will prevent an external attacker being able to utilise your export channel to communicate with any malware present on your system. It also means external attackers cannot reach internal systems through the export solution.
- Release control – a means to bind the release authorisation process to the export channel. This is designed to prevent unauthorised internal systems or users from using the export solution – it can often be implemented with channel authentication, or digital signatures on each object.
- Proof of human controls – validating that a human is requesting the export rather than malware. This can be achieved by requiring a user to type in a code from a TOTP token, for example.
Detecting deliberately concealed data
Detecting data which malware has hidden within a legitimate export is particularly challenging. There are many subtle ways to encode or hide data.
When implementing an export solution , you need to be aware that there will always be a residual risk from malware that is present on your system hiding data in a legitimate export. This is a separate issue to the accidental inclusion of hidden data, covered in section 2.
Encrypting data for the recipient
Encryption can be used to ensure that exported data is protected until it reaches its intended recipient.
The risk to manage
If information released from a system is not encrypted, anyone intercepting the communication will have access to its content.
Defensive techniques
There are two possible techniques which can be used to encrypt information leaving an export solution:
- Data-in-transit encryption – such as Transport Layer Security (TLS) – used to encrypt the communication channel that the information passes over
- Object encryption – encrypting each object individually for the recipient
In many situations, the use of data-in-transit protection will be sufficient. However, in higher risk scenarios, the main benefit of object encryption is that it can be used prior to the object passing over a flow control. This means that a compromise of the external components in an export solution would not result in the attacker being able to see the data that is released.
System Design
End-to-end export solution will vary slightly in their design. However, there are some key considerations as to the ordering of the components and techniques involved, to ensure they are effective.
A proposed end-to-end design is depicted in Figure 1, below.
Stages of the export process
As shown in the diagram, data export can be broken down into three overlapping stages.
- 1
User Involvement
The user must act to move the export process onwards, or halt the process
- 2
The Export Solution
The set of processes and components which, in sequence, bring about the export of data
- 3
Organisational Ownership
The components of the cross domain export solution that the exporting organisation should be responsible for, to ensure control of the risk involved in exporting information.
The flow of data in figure 1:
- An export of a Document or data object is initiated from the Source System
- Sanitisation is performed to remove hidden information from the document. This can require user intervention to tune the level of sanitisation.
- Release Authorisation is performed to ensure the document is appropriate for release. This should take into account a number of factors as described above, and might include one or more human review and authorisation steps.
- If the Release Authorisation step is successful then (depending on the policy) the document can be Encrypted.
- Signing the document for the Release Control can then be invoked if required.
- The Document is then passed to the Release Control, this may check the signature to ensure it has been through Release Authorisation before handing it over to Flow Control.
- Flow Control should always directly follow Release Control, to ensure that only data objects passing the Release Authorisation are sent to the External Proxy.
- The External Proxy is responsible for sending the document to the Destination System.
Variants of this architecture
There are a number of valid variants of this architecture, which should be considered by system designers:
- Release Authorisation and Release Control, may be closely coupled (for instance by sequentially connecting them) instead of using object signing, or channel authentication.
- Aspects of Release Authorisation, Encryption and Signing can take place within the Source System. This could happen, for example, as a workflow within a document management system. For this approach, it is important that Release Control can determine whether data has successfully achieved Release Authorisation and not somehow bypassed it.
- If the export solution is used in conjunction with an import solution to support two-way communications, care needs to be taken to ensure that the two systems together cannot be used for a bi-directional attack. In this scenario, an attacker breaches the internal systems through the import channel, and then uses the export channel to export data, or as an attack feedback channel. Separating the import system and export system can reduce this risk, but is not always practical.
Monitoring and Managing an end-to-end export solution
You should monitor your export solution to ensure it is working as desired. A management regime will help ensure that this is the case.
Management
To manage the solution effectively:
- Ensure the system can be patched easily and quickly
- Ensure that management functionality is separated from the internal systems, so that compromise of an internal device cannot affect the integrity of the end-to-end export system
- Ensure that management of the components to the right of the Flow Control (such as the External Proxy) are separate from the management of the other components, These external components are at greater risk of compromise
Monitoring
Monitoring is essential for ensuring export control is effective:
- The system responsible for monitoring the solution should be separate from the system responsible for management of the solution
- Logs should be collected from all components in the solution and taken into the monitoring system
- It may be appropriate to record all content transiting out of the system, though this may require additional protections
- Analyse your logs, looking for users abusing the system, sending out data that shouldn’t be released. Analytics can be used to look for exports that don't follow normal usage patterns.
- Your log analysis should help you detect un-correlated events across components which should never occur. For instance, a document being released which has not been through Release Authorisation
- Network monitoring should be in place to identify >network-based attacks before they breach your network boundary.
Conclusions
A well-designed export solution can enable your organisation to share information with others, without putting IT systems at greater risk of compromise.
Human intervention
Often, export of data will require human intervention. So, throughout the design process you should consider how well the export system will integrate with your organisational culture and ways of working.
The goal here is to ensure the system prevents unintended exports but does not cause adverse behaviours, as people attempt to circumvent it.
Balanced approach
Export controls within an IT system should be balanced with the broader environmental risks that often exist, such as users being able to print data, take pictures with smartphones, copy and paste into other documents and so on.
Export controls which are too onerous on the user could lead to the growth of ‘shadow IT’ and the consequential loss of governance and control.
Export systems should make sharing and collaborating with others easier, not harder.
