You are here

You are here

Panama Papers: 5 principles that could have prevented a data breach debacle

Greg Bledsoe Lead Technical Advisor , Unbounded Enterprise

The Panama Papers were shocking. It wasn't the revelation that the wealthy keep some of their assets hidden away. It was that billionaires didn't do the most basic due diligence regarding the ability of Mossack Fonseca to keep their secrets.  

I'm not here to debate the ethics of Mossack Fonseca's business. My interest is in cybersecurity, and therefore I am shocked not by what Mossack Fonseca did, but by what it didn't do: make any real effort to protect its digital assets. 

Certainly, I think it's a good thing that a company that helped people stash money that represents corruption, cronyism, bribery, and barbarism has been exposed. On the other hand, some of what a company such as Mossack Fonseca does can be perfectly legitimate and ethical. For instance, if you are a person of wealth who lives in a country where kidnaping the people you hire to represent your interests is a revenue stream, it makes sense to keep their identities secret.

With that in mind, what can we learn from Mossack Fonseca's mistakes so that we don't repeat them?

We're talking terabytes

The purloined data taken from Mossack Fonseca amounted to 2.6TB. How is it possible to remove 11.5 million documents from either a physical or digital environment and not have that noticed for over a year? The amount of time it would take to download 2.6TB suggests that the intrusion was of long duration, quite possibly years.

Most of the documents were in the form of emails, and so it seems likely that Mossack Fonseca's email server was breached and was not encrypted—or at least not encrypted in any competent way. In fact, security professionals who have been scrutinizing the systems have concluded that there wasn't a single important cybersecurity principle that Mossack Fonseca didn't violate.  

Here are five fundamental security principles that could have helped Mossack Fonseca:

1. Separate your services and isolate them as far as possible

Mossack Fonseca ran everything, including mail and web services, on one Windows server, not even using virtual machines, and it even advertised that clients could access all their data from one location. The company might as well have hung a "Hack me" sign on its homepage!    

2.  Keep your software updated 

Mossack Fonseca's shortcomings here are almost too many to catalog. It was running a version of Outlook Web Access that hadn't been updated since 2009. The 2013 version of Drupal that it used had at least 25 known vulnerabilities, and WordPress, possibly the most frequently targeted and exploited CMS in existence, hadn't been updated in three months.    

3. Configure and harden externally available software and protocols carefully

The protocol support for the server, far from carefully tuned, was vulnerable to every SSL vulnerability since SSL v2.0, meaning captured sessions could probably be decoded using techniques such as DROWN to capture legitimate login credentials. But that was hardly necessary given the exploitable nature of all the software running on the server and the loose configuration of the web server itself, which would allow directory listing and traversal.

4. Run processes with minimal necessary privileges

A company that was so careless about so many security issues probably granted administrative privileges willy-nilly. That's just a guess, but quite frankly anything else would come as a surprise. 

5. Review logs frequently and audit access to sensitive data

The company became aware of the breach, and even notified clients and Panama's attorney general, about a week before the leaks went public. But as I noted earlier, the breach probably unfolded over the course of years, with no one noticing.

No E for effort here

The unavoidable conclusion is that there was absolutely zero security awareness and no effort at all put into sustained security and client confidentiality at a highly secretive firm. Mossack Fonseca's employed no encryption when it should have been using zero-knowledge encryption, which would protect the data even from an administrative-level breach of the server.

Given the weakness of Mossack Fonseca's security, any hobbyist penetration tester could have pointed the lamest vulnerability scanner at and found an arbitrary code execution bug and a SQL injection flaw, just in Drupal alone, within minutes.   

Takeaways from a sad story

This story offers many teaching opportunities. Here is a sampling: 

  • Never assume competence. Vet your partners carefully, and the more sensitive the data that flows between you, the more thorough your due diligence must be.  
  • Ask questions about security practices. Does the company perform daily log reviews? Does it have a schedule for security patching? Does it encrypt data at rest, and if so, how well? With zero-knowledge encryption? By the way, if the company has no answers, you have your answer.  
  • Give their systems and processes a look, preferably with permission and a full audit from competent professionals. As this case shows, even a cursory examination of the publicly available side of a potential partner's systems can raise red flags telling you to proceed with caution.  

No turning back on security as No. 1

The days when we had the luxury of treating security as an afterthought are over. Security must be among the foremost things on our minds, and the consequences of our failures can reach to the level of nation-state impact. What that means is revamping all of our IT practices. That will take grass-roots support and awareness, along with strong leadership that draws attention to the cost of failure.

Start doing your part by sounding off below with your thoughts and ideas on the topic.

Keep learning

Read more articles about: SecurityInformation Security