Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
Anthem Refuses To Let Inspector General Conduct Full Security Audit
Newest First  |  Oldest First  |  Threaded View
Hank0639
50%
50%
Hank0639,
User Rank: Apprentice
3/19/2015 | 3:59:22 PM
Re: Surprised...yet not.
I agree with you. The person who wrote the response probably was told "Just say this" and does not understand how their security infrastructure works.
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
3/9/2015 | 10:47:18 PM
Re: What if we frame it in terms of the 4th Amendment?
To be clear, I don't fault the gov't for wanting to be involved here -- and if circumstances were to arise where they would force an audit, so be it.  And, of course, if Anthem is found to have engaged in wrongdoing, sure, come down on them.

It's really a matter of timing.  Once the entire matter is resolved -- legally and all -- then Anthem should welcome collaboration with government partners on cybersecurity.  When they're facing fines and lawsuits and such, though, one can hardly blame them for sticking to the policy line.

I just think this particular story has gotten more traction than it should have.
Meleon42
50%
50%
Meleon42,
User Rank: Strategist
3/9/2015 | 11:13:26 AM
Re: Surprised...yet not.
I am surprised they are not at a level where their bank requires a yearly PCI audit by a independent QSA
Paladium
100%
0%
Paladium,
User Rank: Moderator
3/9/2015 | 7:01:43 AM
Re: What if we frame it in terms of the 4th Amendment?
Joe:  For the record I am not for the Government sticking its nose into private businesses or our lives.  However, they should be a watchdog that comes down hard when businesses cause damage to a large number of customers due to its negligence.  Failure to properly secure customer data, failure to properly staff security with the people, tools and training to monitor and protect that data, are all justifications to place a big boot up Anthems butt.

In theory customers should be able to take their business to another health care provider, thereby hitting Anthems bottom line sufficiently to force them to get their collective heads out of their butts and do the right things to protect customer data.  But in practice moving to a different health care provider is not such a simple thing to do for many, many reasons I'll not go into here.

Maybe a good idea to consider is to limit the size of health care providers to force more competition in the market.  The more competition, the more options customers would have.  That would naturally drive down costs due to market forces.  If a provider screws up customers could easily walk away.  But until that day comes, if ever, we will continue to have these large breaches, customers will have limited choices, and big government will continue to intrude unfortunately.
Joe Stanganelli
0%
100%
Joe Stanganelli,
User Rank: Ninja
3/8/2015 | 11:34:07 PM
What if we frame it in terms of the 4th Amendment?
This really shouldn't shock anyone in the industry.  I wonder how many of these notoriously libertarian InfoSec specialists and pundits would assent to a warrantless government search or inspection.  But because it's Anthem (a company that potentially faces fines and worse from this breach), we should poo-poo them when they decline the government wanting to stick its nose in?

Whatever.
SecOpsSpecialist
50%
50%
SecOpsSpecialist,
User Rank: Moderator
3/8/2015 | 10:46:09 PM
Re: Surprised...yet not.
Paladium,

Yes, they are bound by HIPAA law, as well as the HITECH Act and the OMNIBUS Rule, but because they are an insurance company they are also required to follow PCI-DSS, which mandates that all payment systems be segregated on the network away from the customer data and ALL data, not just credit card data must be encrypted.

HIPAA does not yet require that data be encrypted, it is an addressable issue. However, if a company accepts payments using credit cards, or banking information, which Anthem does, seeing how large they are, they are bound by PCI-DSS.

Interestingly enough this is what the PCI-DSS council has to say,

Q: What if a merchant refuses to cooperate?
A: PCI is not, in itself, a law. The standard was created by the major card brands Visa, MasterCard, Discover, AMEX and JCB. At their acquirers'/service providers' discretion, merchants that do not comply with PCI DSS may be subject to fines, card replacement costs, costly forensic audits, brand damage, etc., should a breach event occur.

For a little upfront effort and cost to comply with PCI, you greatly help reduce your risk from facing these extremely unpleasant and costly consequences.

Here's a great article to take a look at for PCI-DSS rules and FAQs: https://www.pcicomplianceguide.org/pci-faqs-2/
Paladium
50%
50%
Paladium,
User Rank: Moderator
3/8/2015 | 3:56:02 PM
Re: Surprised...yet not.
I have to chuckle at this whole incident. I would bet lunch that they were using HIPPA standards as their security framework. Do I have any takers?


