Skip to content ↓ | Skip to navigation ↓

According to the Associated Press, the attackers who targeted and exfiltrated more than 80 million customer records from Anthem Inc, were able to commandeer the credentials of at least five different employees.  We know from Anthem themselves that at least one admin account was compromised, as the admin himself noticed his credentials being used to query their data warehouse.

Looking at job postings and employee LinkedIn profiles it appears that the data warehouse in use at Anthem was TeraData. By doing some quick searches on LinkedIn I was able to find more than 100 matches for TeraData in profiles of current employees at Anthem, including, CXOs, system architects and DBAs. Discovering these employees emails is trivial and would be the first step attackers could take to identify who to target for spear-phishing campaigns.

linkedin

Once they are able to compromise a few high level employee systems through a phishing campaign either through malware attachments or through a browser exploit, gaining access to a user’s database credentials would be trivial. This would be where the “sophisticated malware” that is being reported would be utilized, if the malware was designed specifically for this attack it would evade most anti-virus products.

What may be a key weakness here is that it appears there were no additional authentication mechanisms in place, only a login/password or key, with administrative level access to the entire data warehouse. Anthem’s primary security sin may not have been the lack of encryption, but instead improper access controls. Although it appears the user data was not encrypted, in Anthem’s defense if the attackers had admin level credentials encryption would have been moot anyway.

I should note that TeraData provides quite a few security controls, including encryption, as well as additional data masking features, even specifically called out for protecting Social Security Numbers and related data. So odds are the actual vulnerability here is not in the software, operating system or hardware, but how the system and access controls were configured based on business and operational requirements.

From what we know so far on the prevention side, the access control issue is troubling for many organizations, as it not only increases risk with cases of phishing, but also with regards to insider threats, or simple mistakes by users with high level access. Many organizations have loose access controls, so Anthem is not alone.  Using basic frameworks such as the 20 Critical Security Controls, organizations should evaluate #12 “Controlled Use of Administration Privileges”and #15 “Controlled Access Based on the Need to Know”. Attackers will get into the network, if they do what data will they have access to in your organization?

The Anthem case also shows the importance of monitoring database activity, if the admin had not noticed his credentials were being used it may have taken longer for Anthem to respond and additional data could have been compromised. Tools like Tripwire Enterprise provide automated monitoring of popular enterprise databases and when paired with correlation rules with log intelligence tools like Tripwire Log Center administrators can flag suspicious activity such as access at odd hours and other indicators.

Tripwire CCM Express Free Trial
  • Good insight Ken. With regards to your statement "…in Anthem’s defense if the attackers had admin level credentials encryption would have been moot anyway." That is not entirely true. Using a robust encryption + access control solution like Vormetric would give them the ability to prevent privileged users like admins or root level accounts from being able to decrypt sensitive data encrypted by Vormetric.

    This is accomplished by specifying policy with Least Privileged access rules that lock down readability and decryption to only the specific users (or service context) and/or specific trusted binary processes that require access for data ingestion and processing. When a control like Vormetric is in place the typical rules wrapped around sensitive data limit all types of privileged user credentials to viewing metadata only or to no readability at all. This makes it possible to significantly reduce the insider threat to an organizations sensitive data as well as virtually eliminate the potential damage that can ensue when an organizations privileged users credentials are compromised via bad actors as in the case you detail around the Anthem breach.

    Unfortunately Anthem was not employing a sound Defense in Depth strategy by leveraging crucial security controls such as Vormetric and Tripwire to protect their sensitive data and system configurations. Perhaps if they recover from this in decent shape they will be looking into ensuring their security posture is in better shape :-)

  • Mahmood

    Interesting post Ken. This must be a terrible time for the folks at Anthem and their members. We will eventually learn about how it happened and test your theory of how it could've happened. Many years ago I was part of the TeraData technical consulting team and still have plenty of colleagues there so glad to see that you mentioned the native security controls of the DB.

  • AJA

    What other indicators of database compromise could there be other than activities during off hours? When you have admin credentials and a backdoor into the network, you can do whatever you want when you want and the traffic/activity looks like normal DBA activity. Unless the DBA is monitoring his own use of a database in near term windows of time, this type of attack would be very difficult to spot.

    • AJA – "Unless the DBA is monitoring his own use of a database in near term windows of time, this type of attack would be very difficult to spot."

      80 million records in "the database" = approximately 35GB uncompressed text when exported based on benchmarks we have from past breaches in healthcare / insurance.

      Two primary paths of data extraction 1) off the local DB server, 2) off the compromised DBA / Admin box.

      Two primary methods of extraction of the data from the DB. 1) one query returning all results. 2) multiple queries returning smaller sets of data, randomized in row counts and times.

      The third option people aren't talking about is that the database extract was on a system other than the db, so no db extraction was needed. This commonly occurs during ETL processes and EUCs by DBAs.

      Either way, 35GB of CSV data would compress to around 1.7GB, (if one file), which could easily fly under the radar without advanced monitoring controls.

  • Nitin Sukhija

    Good post Ken.