Insecure Authentication
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:
- A.5.17 Authentication information
- A.8.2 Privileged access rights
- A.8.3 Information access restriction
- A.8.5 Secure authentication
Controls from the ISM which include more detailed controls include:
- Control: ISM-0820; Personnel are advised to not post work information to unauthorised online services and to report cases where such information is posted.
- Control: ISM-1892; Multi-factor authentication is used to authenticate users to their organisation’s online customer services that process, store or communicate their organisation’s sensitive customer data.
- Control: ISM-1173; Multi-factor authentication is used to authenticate privileged users of systems.
- Control: ISM-0974; Multi-factor authentication is used to authenticate unprivileged users of systems.
Coding Errors
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:
- A.5.8 Information security in project management
- A.8.29 Software Development Lifecycle, particularly around testing – ISO 27002 has guidance around secure testing planning and activities including code reviews.
More detailed controls in the ISM include (but are not limited to):
- Control: ISM-0402; Applications are comprehensively tested for vulnerabilities, using static application security testing and dynamic application security testing, prior to their initial release and any subsequent releases
- Control: ISM-1850; The OWASP Top 10 are mitigated in the development of web applications.
Same code being used in multiple locations
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:
- Clause 10.2 Nonconformity and corrective action
- 8.25 Secure development life cycle
- 8.32 Change management
More detailed controls in the ISM include (but are not limited to):
- Control: ISM-1909; In resolving vulnerabilities, software developers perform root cause analysis and, to the greatest extent possible, seek to remediate entire vulnerability classes.
- Control: ISM-0401; Secure-by-design and secure-by-default principles, use of memory-safe programming languages where possible, and secure programming practices are used as part of application development.
Unused API Endpoint left dormant
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:
- A.8.12 Data leakage prevention
- A.8.20 Networks security
- A.8.21 Security of network services
- A.8.25 Secure development life cycle
More detailed controls in the ISM include (but are not limited to):
- Control: ISM-1910; Web API calls that facilitate modification of data, or access to data not authorised for release into the public domain, are centrally logged.
- Control: ISM-0520; Network access controls are implemented on networks to prevent the connection of unauthorised network devices and other IT equipment.
- Control: ISM-0534; Unused physical ports on network devices are disabled.
Logging and Alerts
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:
- A.5.25 Assessment and decision on information security events
- A.8.15 Logging
- A.8.16 Monitoring activities
More detailed controls in the ISM include (but are not limited to):
- Control: ISM-1030; A NIDS or NIPS is located immediately inside the outermost firewall for gateways and configured to generate event logs and alerts for network traffic that contravenes any rule in a firewall ruleset.
- Control: ISM-1228; Cyber security events are analysed in a timely manner to identify cyber security incidents.
Conclusion
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.