From my experience on the finance sector side, the OCC has the ability to take over a bank for clear and flagrant non-compliance of their directives and requirements. I do not have Health Care industry experience, however, I wonder if there is an equivalent agency with similar authority on the Health Care side. If so, maybe it's time the feds ratchet up their language to force Anthem to get their act together.
SecOpsSpecialist
50%
50%
SecOpsSpecialist,
User Rank: Moderator
3/6/2015 | 2:40:25 PM
Surprised...yet not.
I am honestly not surprised that Anthem would refuse after the OIG said that they were failing the last time. But what really made me question things was where they said "it would cause network outages and we would need to turn off our anti-virus". Forgive my ignorance here, but since when is turning off anti-virus going to lead to a network outage exactly? Unless the anti-virus solution they use is what supports the network (which it shouldn't I might add), then they are blowing smoke and no one in the organization really has any idea about what it takes to be in Security.

Yes, they won us over with the whole fact that they notified us before they were required to, but it is a touch suspect as to why they wouldn't let the OIG back in a second time. I personally think it's because they know they would fail a second time and don't want to run the risk of that occurring again. Honestly, they need to let someone in there with the ability to fix their issues and put down the law of the land and say "look, this is unsafe, this needs to be fixed and here's how we do it."

Anthem is big enough where they can afford to have security controls in place, but it appears that they are lazy or refuse to comply to be able to do so.
GonzSTL
50%
50%
GonzSTL,
User Rank: Ninja
3/6/2015 | 1:13:30 PM
Anthem's Refusal
The federal bureaucracy is maddening! I need to get this straight in my head. From what I understand, HIPAA enforcement and compliance reviews fall under the US Department of Health & Human Services Office for Civil Rights. So why is the US Office of Personnel Management's Office of the Inspector General wanting to conduct the vulnerability scans and compliance tests, and not the US Department of Health & Human Services' Office for Civil Rights, which is required by HIPAA and HITECH to enforce the rules? In fact, the USHHS OCR developed the protocol to be used to measure compliance efforts, and even established a pilot audit program to assess covered entities. In the pilot program, USHHS OCR contracted KPMG to perform the initial audits, so it is possible that future audits could be delegated to other entities. So has the compliance audit function been seconded to the US OPM OIG by the USHHS OCR?

Now the issue of auditing post-breach is a little touchy. Anthem is undoubtedly a beehive of activity these days as they try to recover from the breach. I imagine that the InfoSec, and IT folks are being worked to the bone, in the effort to clean up and fix whatever issues they have. If I were in Anthem's shoes, I wouldn't want any external people poking around while all that is going on, and diverting precious resources from their already daunting task to the audit process. However, I do understand the need to audit them after remediation.
Technocrati
50%
50%
Technocrati,
User Rank: Ninja
3/5/2015 | 7:04:16 PM
Just Who Exactly is Running Things ?
I simply cannot pass this news up. I cannot believe what I have just read.   Anthem which now holds the infamous label of "King of all Breeches" refuses to to allow vulnerability scans and compliance tests post-breach !

This is so ludricious that I can even fathom a response.

Apparently there are no laws to enforce them to comply ?   Who is exzactly running things ?    The Government or business ?

That was purely rhetorical.     I know the answer.


Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: He hits the gong anytime he sees someone click on an email link.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12262
PUBLISHED: 2020-11-27
Intelbras TIP200 60.61.75.15, TIP200LITE 60.61.75.15, and TIP300 65.61.75.15 devices allow /cgi-bin/cgiServer.exx?page= XSS.
CVE-2020-29129
PUBLISHED: 2020-11-26
ncsi.c in libslirp through 4.3.1 has a buffer over-read because it tries to read a certain amount of header data even if that exceeds the total packet length.
CVE-2020-29130
PUBLISHED: 2020-11-26
slirp.c in libslirp through 4.3.1 has a buffer over-read because it tries to read a certain amount of header data even if that exceeds the total packet length.
CVE-2020-26936
PUBLISHED: 2020-11-26
Cloudera Data Engineering (CDE) before 1.1 was vulnerable to a CSRF attack.
CVE-2020-29042
PUBLISHED: 2020-11-26
An issue was discovered in BigBlueButton through 2.2.29. A brute-force attack may occur because an unlimited number of codes can be entered for a meeting that is protected by an access code.