Tag Archives: SAP

The Challenges Of Staying Safe

USIS, a firm that used to do background checks for the U.S. Government was hacked in 2013.  They did not provide many details of what happened, but the government cancelled $2.5 Billion in contracts and they laid off  2,500 employees.  It also pushed the parent company dangerously close to default on $2 Billion in loans and caused Moody’s to downgrade the company.  This is the potential impact of a security breach. (see here, here and here)

Now some details are coming out (see article).  Apparently, the company uses SAP, a very popular enterprise software product that is both very complex and very powerful.  In USIS’s case, that software was hosted by a third party.

A report that came out this weekend says that it is likely that the attackers compromised that SAP software and that is how they were able to access the USIS data.  The details of how exactly they did this are still unclear, but it should act as a reminder for all businesses:

  • Patching software is very important.  As the complexity of the product grows (like SAP), the odds of bugs goes up and some of them could be fatal.  According to other reports, many SAP users do not patch their software for fear of breaking something.  We don’t know if a missing patch allowed the hackers in at USIS.
  • Evaluate the security of third party providers.  If you outsouce operations, you are still the one that your customers (and the law) will go after.  I doubt their outsource provider had a $2.5 billion dollar insurance policy and even if they did, that would only cover the lost contract, not USIS’s reputational loss.
  • Programs like SAP tend to be customized.  A lot.  Vendors will not provide patches for your customizations.  Planning for how to take care of that is not easy.  How your customizations interact with the vendor’s code is often complex.  In general, internally developed software is tested significantly less rigorously than commercial software since it only has one customer.  Think about how buggy commercial software is.

Hopefully, USIS will pull through this, but there is no way to recover that business unit.  In fact, they may lose other, only marginally related business due to reputational problems.

I will leave you with three questions:

  1. Are you confident that your software patching process covers all of your software and is applied quickly enough?
  2. Do you evaluate the security of third party providers or just the cost.  Overall, less than 25% of companies evaluate vendor security and of the ones that do, many of those are a paper exercise?
  3. How do you test and patch your internally developed software?  I do not mean functional testing (that it works like it is supposed to); I mean testing to make sure that a hacker can’t break in using it.

The lack of an adequate answer to these three questions cost USIS at least $2.5 billion and maybe their company.