Protecting bulk personal data
Pages
Page 4 of 5
How is your system designed, implemented and operated?
Learn about what to look out for in how your system is designed, implemented and operated to help protect your bulk data held by digital services.
Below are points 8-15 of the good practice measures.
No known vulnerable surfaces are exposed at the edges of your service.
Vulnerabilities in third-party software are mitigated. Custom software - such as web applications - is subject to testing for common vulnerabilities before handling live data.
Continuous testing confirms that all of this remains true.
The vulnerabilities which an attacker can reach first are those exposed by the external interfaces of your service. Typically, these external components would be web applications, but you’ll need to consider what they are in relation to your own data set or system.
Unmitigated vulnerabilities in web servers, web frameworks, third-party libraries and custom code are often easy to find and compromise using widely available, low-skill tools. If these components have access to your data set, that data is likely to be compromised when the components are exploited.
Commodity software components are easily tested for well-known vulnerabilities using vulnerability scanning tools. Custom software - such as your web applications - can also be tested. Using widely available tools it’s easy to check for common vulnerabilities such as SQL injection, cross-site scripting, and cross-site request forgery.
Any of the following statements are true | All of the following statements are true | All of the following statements are true |
|---|---|---|
Vulnerable components are known to be exposed at the edge of the service. The external attack surface of the service is not routinely tested for well-known security issues. The external attack surface of the service has not been tested for well-known vulnerabilities for at least 6 months. | All commodity software components accessible externally have had all security patches applied (or vulnerabilities are otherwise mitigated). All custom software and applications have been tested for common vulnerabilities. Regular (at least quarterly) testing confirms this remains true and external-facing components of the service are patched promptly if required. | All commodity software components accessible externally have had all security patches applied (or vulnerabilities are otherwise mitigated). All custom software and applications have been tested for common vulnerabilities. Continuous testing confirms this remains true and external-facing components of the service are patched promptly if required You have validated these impact statements within the last 12 months |
Prompt mitigation
How promptly should vulnerabilities be mitigated? As described above, your team will need to triage vulnerabilities to understand their impact within your specific scenario.
However, as a rule of thumb, you should aim for triage and mitigation of issues in external-facing components to take:
- Hours for vulnerabilities classified ‘Critical’ or ‘High’ or vulnerabilities reported as being actively exploited in the wild
- Days for vulnerabilities classified ‘Severe’ or ‘Medium’
- Weeks for vulnerabilities classified ‘Important’, ‘Moderate’ or ‘Low’
No unsupported software is present in your service and its underlying infrastructure.
Software that is no longer supported will not receive security patches in the event that vulnerabilities become known. This means it will likely be difficult, or impossible, to mitigate any issues that are found.
We recommend that no ‘out of support’ software be used across your entire software stack for the components protecting the data. This recommendation applies to operating systems, infrastructure firmware and software packages on devices that handle or protect the data in question.
| The following statement is true | The following statement is true | All of the following statements are true |
|---|---|---|
| Some of the software, operating systems, or networking equipment for components which handle or secure access to data has reached its ‘end of life’. Or is no longer being supported by the vendor or community. | Some of the software, operating systems, or networking equipment for components which handle or secure access to data is within 12 months of becoming ‘end of life’. Or is no longer being supported by the vendor or community. Some of the software, operating systems, or networking equipment for components which handle or secure access to data are within 3 years of going out of support, and no mitigation plan is yet in place. | All operating systems, software packages and networking equipment for components which handle or secure access to data are actively supported by the vendor or community |
Basic attacks against your service would be noticed through proactive monitoring and handled through a measurable, tested, incident response process.
Assume that some attacks would be successful and ensure you would detect them.
Basic attacks that could be launched by relatively unskilled attackers using widely available tools should be detected by the team operating the service, categorised according to severity, and responded to through a well-known and well-drilled process.
The sort of attacks we would consider ‘basic’ are:
- attempted DDoS attacks
- attempts to brute force user, service or administrator credentials
- attempts to insert malicious content into a text input field in a web form (SQL injection, cross-site scripting, cross-site request forgery)
It is good practice to test your own services for weaknesses using widely available tools and to find out if the team monitoring or operating the service detected your activities.
Plans should be in place to react to attacks against your service. System operators need to know what action to take, what they are authorised to do, and what decisions they would need to escalate.
| Any of the following statements are true | All of the following statements are true | All of the following statements are true |
|---|---|---|
It is not known whether basic attacks against the service would be detected. There is no response plan in place to deal with incidents. | It is hypothesised that basic attacks against the service would be detected, however this is rarely (if ever) tested. An incident response process is in place but this is rarely (if ever) tested. | Regular testing and tuning of triggers and alerts gives you confidence that basic attacks against the service would be detected. An incident response process is in place and is regularly tested. |
Detecting compromised components
In addition to detecting attempted breaches, consider how you would detect one which had already been successful.
Do components in your system need to be directly connected to the internet? Would an alert be raised if they attempted to do so?
An automatic alert would be raised in response to an atypical attempt to access bulk data.
These attempts should include unusual queries, attempted large scale exports of data and administrator access to data.
Having a good understanding of what ‘normal’ looks like for your service will help you detect the abnormal.
Depending on a user’s level of authorisation and usual behaviour, queries to export large amounts of data might be entirely above board. For others this behaviour may be abnormal, and should therefore be noticed and acted upon.
Since administrators should have no need to access data, any administrator doing so should cause an alarm to be triggered.
The following statement is true | All of the following statements are true | All of the following statements are true |
|---|---|---|
Controls to detect unusual queries and attempted large scale exports of data are not in place. | Controls to detect unusual queries, attempted large scale exports of data or administrator access to data are alerted upon. Controls to detect unusual queries and attempted large scale exports of data are in place but it is not currently possible to detect administrator access to data. | Controls to detect unusual queries, attempted large scale exports of data or administrator access to data raise an alert. These controls are regularly tested and an established procedure to investigate the alerts is in place. |
All interfaces to your service are well-defined. None allows for arbitrary queries of the data.
If there is no function which enables users to retrieve large data sets, such functionality cannot be abused in the event of a compromise.
When building systems there’s often a desire to incorporate functions allowing users with the appropriate skills to handcraft queries and run them against the data set.
These interfaces are often prone to errors in implementation, allowing actions that were not intended. They also undermine any layered controls present in the design of the system, as they act as a bypass for the layered approach.
If there is a legitimate business requirement for an individual to have the ability to run arbitrary queries, this should be considered a privileged role, only enabled in conjunction with access logging and audit of the user’s activity.
The following statement is true | The following statement is true | One of the following statements is true |
|---|---|---|
The use of interfaces that support arbitrary queries is not logged or not audited on a regular basis. | Interfaces that allow arbitrary queries of data are available to many users, though the use of the interface is logged and constantly audited to ensure proper use. | Interfaces that allow arbitrary queries of data do not exist. Interfaces that allow arbitrary queries of data exist but are restricted to a small number of users whose use of the interface is logged and regularly audited. |
User access to bulk data held by the service is rate-limited.
To avoid abuse of user access to data, or to limit the impact of a compromised account, it is advisable to apply reasonable constraints to the number of records a user is able to access, within a given period.
For example, in a case-working scenario you could limit the number of records a user can access in a shift period to a number marginally higher than the most efficient worker could manage to review within a shift period.
Similarly, if a function exists to search data sets by certain fields, then the search results should be limited to a reasonable number, based on normal expected use.
The following statements is true | N/A | This statement is true |
|---|---|---|
No control prevents a user retrieving all records from the data set. | A user can only retrieve a limited number of records from the data set at any one time. |
A spear-phishing attack against an administrator's email account, or an attack through their web browser, will not yield administrative access to the service using a single exploit.
The goal here is to mitigate the most common attack vectors used against system administrators.
If administrators use the same device or account to open their email, browse the internet, and administer the service, a successful attack against them would give the attacker administrative access to the service.
Some high-profile compromises of commercial services were carried out by sending a targeted spear-phishing email to a system administrator, identified through their social media profile. Poor hygiene by that system administrator is what the attackers were relying on in order to take control of the system.
‘Watering-hole attacks’ to target system administrators through sites they are likely visit should also be mitigated.
The following statement is true | The following statement is true | All of the following statements are true |
|---|---|---|
Administrators are able to access email accounts or browse the Internet on the device from which they are managing the service, within the same user context. | Administrators are able to access email or browse the Internet on the devices they use to administer the service, but only through a separate user context (eg by logging on to a separate user account). | Administrators are unable to access email or browse the Internet natively on the devices they use to administer the service. If they are able to see their email or browse the Internet it is merely a visual rendering of a separate environment which they are remotely controlling. |
All backups or copies of your data are held securely, for the minimum time necessary.
Some of the most high-profile compromises of recent times stole copies (rather than primary versions) of the data from internet-connected services.
We recommend you don’t hold backups of data on internet-facing services. It is good practice to archive old records into offline encrypted backups rather than keep them within the online system. You should delete these as soon as possible.
Any of the following statements are true | N/A | All of the following statements are true |
|---|---|---|
Offline backups on removable media are not controlled or stored securely. Backups are stored encrypted in an online system along with the decryption key. Copies of data used for temporary activities are not stored encrypted or not deleted when no longer required. Less protected test or development systems handle live data. | Any data backups are held encrypted in an offline environment or on removable media in a physically secure store Any copies of data required for temporary activities are stored encrypted and deleted immediately when no longer required No live data is used in test or development systems. Or these systems are protected to the same level as the production systems. |
