Mitigating your own Mossack Fonseca
THE APRIL 2016 data breach at law firm Mossack Fonseca, which led to the publication of client information in documents known as the Panama Papers, has put the spotlight on data security in law firms. Robert Cox discusses how business managers and IT teams can work together to assess risks and determine whether IT recommendations should be undertaken.
The Panama Papers contained 40 years of history, and included:
- 4.8 million emails
- 2.2 million PDFs
- 1.1 million images
- 320,000 documents
How the information was leaked will probably never be known. However, what has been reported is the following:
1. Aspects of the Mossack Fonseca email system had not been updated since 2009. The version of the system in use had known security holes, which have been subsequently fixed byMicrosoft.
2. Emails sent from Mossack Fonseca to their clients were not encrypted. It is possible that intermediaries could have read the contents of the emails.
3. The Mossack Fonseca Client Information Portal was last updated in 2013 and had at least 25 known security holes. These security holes made it possible for someone to access all of the data in the client information portal.
The possibility of an employee being involved in the data breach should also not be discounted, although Mossack Fonseca has publicly indicated that it was not “an inside job”.
What could have been done to prevent the breach occurring?
If the source of the data breach was one of the above issues, at first glance prevention would seem quite simple. Ensuring that each product was running the latest software would have been enough to prevent the problem.
But the reality is never that simple, is it? Mossack Fonseca’s IT system is likely to involve many hundreds of physical devices including servers, networks, PCs, laptops and mobile phones. Each device would run software from many different vendors. And each one of these systems requires ongoing software updates and configuring – a significant ongoing investment.
Some firms take the chance that cyber security events won’t occur and run their systems without incident. Others take a more cautious view and treat the cost of this ongoing investment as an insurancepremium.
A simplified risk assessment processes can and should be used to assess whether an IT recommendation (eg, upgrading a server, implementing new security procedures or technology) should be accepted. You need to weigh up the cost and benefits of the recommendation against other priorities for yourorganisation.
Three steps for assessing IT recommendations
The process that I use is as follows:
1. determine the cost of the ‘insurance premium’, meaning the di erence between the cost of doing nothing and what is being recommended;
2. summarise the potential events that are being mitigated; and
3. determine the nominal value on the cost to the business if the events occur (this assessment needs to be completed by the Partners, business owners or management team). In this context the impact on an organisation’s reputation needs to be included.
Once this information is available, a short meeting between the IT and management teams will quickly be able to determine if a recommendation is an obvious go, an obvious no-go or a genuine 50/50 decision.
This process has deliberately avoided nominating the probability of the event occurring. This is because IT specialists find it impossible to quantify a risk beyond broad high, medium, and low categories. However, IT specialists do find it easy to compare two events and nominate which is more likely – this information can then be used to assist in determining whether a recommendation should be accepted.