We recently became aware of a data leak where personal information of up to 64 million people was leaked to unauthorised users through a third-party system which was used. Luckily those who discovered the breach were ethical, reported the vulnerabilities they discovered to the companies affected.
Loading...
How thorough ISO 27001 auditing could have prevented a global data leak.
Loading...
Background
A global company use a third-party AI chatbot to manage the early stages of their hiring process to capture applicants’ details, including personal details and CV, then progress them through an initial screening test.
While using SSO for applicants, there was a link on the site for third party provider users to click and log in using a username and password. This was left as a way for the provider to access a test restaurant. However, this was breached using a simple username and password combination. Once unauthorised access was obtained, they could access all applicants’ details within that testing environment.
After browsing around a bit, they discovered the calls to API to system to store the applicants’ personal details as well as the chat history with AI conversational bot. The API Indirect Object Reference vulnerability within the API, which allowed them to manipulate the applicant ID parameter to enumerate through all applicants within the system, regardless of where they had applied to.
Preventions
The supplier was (and still is) certified against iSO 27001 and SOC 2 standards.
So… how could (and should) the vulnerabilities which lead to this leak have been prevented by the contractor? With the assistance of thorough audits focussing on ISO 27001:2022 controls listed here, some activities and lax procedures around them could have been found, and information kept secure.
Selecting a knowledgeable body with qualified auditors with strong industry experience will assist companies in identifying weaknesses within management systems and procedures and offer the opportunity to improve the robustness of the mitigations and controls put in place to limit, or ideally prevent data leaks from systems.
The key vulnerabilities for both the organisation involved and supplier can be broken down into the below groups:
Loading...
Insecure access to the application
Although the access to applicants and restaurant users to manage their applicants was through SSO, offering security, there was still the back door of the provider access which utilised a simple username and password. Additionally, an insecure username and password used were “123456”. It was reported that this had been left over since implementation in 2018.
Controls which can be implemented to prevent this include:
5.16 – Identity Management – Management of identities should be managed through their lifecycle, including deactivation and removal when no longer required. User credentials should not be shared between people unless required for business or operational reasons.
5.17 – Authentication Information – where possible, strong passwords or passphrases should be used. Commonly used passwords or compromised usernames should not be used. Validation should be built into products and password storage utilities should be configured to only allow strong passwords to be used.
8.31 – Separation of development, test and production environments – testing and production environments should be segregated which then allows for any sensitive data to be removed or anonymised or removed.
8.33 – Test information – sensitive data should be removed or masked if used for testing, and properly deleting data used for testing once it is completed.
Loading...
Insecure API
The API allowed for results to be returned from calls made to it without any checks on authorisation as to whether the caller had access to the data being requested. It was not determined whether there was any authentication performed on the API endpoint, although given that it was used for core access within a system after initial user authentication, that there was authentication performed. However, there was no authorisation done when retrieving the records to check if the user making the API call had access to that record.
Secure API design should also allow for some sort of rate limiting or checks to detect if someone is attempting to exploit an Indirect Object Reference.
Specific controls which will mitigate or detect this type of vulnerability are:
8.26 – Application Security Requirements – determining and documenting security requirements of the API before it is built so that these requirements can be built into products and environments.
8.27 – Secure system architecture and engineering principles – ensuring that the architecture of the API is secure and involves security requirements are considered within the architecture of the solution.
8.16 – Monitoring activities – to monitor activity on the API, which should then indicate and alert if someone is attempting to use the API in a way that indicated malicious intent (eg, cycling through identities).
Loading...
Supply Chain Management
As an organisation you are responsible for all data, including personally identifiable information that is captured from users by your organisation. This includes any data which is captured and stored in systems owned and managed by your suppliers. As part of engaging with third party suppliers, security considerations should be evaluated, such as checking for certifications or other checks to give confidence that they will keep data secure. This can also include the right to review their systems for security which should be agreed to in the contract.
After going live with a new system implementation, requirements for their support and access requirements should be reviewed and monitored.
Controls to manage the supply chain are:
5.20 – Addressing information security within supplier agreements. Initially, data security should be included within agreements with suppliers to outline responsibilities around handling of data by suppliers. This provides the basis for the following controls.
5.21 – Managing information security in the ICT supply chain. Organisations should have assurance of the security within supplier software by requiring suppliers provide them with information describing the security functions within their product and by implementing a monitoring process for validating products comply with the security requirements.
5.22 – Monitoring review and change management of supplier services. Organisations should monitor and review changes to supplier services and products including identification of security vulnerabilities and how they are managed.
Summing Up
Like all leaks or breaches, there is no single point which will protect your data and systems, there are many different vulnerabilities which are exploited to exfiltrate data from your systems.
Cyber security is a mindset and culture which must be adopted within a business. Implementing a system (ISMS) to handle security and empowering staff to enhance this and being accountable as a business for the culture is vitally important to prevent any security incidents and keeping your customer data secure. By securing your data you will prevent incidents such as this and keep your business out of the news.
If certifying your business against a data security standard, whichever you choose as most relevant for your business, select a certification body and auditors who are knowledgeable and can add value to your business by pointing out things you are doing well and anywhere they can see improvement opportunities.
Author
Brad Fabiny
DQS Product Manager - Cyber Security and auditor for the ISO 9001, ISO 27001 standards and information security management systems (ISMS) with extensive experience in software development.
Loading...
