At the International Association of Privacy Professionals (IAPP) Privacy Security Risk 2017 Conference in San Diego California last week the IAPP interviewed information security specialist Jason Straight who is the chief privacy officer at UnitedLex about the Equifax breach. The interview raises interesting issues around security practices, the need for teamwork and coordination and the ability for organisations to learn from the publicly known facts of Equifax’s breach. The insights are relevant for legal counsel, security personnel and CEOs who may be concerned about the buck landing with them.
Useful links for those who are interested are the written testimony and the Apache Struts public response.
The fundamental obligation under Australian Privacy Principle 11 is to take all reasonable steps to keep personal information secure. Equifax provides a case study in the risks in meeting this obligation.
Was it all the fault of one unnamed employee?
In his written testimony to the US Congress the former Equifax CEO Richard Smith stated that the failure by an a single unnamed employee to apply a critical patch to the Apache Struts software used by Equifax in its dispute resolution web-facing application was the cause of the breach which exposed the credit records including sensitive information and social security numbers of over 145 million Americans plus some UK and Canadian residents.
This interview suggested that the fact that the methodology relating to the application of a patch and the failure to follow up whether the patch was applied was less than best practice, and if the entire security of the organisation relied on one employee responding to an email request, then that is the cause of the breach, not the action or inaction of the employee.
The relevant facts are that this was a patch notified by US CERT to organisations as being critical to their security. The group within Equifax receiving this notice emailed the notification asking applicable personnel to patch Apache.
The facts as set out in the testimony are that the vulnerable version was not identified or patched. The only follow up to this email was a reliance on uniform security scans failing to detect vulnerabilities. Suspicious network traffic on the relevant website was not discovered until four months later.
This suggests that Equifax’s security protocols were inadequate, and were the cause of the breach rather than the inaction of a single employee.
What can my organisation learn from this?
This gives other organisations an opportunity to consider how they can learn from Equifax’s approach to patches.
Firstly, what is the policy in applying and testing patches so that vulnerabilities are remediated on a regular schedule?
In the Equifax evidence, it is stated that one of the security people emailed the unnamed employee to instruct them to apply the patch. Use of email to a single individual rather than an alternative approach such as the use of a ticketing system (as is often used within IT systems) would have ensured that the organisation was not reliant on the response of one individual. It would also have allowed a number of individuals to consider whether the application of the patch to the Apache Struts software was required, and would also have allowed a number of others who were involved in monitoring and responding to the ticket to follow-up to ensure that the patch had been applied. It is more likely someone would have identified the version that needed to be patched.
While much of the interview is highly technical, if you are interested you can listen here.
Does your system architecture help or hinder you?
The Apache Struts software was used as part of the web-facing public access dispute resolution centre where customers could upload information about disputes to allow for their resolution. A question that is raised is how does a breach of the dispute resolution interface allow direct access to the key data held by Equifax? Following the Equifax breach, Apache made a public statement with five recommendations including:
4. Establish security layers. It is good software engineering practice to have individually secured layers behind a public-facing presentation layer such as the Apache Struts framework. A breach into the presentation layer should never empower access to significant or even all back-end information resources.
As a matter of governance, a system should be structured in such a way that a breach of a web-facing part of a system should not allow a hacker to then access core secured data.
This appears to be a fundamental defect in the structure, based on the information that is publicly available about the Equifax breach.
This raises the question for boards and executives who often leave the technical issues to the IT function as to whether those types of system architecture issues have been addressed. If there is a breach of the outer wall does it allow the hackers to go straight to the core?
How is this relevant to Australia?
As we prepare for mandatory breach notification in February 2018, considering how to prevent breaches in the first place is part of the preparation. Asking questions such as ‘what is my patching protocol’ and ‘how do I monitor my systems?’ together with ‘how is my architecture designed to prevent access to my most sensitive data?’ is a task that boards and executives outside of the IT function should be undertaking. These would form part of the privacy governance framework, and our privacy professionals can help you in developing and implementing such frameworks.
Author: Lyn Nicholson
* On 30 November 2017, we will be delivering a seminar 'Key issues in data protection and privacy' in our Brisbane office. Please click here for more information and to RSVP.
Lyn Nicholson, General Counsel
T: +61 2 8083 0463
Trent Taylor, Partner
T: +61 7 3135 0668
Dan Pearce, Partner
T: +61 3 9321 9840
The information in this publication is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavour to provide accurate and timely information, we do not guarantee that the information in this publication is accurate at the date it is received or that it will continue to be accurate in the future. We are not responsible for the information of any source to which a link is provided or reference is made and exclude all liability in connection with use of these sources.