Unfortunately, there are many serious data loss incidents which could have been avoided or reduced in severity if simple good practice had been implemented. The Office of the Information Commissioner has published guidance on the most significant threats to data protection. These are defined as those that have either resulted in a severe breach of the DPA or frequently occur in the ICO’s casework. This blog-post offers a summary of this work.
– Read this guidance, apply the principles and avoid the pitfalls –
The Ten most frequently-arising computer security issues are:
| 1 | Operating system – software updates not done | Unpatched servers are a real security hazard – keep all software on your server up to date. |
| 2 | SQL injection attack possible | Poor coding can create security holes which leak data – websites are particularly at risk. |
| 3 | Unnecessary services left on. | Unnecessary services can offer an open door to cyber-criminals. |
| 4 | Disposal of software and/or equipment | Data hygiene is essential before any digital equipment is recycled, reused or destroyed. |
| 5 | Passwords and storage | Passwords must be strong and they must be stored securely. |
| 6 | Poor configuration of SSL and TLS | Incorrect configuration (including default) can lead to a mistaken sense of security. |
| 7 | Data processed in an inappropriate location. | A large number of data breaches involve personal data being processed in an inappropriate location (e.g. at home without permission) |
| 8 | Default system credentials left intact. | Many software components are distributed with default credentials (e.g. a username, a password) which are often overlooked. These credentials are widely known! |
| 9 | ‘Layered Products’ – software updates not done | Unpatched versions of PHP, Java, Tomcat, Networker, PuTTY etc, are a security hazard. |
| 10 | Unencrypted personal data | Personal data should be appropriately protected by strong encryption. |
1.0 Software security updates
Without regular application of security updates to a system’s software, it will become progressively more vulnerable over time as more security flaws are discovered and methods for exploiting them become more widely-known. The same situation will arise when the developers discontinue technical support for a software product, which normally means that no more security updates will be available.
If there is a good reason not to apply all available updates as soon as possible, then an exceptional patching policy must be drawn up. The business owner should perform a risk assessment and seek appropriate approval for any risk treatment decisions made, taking proper account of the nature of the data being processed.
1.1 Good practice summary:
1.1.1 You must have adequate arrangements in place for OS software update – especially for software used for processing personal data.
1.1.2 There may be good reasons not to apply all available updates as soon as possible. For example:
- an operational need to wait for a suitable maintenance period;
- co-ordination with other necessary updates on related software;
- the need to test updates before rolling them out to production systems; or
- an assessment that a vulnerability does not affect the configuration used by the relevant systems.
When there is a reason to delay, the server owner or business owner should perform a risk assessment and seek appropriate approval for any risk treatment decisions made. This risk assessment should take proper account of the nature of the data being processed. Security updates must be applied as soon as is reasonably practical after they become available.
2.0 SQL injection
The risk of ‘SQL injection’ affects applications that pass user input to databases in an insecure manner. Typically this can occur in a publicly-available website that uses a database, in order to display or input information. Since SQL injection flaws are introduced in the source code of applications, it is important to identify who is responsible for maintaining the source code of any application used.
2.1 Good practice summary
2.1.1 Be aware of all of your assets that might be vulnerable to SQL injection. SQL injection can affect applications that pass user input into a database and includes many modern websites and web applications.
2.1.2 SQL injection presents a high risk of compromising significant amounts of personal data and it must be considered to be a high priority for prevention, detection and remediation.
2.1.3 SQL injection results from coding flaws – so be sure you know who is responsible for developing and maintaining your code. It is these people who you will need to rely on to prevent SQL injection or fix SQL injection flaws if they are found. They will need guidance and training to understand the issue.
2.1.4 Consider independent security testing (penetration testing, vulnerability assessment, or code review, as appropriate) of the relevant sites or applications in order to identify code development issues, including SQL injection flaws. Do this before the application goes live and periodically test live applications.
2.1.5 When remediating an SQL injection flaw, consider using parameterised queries where possible, and ensure that all similar input locations are also checked and remediated where applicable.
Parameterised queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This ensures that the database can distinguish between code and data, regardless of what user input is supplied and means that an attacker is not able to change the intent of a query, even if SQL commands are inserted.
3.0 Unnecessary services
A golden rule in network security is only run services that are absolutely necessary. This will reduce the number of ways an attacker might compromise systems on the network. If you have services which are publicly accessible and are not being actively used, you are leaving doors open (i.e. exposing potential attack vectors) unnecessarily.
3.1 Good practice summary:
3.1.1 Completely decommission any service that is not necessary.
3.1.2 Avoid high risk services such as telnet.
3.1.3 Ensure that services intended for local use only are not made publicly-available.
3.1.4 Periodic port-scanning to check for unnecessary services inadvertently enabled.
3.1.5 Maintain a list of which services should be made available. Periodically review the list to see whether any services have become unnecessary, and restrict or decommission them as appropriate.
4.0 Decommissioning of software or services
When an old or temporary/test service is no longer needed, it must be decommissioned thoroughly, otherwise it will continue to pose a risk.
4.1 Good practice summary:
4.1.1 List all the components of a service so that you can make sure they are all decommissioned.
4.1.2 Make a record of any temporary services which you will eventually need to disable.
4.1.3 Thoroughly check that the decommissioning procedure has actually succeeded (use systematic tools such as port scanners to check this).
4.1.4 Arrange for the secure disposal of any hardware and storage devices.
- Password storage
Users’ access credentials (eg a username and password or passphrase) are particularly valuable to attackers and it is important that credentials are appropriately managed.
5.1 Good practice summary:
5.1.1 Don’t store passwords in plain text, nor in an easily decryptable form.
5.1.2 Use a hash function. Only store the hashed values.
5.1.3 The hash function should have appropriate strength to make offline brute-force attacks extremely difficult – if not, impossible.
5.1.4 Use ‘salting’ to make offline brute-force attacks less effective.
5.1.5 Periodically review the strength of the hash function and keep up to date with advances in computing power. The best way of achieving this is to use a password hashing scheme with a configurable work factor.
5.1.6 Use a combination of password strength requirements and user education to ensure that attackers can’t simply guess common passwords.
5.1.7 Have a plan of action in case of a password breach (e.g. how to reset users’ passwords in bulk and how to notify them of what has happened and what they need to do about it)
- Configuration of SSL or TLS
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are closely related encryption schemes used for ensuring secure communications across the internet. In practice, the single term ‘SSL’ is often used loosely to signify either or both of SSL and TLS, even though TLS has been in existence since 1999 and is now widely used and supported. Misconfiguring an SSL or TLS service will cause one or both of these assurances not to be guaranteed. However, both assurances are required to create a trusted connection so that personal data or other sensitive information can be securely transferred.
6.1 Good practice summary:
6.1.1 Ensure that personal data (and sensitive information generally) is transferred using SSL or TLS where appropriate.
6.1.2 Consider using SSL or TLS for all data transfer in order to reduce complexity. Remember that in the case of a website, any included content such as images, javascript or CSS should also be provided over SSL or TLS in order to avoid ‘mixed content’ warnings.
6.1.3 Ensure that SSL or TLS is set up to provide encryption of adequate strength.
6.1.4 Ensure that every SSL or TLS service uses a valid certificate, and schedule renewal of all certificates before they expire to ensure the services remain secure.
6.1.5 Consider obtaining an Extended Validation (EV) certificate if assurance of identity is of particular importance.
6.1.6 Do not encourage users to ignore SSL or TLS security warnings.
- Inappropriate locations for processing data
A large number of data breaches involve personal data being processed in an inappropriate location. There are typically two main types of cause of this:
- Poor security architecture, meaning that it isn’t clear where and how personal data should be processed.
- Inadvertently storing personal data in a publicly accessible area.
7.1 Security architecture
An important principle is segregation of production environments from development or testing environments.
7.1.1 Ensure testing or staging environments are segregated from the production environment.
7.1.2 Consider segmenting your network according to function and in accordance with your data protection policies.
7.1.3 Ensure your network architecture accounts for functions such as backups and business continuity in general.
7.2 Storing personal data in a widely-accessible location
Data leaks can happen as a result of three mistakes that can be made, either separately or together:
7.2.1 Failure to realise that the storage place is widely accessible
7.2.2 Failure to realise the personal nature of the data in the first place
7.2.3 Administrative error
7.3 Storing personal data – good practice:
7.3.1 Make sure you have policies for how, when and where personal data will be processed.
7.3.2 Consider all the services you are running, how they are accessible, and whether they comply with your policies.
7.3.3 In particular, ensure any web servers are exposing only the intended content. Where necessary, apply specific access restrictions.
7.3.4 Do not rely merely on obscurity to prevent access.
- Default credentials.
Many software components are distributed with default credentials provided, typically a username and password. This can make distribution, installation and set-up simpler, but also poses a security risk because these credentials are widely known.
8.1 Default credentials – good practice summary:
8.1.1 Change any default credentials as soon as possible.
8.1.2 When changing default credentials, remember to follow good practice on strong password choice.
8.1.3 Ensure that credentials are not hard-coded into any of your software.
8.1.4 Ensure that credentials are not transmitted in plain text.
- Layered products.
Layered products include software components, services, libraries and development frameworks which sit on top of the operating system in a layer just below or adjacent to the application. These include Rails, PHP, Java, Tomcat, Networker and PuTTY. Without regular security updates to these layered products, they will become progressively more vulnerable over time as more security flaws are discovered and methods for exploiting them become more widely-known.
9.1 Layered products – good practice summary:
9.1.1 You must make adequate arrangements for the software update of layered products. If there is a good reason not to apply all available updates as soon as possible, then an exceptional patching policy must be drawn up. The business owner should perform a risk assessment and seek appropriate approval for any risk treatment decisions made, taking proper account of the nature of the data being processed.
- Unencrypted personal data.
Personal data must be adequately protected from unauthorised disclosure, theft, loss, and accidental and deliberate damage. Adequate protection means protective controls which are commensurate with risk. Personal data is vulnerable when it is processed on a mobile device, or when it is at rest (stored on USB, magnetic or optical media) or when it is being transmitted. Encryption must be considered as a control to protect personal data at these times.
10.1 Personal data – good practice summary:
10.1.1 Don’t process, store or transmit personal without management consent.
10.1.2 Know how much personal data you are processing
10.1.3 Know what the personal data contains
10.1.4 Know the path followed by the data during processing
10.1.5 Ensure that personal data is encrypted when the data is transmitted or stored.