There are lessons to be learned from the Maricopa County Community Colleges breach. Learn them, dammit.
I generally do not write “lessons learned from [X breach] ” posts, because I seriously doubt people have really learned anything. Instead of headlines like “Lessons learned from…,” what we should be writing is, “If you don’t learn from this, then you’re an idiot and should never be allowed near consumers’ personal information.”
In any event, this time I’ve decided to post a “lessons to be learned” post in the hopes that some wise souls will actually take this to heart and help another breached entity avoid the unnecessary consumer frustration and outrage I see evolving in comments submitted by readers. So here we go…
The Maricopa County Community Colleges breach represents a #FAIL of epic proportions on so many levels. For those not familiar with background to the breach: the college’s version of the breach states that in January 2011, the FBI contacted MCCC’s IT department and alerted them that a database with PII was up for sale on the Internet. MCCC conducted an internal investigation and then arranged for an investigation by an outside firm (Stach & Lui). Sounds good, right? But an IT employee allegedly obstructed the outside firm’s investigation by withholding critical information. As a result, MCCC says, they did not discover certain security vulnerabilities and MCCCD leadership never even saw Stach & Lui’s report. Why they didn’t ask for it is another question, but they claim that the employee’s bad behavior led to lack of knowledge that was directly responsible for for the 2013 incident in which 14 databases wound up for sale on the Internet, affecting over 2,000,000. So… the first lesson that you’d better learn if you haven’t learned already:
Trust, but verify. You can’t have just one person who knows what’s going on because heaven forbid, they may not be honest or may be looking to hide their errors.
Note that there is an alternate version to MCCCD’s, posted by an anonymous commenter on this site who claims that the IT department begged MCCCD to be allowed to totally wipe the servers but their request was denied. Someday, hopefully, we’ll get to see some actual reports by independent investigators.
But there are other important lessons to be learned in terms of breach response. Under one of the posts about the breach on this site, it’s getting ugly in the Comments section. There are a few recurring themes, and those who counsel clients about breach response and breach notification letters should take note of what’s going on:
Do they know how you got their data? People are confused and suspicious as to why they are receiving letters from MCCC when they never attended classes there. There’s actually an explanation that makes sense and an MCCC spokesperson explained it to me on the telephone yesterday, but MCCC did not include it in their notification letter to those affected. Nowhere in their notification letter to those affected do they explain that many people who took extension courses online for re-certification or certification in their fields of study or work were actually providing their information to MCCC even if MCCC’s name did not appear as the provider of the course. Or that the individual may have been involved in a vendor relationship long ago. Had they included a “How we might have obtained your information” sentence or two in their notification letter, they could have prevented a lot of confusion, distrust, and anger.
When you (or your client) writes a notification letter, add this to your checklist: “Have you adequately explained the different routes by which recipients’ information might have wound up in your database?”
Who’s this credit monitoring service and why should I trust them with my personal info? Even though the notification letter specifically instructs those affected that MCCC has made arrangements to provide them with free credit monitoring services through IDintegrity.com and to go to that site, when people got to that site, they were unnerved by the appearance of the site and the lack of information on it. If you’ve already been burned and worried that your data has been stolen, you are understandably less likely to provide your SSN and details to any company, much less one whose site looks like it was a hastily thrown up site that could be a phishing site. And yes, I realize I’m being critical of IDintegrity.com’s web site. I’ve already spoken with them today to tell them what’s going on and what I think they need to do to develop that site more and reassure consumers that they are dealing with a legitimate service.
If you offer services to affected consumers at your expense as part of breach response or mitigation, consider how that firm will appear to those you are directing to their site. And if the site doesn’t inspire confidence and you don’t help the victims understand why they should trust the firm, that reflects back on you. And:
If you offer services to affected customers at your expense, have you ensured that the firm’s web site can handle a crush of people trying to sign up when the notification letters arrive?
In this case, IDintegrity.com’s site has been down or responding slowly, probably because of the number of people trying to sign up. It’s on MCCC and IDintegrity.com to ensure that consumers, already frustrated and angry, do not have a “healthcare.gov disaster” experience. MCCCD should be screaming at IDintegrity.com by now to get the site functioning properly.
I urged both MCCC and IDintegrity.com to provide me with statements that I could post to this site to address consumer concerns and frustration. I have not yet received them. In the interim, commenters are getting angrier and talk about lawsuits has started. Which brings me to the last lesson to be learned:
If you care about your reputation and consumer satisfaction, respond promptly.
Take advantage of opportunities sites such as this one provide and respond in the Comments section or send a statement to the site and ask them if they can post it or include it. Do not just fail to respond to angry or frustrated comments, as they will only increase if you don’t jump in to calm things down.
Now… will anyone actually learn those lessons? I guess I’ll have to wait to see. And yes, I know I omitted the obvious infosec ones like not storing a gadzillion years of Social Security Numbers. There really is such a thing as obvious, and if colleges don’t know that already, they’ll probably never learn it.
Amos - December 18, 2013
So here may be part of the ID Integrity problem:
They have different DNS records for the domain and for the www subdomain. Not using the “www.” prefix results in a spinning icon and the page never loads.
Even better, it’s run by Kroll and part of their company just got hacked https://www.idradar.com/news-stories/identity-protection/Kroll-Data-Hack-Exposes-Hundreds
Even more better, they have SSLv2 enabled: https://www.ssllabs.com/ssltest/analyze.html?d=www.idintegrity.com&s=188.8.131.52 and do not have TLS 1.1 or 1.2 enabled.
Of course, with Server 2008 R2, disabling SSLv2 and enabling TLS 1.1 and 1.2 does take a bit more work than clicking Next -> Next -> Install -> Finish
And for the finale, their banner shows they are running Tomcat 6.0.24, which has a number of vulnerabilities: https://tomcat.apache.org/security-6.html Tomcat v6.0.24 was released on January 21, 2010 per that link.
Here’s how it’s spelled: “Due Diligence”, in case they were wondering.