RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Tag: Identity Theft

This is how the #AnthemHack could have been stopped, perhaps

It has been just over a week since the #AnthemHack was made public.

Over this period, the main stream media and many of the bloggers and commentators,  as usual,  have been all over it.  Many have resorted to some not-so-well-thought-out (at least in my opinion as well as a couple of others1 ) statements such as “encryption” could have prevented it. Some have even faulted HIPAA for not mandating encryption of data-at-rest2.

Amidst all this, I believe there has been some good reporting as well, albeit very few. I am going to point to a couple of articles by Steve Ragan at CSOOnline.com here and here.

I provide an analysis here of perhaps how Anthem could have detected and stopped the breach before the data was exfiltrated. This is based on the assumption that the information published in Steve Ragan’s articles is accurate.

Let’s start with some known information then:

  1. “Anthem, based on data posted to LinkedIn and job listings, uses TeraData for data warehousing, which is a robust platform that’s able to work with a number of enterprise applications”. Quoted from here.
  2. “According to a memo from Anthem to its clients, the earliest signs of questionable database activity date back to December 10, 2014”. Quoted from here.
  3. “On January 27, 2015, an Anthem associate, a database administrator, discovered suspicious activity – a database query running using the associate’s logon information. He had not initiated the query and immediately stopped the query and alerted Anthem’s Information Security department. It was also discovered the logon information for additional database administrators had been compromised.” Quoted from the same article as above.

I went over to the Teradata site to download their Security Administration guide of Release 13 of Teradata Database (download link). I downloaded the guide for an older version from November 2009. I am assuming Anthem is using Release 13 or later and so, isn’t missing the features I am looking at.

Database logging can be challenging sometimes and depending on the features available in your database, the logging configurations can generate a lot of noise. This in turn, may make it difficult to detect events of interest. I wanted to make sure there weren’t such issues in this case.

It turns out TeraData is fairly good in its logging capabilities. Based on the highlighted content, it appears one should be able to configure log generation specifically for a DBA performing a SELECT query on a table containing sensitive data.

=======================================================

TD-Logging

=======================================================

There should not ordinarily be a reason for a DBA to query for sensitive data so this should have been identified as a high risk alert use-case by their Logging and Monitoring program.

I am assuming Anthem also has a Security Information and Event Management (SIEM) solution that they use for security event monitoring. Even a garden variety SIEM solution should be able to collect these logs and raise an immediate alert considering the “high risk” nature of a DBA trying to query for sensitive data.

This alert should have gone to someone that is accountable or responsible for security incident response. It appears that didn’t happen. This is symptomatic of a lack of “ownership” and “accountability” culture, in my view. For a case of this nature, I strongly recommend the IT owner (e.g. Manager or Director of the Database Team) being on point to receive such alerts involving sensitive data. Your Security Operations folks may not necessarily know the context of the query and therefore the high risk nature of it. I talked about this in a guest post last month. See the last dot point in this post.

As quoted at #3 above, it appears one of the DBAs discovered someone using his/her credentials and running that query. You certainly don’t want to leave it to the DBA to monitor his own actions. If this was a malicious DBA, we might be talking about a major breach caused by an insider and not a Advanced Persistent Threat (APT) actor as the Anthem breach appears to be.  But then, I digress.

If the high risk anomalous DBA activity had been discovered immediately through the alert and if appropriate incident response steps had been initiated, it is possible that Anthem may have been able to stop the breach before the APT actor took the data out of the Anthem network.AnthemHack Tweet

So, if we come to think of it, some simple steps of due diligence in establishing security and governance practices might have helped avoid a lot of pain to Anthem not to mention a lifetime of hurt to the people and families impacted by the breach.

