Having a risk assessment helps to qualify the approach and show due dilligence, but it's a subjective process so results will vary and if the ICO disagree with the outcome then the financial penalties can be large. Marriot claimed a risk based approach supported their decision to focus database monitoring and encryption on card holder data, however the ICO disagreed with that conclusion and held them liable for not giving personal data the same level of protection.
Industry regulations such as PCI can help indicate that controls are "appropriate".
Conclusion
The ICO appear to take the state of the art as their baseline and seem to have a fairly idealistic view on implementing enterprise security. They look at recommendations from bodies such as NCSC, NIST, etc alongside industry regulations and consider any deviation from those as an indicator of negligence which increases the liability. Sensible efforts will be considered such as Marriot's MFA implementation, which ultimately turned out to be incomplete but that was not considered in the judgement as an independent audit had informed them the control was in place.A few particular controls were called out in multiple cases and should be on any organisations radar:
- Application Whitelisting.
- Multi-factor authentication.
- Detection of configuration change.
- Privileged access management (PAM) and implementation of least privilege.
- Risk Assessment of personal data storage and processing.
- Awareness of good practice and current issues with technologies in use.
- Strict control over remote access.
- Compliance with internal security policies and relevant industry regluation.
In terms of specific items called out with some big cases that indicate expectations of controls are:
Ticketmaster
https://ico.org.uk/media/action-weve-taken/2618609/ticketmaster-uk-limited-mpn.pdf- Hacked via 3rd party Javascript chat bot they'd included on their website, 3rd party was then compromised.
- The 3rd party had ISO27001, this was not considered relevant by the ICO as it's not a software security standard.
- The ICO used blog posts and Stackoverflow questions about risks from including 3rd party Javascript on website as evidence that this was a recognised issue, combined with supply chain articles by NIST and NCSC.
BA
https://ico.org.uk/media/action-weve-taken/mpns/2618421/ba-penalty-20201016.pdf- Referenced CPNI GPG from April 2015 supply chain guidance on assessing risk
- Mentioned various NCSC and NIST documents recommending MFA
- Highlighted that BA's own internal policy mandated use of MFA.
- However their implementation of Citrix did not apply MFA to all access.
- Did not have a risk assessment of the Citrix solution or the applications accessed through it.
- Had not locked down the services available by Citrix.
- Lack of app whitelisting.
- Lack of server hardening.
- Limited restrictions on apps being opened by stopping clicking the icon, but still able to run via file->open.
- Environment was pen tested, but scope appears to have been limited so many issues were not detected.
- Called out use of hardcoded passwords.
- Suggested logging access to certain files containing hardcoded passwords would be a suitable control.
- Lack of implementation of "least privilege" principles.
- Lack of monitoring of unexpected (e.g. guest) account logins.
- No use of PAM.
- Limited monitoring.
- Used PCI DSS but were not compliant with it.
- Left debug logging in place on live systems, increasing data available to attackers.
- Lack of File Integrity Monitoring (FIM).
- No ability to detect changes to the website code.
Marriot
https://ico.org.uk/media/action-weve-taken/mpns/2616891/dsg-mpn-20200107.pdfMarriot thought MFA was implemented and had even audited it, but there were undiscovered gaps. The ICO accepted this and did not include that in their assessment.
- Insufficient monitoring of privileged accounts - not logging access to systems, noting from other cases that logging alone is of little value unless someone is checking the logs or being alerted.
- Insufficient monitoring of databases - Guardium deployed but only on cardholder storing tables, so they had done a risk based approach to choose where to monitor, but was not deemed adequate by the ICO. SOC/SIEM was not logging the user access to databases. Boundary controls were not enough without internal monitoring.
- Control of critical systems - app whitelisting, monitoring/alerting.
- Encryption - no justification/risk assessment of data held without encryption.
DSG
https://ico.org.uk/media/action-weve-taken/mpns/2616891/dsg-mpn-20200107.pdf- It was deemed that that PAN (Primary Account Number - i.e. Card data) does constitute personal data, so be wary of this as data is considered PII if people can be indirectly identified by it, phone numbers being a common example that many may not initially consider as being PII. See: https://www.gdpreu.org/the-regulation/key-concepts/personal-data/
- PCI DSS is not indicative of appropriate security for PII but certifications like this can be helpful in deeming what level is considered appropriate, it sounds like DSG had some issues with PCI compliance.
- Segregation was considered as both network/IP and Active Directory, the inference being that segregating your network but not your AD is probably not appropriate.
- Not having host based firewall was called out, despite that it wouldn't have prevented this attack. Also the ability to detect changes to the configuration of these local firewalls was called out as a requirement.
- Inadequate patching on domain controllers.
- No logging/monitoring in place to detect and respond to attacks.
- Outdated versions of Java.
- Not strictly controlling privileged access rights - i.e. no PAM.
- Not using standard builds with hardening built in.
- Patching of devices was not compliant with their own policy.
- Case notes state that application whitelisting is considered "appropriate" control
Posts
