More details have emerged about the root causes of the large data breaches in 2022.
Here, we will assess the key technical aspects that lead to the breaches, and how controls from ISO 27001 Annex A and the Australian ISM can be put in place to prevent this. With ISO 27001 certification, the implementation of these controls and processes within the organisation can be independently monitored by a certification body focussed with skilled auditors.
One of the data breaches involved an attacker accessing administrator credentials from a contractor’s personal browser profile which was in use on their work computer. These credentials were then synchronised across to their personal computer where it was stolen by malware on the contractor’s personal computer. These admin credentials then allegedly granted access to “most of the systems”, including the VPN.
There are numerous ways that this can be protected against. Firstly, using different credentials for different tasks or areas within the system will limit the access that a hacker will have. Further, implementing multi factor authentication where possible, especially on external access points to your system such as the VPN is important.
These are covered in ISO 27001 Annex A controls:
Controls from the ISM which include more detailed controls include:
It was reported that access controls were in place for the API which was used by the attackers to breach customer data. However, these were weakened by a code change which was made.
Despite everyone’s best effort, bugs are somewhat inevitable in software development. No-one intends for bugs to enter systems, however in complex systems, with complex data, some edge cases can slip through, or if the code is used within other parts of the system, and that is not picked up, then things can sometimes slip through. The risk of them getting through can be mitigated against by having all code reviewed before it is put onto even a testing system. Often, we see that code reviews can be a box ticking exercise, or the reviewers don’t fully understand the changes and miss things.
The next step is thorough testing. Depending on the nature of the change, this can be either manual or automated, or a combination. Automated tests would help to detect any degradation in functionality, such as those introduced during the code change. A thorough set of automated acceptance tests which are run periodically can pick up the. Manual testing, where testers go through and use the system can also achieve this based on the system.
These are covered in ISO 27001 Annex A controls:
More detailed controls in the ISM include (but are not limited to):
It was reported that the same access control issue was identified and rectified in a separate system on the main site.
When this was identified and during the fixing process, best practise is that there should have been an assessment performed to identify root causes, and any other potentially affected areas. If the root cause analysis failed to pick up that the code was duplicated in another system, then the job / work tracking system should be able to be used to identify when and where the change was made. If it was made to both affected systems at the same time, then this should be easily identifiable through the change tracking within the job tracking system. Alternatively, if it was “copied” from the first system into the second system, then the jobs should be linked to each other to increase the visibility of the similar functionality.
Best coding practises say that code should not be duplicated and should be re-used where possible. This way, applying the fix in a single place will fix the vulnerability in multiple locations.
These are covered in ISO 27001 Annex A controls:
More detailed controls in the ISM include (but are not limited to):
Once use of the affected API was completed and it had reached the end of its life, it was left dormant, yet still accessible from public facing internet.
While this vulnerability was on a live system located on a sub-domain, we often see that there are many APIs which are intended for internal use which somehow end up being publicly available which are left untracked and vulnerable to attack.
Ultimately, each API should be tracked and monitored, with procedures in place to manage the lifecycle of an API, which includes how to manage it when it is no longer required.
From a networking perspective, there should also be awareness of what is publicly accessible, i.e. what IP addresses, ports. There should also be awareness of which addresses the APIs and endpoints are accessible on.
In addition to these, a penetration test or other vulnerability scan can be carried out on your environment to determine what is publicly accessible, and give you confidence that there are no gaps or other areas which have been overlooked. A thorough penetration test should even give you the details of any endpoints or APIs which are accessible publicly, which can then be rectified.
These are covered in ISO 27001 Annex A controls:
More detailed controls in the ISM include (but are not limited to):
During both incidents there is evidence that both companies either missed alerts or did not act on alerts from their SIEM systems which may have caught the attackers before they had a chance to remove the data from the network.
This can be mitigated by ensuring that your SIEM system is analysing your logs and creating alerts with an appropriate priority which are investigated by your team. There is a balance to be struck here, so that there aren’t too many alerts being raised so they don’t get investigated, while also ensuring that alerts which indicate abnormal behaviour are being raised.
These alerts should include all of the previously mentioned scenarios, and importantly when large amounts of data are either entering or exiting the network through unusual endpoints, or when abnormal endpoints / IP addresses and ports are being utilised.
These are covered in ISO 27001 Annex A controls:
More detailed controls in the ISM include (but are not limited to):
There is much to be learned from cyber incidents like these. Implementing an ISMS will give you a system to handle data security and help you to identify the data that is contained within your business, and the risks associated with it, and controls to place to mitigate these risks.
While there is no guarantee of preventing an attack by a well-resourced and determined attacker, having an ISMS and commitment to data security will help you to mitigate risks and minimise the effects of any attack. This can be done by identifying what data you store and control and where you are handling. Getting certification for your ISMS to ISO 27001 with a certification body with skilled auditors who are committed to partnering with you to improve your system will give you confidence that you are best prepared and protected.
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.