Here then are some take-aways if you would like to review your security program and want to make some changes:

  1. You may not need that shiny object. As explained above, an average SIEM solution can raise such an alert. We certainly don’t need that ‘big data” “analytics” solution costing 100s of thousands or millions of dollars.
  2. Clarity in objectives3. Define your needs and use cases before you ever think of a tool or technology. Even if we had a fancy technology, it would be no use if we didn’t identify the high risk use-case for monitoring the DBA activity and implement an alert for it.
  3. Process definition and speed of incident response. People and process aspects are just as important (if not more than) as the technology itself. Unfortunately, we have too many instances of expensive technologies not being effective because we didn’t design and implement the associated people/process workflows for security monitoring and timely incident response.
  4. Ownership and accountability. I talked about this topic last month with a fair amount of detail and examples. While our Security Operations teams have their job to do in specific cases, I believe that the IT leadership must be “accountable” for security of the data collected, received, processed, stored or transmitted by their respective systems. In the absence of such an accountability and ownership culture, our security monitoring and response programs will likely not be effective.
  5. Focus on quick wins. If we look at our environments with inquisitive eyes and ears, most of us will likely identify quick wins for risk reduction. By quick wins, I am referring to actions for reducing higher risk levels that we can accomplish in weeks rather than months, without deploying a lot of resources. Not all of our risk management action plans have to necessarily be driven by formal projects. In the context of this Anthem example, it should be a quick win to implement an alert and have the database manager begin to watch for these alerts.
  6. Don’t accept pedestrian risk assessments and management. If you go back and look at your last risk assessment involving a sensitive database for example, what risks were identified? What were the recommendations? Were these recommendations actionable or some “template” statements? Did the recommendations identify quick-win risk reduction opportunities? Did you follow through to implement the quick wins? In other words, the quality of a risk assessment must be solely determined by the risk reduction opportunities that you were able to identify and the outcomes you were able to accomplish within a reasonable period of time. The quality of paper deliverables, methodology etc. are not nearly as important, not to say that they don’t matter.
  7. Stay away from heavy weight security frameworks. We talked about this last year. I’ll probably have more to say about it in another post. Using #AnthemHack as an example, I plan to illustrate how a particular leading security framework wouldn’t be very helpful. In fact, I believe that using heavy weight security frameworks can be detrimental to most security programs. They take a lot of time and precious resources not to mention the focus away from accomplishing risk reduction outcomes that truly matter.
  8. Effective governance and leadership. Last but not the least, the need for leadership and governance should come as no surprise. None of the previous items on this list can be truly accomplished without an emphasis on governance and leadership starting right at the board level and across the executive leadership.

I hope the analysis and recommendations are useful to you.

Remember, while the techniques employed by APT actors may be advanced and persistent, the vulnerabilities they exploit are often there only because we didn’t do some basic things right or perhaps we made it too hard and complicated on ourselves to do it right.

References for additional reading

1 Why even strong crypto wouldn’t protect SSNs exposed in Anthem breach , Steven M. Bellovin

http://arstechnica.com/security/2015/02/why-even-strong-crypto-wouldnt-protect-ssns-exposed-in-anthem-breach

Even if Anthem Had Encrypted, It Probably Wouldn’t Have Helped, Rich Mogull

https://securosis.com/blog/even-if-anthem-encrypted-it-probably-wouldnt-have-mattered

 

2 I like the fact that the HIPAA Security Rule is not prescriptive, except… , Kamal Govindaswamy

http://rnc2.com/blog/regulatory-compliance/hipaahhitech/like-fact-hipaa-security-rule-prescriptive-except/

 

3 Security Analytics Lessons Learned — and Ignored!, Anton Chuvakin

http://blogs.gartner.com/anton-chuvakin/2015/02/09/security-analytics-lessons-learned-and-ignored/

FTC delays enforcement of Identity Theft Red Flags Rule to 12/31/10

FTC announced earlier this morning that it is delaying enforcement of the Red Flags Rule to 12/31/10 pending expected legislation by Congress that would affect the scope of entities covered by the Rule. As I wrote in my blog just a few days ago, organizations representing physicians, lawyers and  accountants have already contested that the Rule shouldn’t apply to them. I wrote that the previous deadline of 06/01/10 was probably too close for FTC to move it again. I guess it is never too close!

Let us wait and watch for next steps from the Congress now!

Identity Theft Red Flags Rule – Is the 06/01/10 deadline looking good?

Frankly, I have lost count of how many times FTC has moved the deadline already (see my related post from 2009).  This time, however, I think the deadline is too close (about a week out at the the time of this blog post) that I think the rule is finally going to take effect.  Again, I may be proved wrong… let us wait and see!

Aside from the rule taking effect, enforcement of the rule is going to be interesting to watch! Just this past Thursday,  AMA and two other physician groups filed a suit contending that the rule shouldn’t apply to physicians.  The rule had already been contested by Lawyers and Accountants.

AMA’s suit comes after several back-and-forth discussions with FTC over the last year or so. It looks like AMA wasn’t obviously convinced that the rule should apply to physicians despite what I thought was this compelling argument by FTC.

AMA’s main contention has been that hospitals and physicians are already subject to HIPAA Security and Privacy Rules and therefore the Red Flags Rule shouldn’t apply to them. From my experience, however, I believe that most HIPAA Security/Privacy Programs may not be effective against Identity Theft tricksters of today. I would recommend that health care providers implement a risk-based, written Identity Theft Prevention Program to supplement the Administrative Requirements (§ 164.530) of the HIPAA Privacy Rule and Administrative Safeguards (§ 164.308) of the HIPAA Security Rule.

I think the below quote from FTC’s letter sums it up well:

“The Rule is designed to prevent identity theft primarily by ensuring that organizations are alert to signs that an identity thief is using someone else’s identifying information fraudulently to obtain products or services, including services such as medical care. Thus, the Red Flags Rule generally complements rather than duplicates the HIPAA data security requirements.”