Category Archives: Breach Response

Knock, knock. Who’s there? No one.

As we mentioned in our last post, trying to contact and confirm organizations that have reportedly been breached can be time-consuming and frustrating. When that organization is a hospital and we cannot reach anyone or get a response, it’s especially concerning.

Yesterday, I tried to contact [Redacted] Hospital. I went to their site for contact info, but they had no phone directory or email directory by department or office. So I called their main number and asked for IT. I was sent to voicemail. I hung up, called back, and asked the operator to stay on the line until I got through to a person in IT or the Privacy Compliance Officer. Eventually, I heard a male voice, who told me that he was the “service desk.” The “service desk” was not IT. I subsequently learned that they are an outsourced IT partner.

I explained that the hospital had apparently suffered a hack via SQL injection and I could email him a link to the data so that IT could investigate and take action to secure the server better. I gave him my name, email address, and phone number, and told him that I was with the Open Security Foundation.

He told me didn’t have an email address for me to email him the link, but that he would open a ticket. He had no email address to give me? Seriously? On the one hand, not accepting an emailed link from a stranger makes good security sense, but on the other hand, how could I send them data and details without an email address? I usually paste some dumped data into the body of the email with the link to the full paste. So now, not only could I not directly reach the responsible parties, I could not even send them any data to pursue.

The service desk employee opened a ticket and sent me a copy of it. That was almost 24 hours ago. The two individuals he directed the ticket to were the hospital’s System Administrator and Technical Analyst, neither of whom have contacted me by email or phone, even though my contact details were in the support ticket.

In this case, the data were dumped on the Internet at the beginning of December 2012, so maybe they know already, but since the data are still live and in any event, they have no idea what data I called about, maybe they don’t know. The data do not appear to be patient data, but they are personally identifiable information. And if those data were vulnerable, what other data might still be vulnerable?

Another staff member from OSF also tried to reach them last night – through the hospital’s on-site contact form. That form doesn’t have a pull-down menu to direct the message to particular subjects or departments.

It shouldn’t be so difficult to contact the responsible party when there’s been a breach. So here are some “best practices” recommendations for HIPAA-covered entities to add to their checklists:

1. Provide a dedicated phone number and email address to report privacy or security breaches and prominently post those contact details on the home page of your web site.
2. Ensure that the phone number and email address are monitored 24/7/365.
3. Establish a written policy that all such contacts or messages are to be acknowledged within 1 hour.
4. Follow up and let the individual who reported the problem know what steps you have taken.
5. If you use a contact form on your web site, have a pull-down menu for subjects, and have one of them be “Privacy or Security Concern.”

Every hospital tells patients that they take the privacy and security of their information seriously. I wouldn’t believe them if they don’t respond to security alerts and make people jump through hoops just to try to inform them that they may have had a breach involving personal information. And I certainly wouldn’t believe any hospital that doesn’t even return a phone call when you have left them a message that they may have a security problem with their public-facing server.

Responsible hospitals should facilitate reporting privacy or data security concerns. So what has your organization done to facilitate reporting of breaches?


Behind the scenes of doing the right thing

From time to time, the Open Security Foundation is contacted about security vulnerabilities and data breaches that have yet to be made public. We always strive to handle each report in the most appropriate way possible and wanted to share with you an example from last year. In March of 2011, we had a breach anonymously submitted to DataLossDB without any further way to contact the submitter, but enough information for us to work on verifying and relaying the issue to the affected company.

From the initial look of things, it appeared that job applicants’ names, addresses, phone numbers, email addresses, and resumes were accessible and even editable on the Computer Sciences Corp (CSC) website without requiring a login. You could browse to their resume website and increment the ResumeID=x field in the URL making it trivial to enumerate and access approximately 300 applicants personal information.

We contacted CSC as soon as the incident was submitted to see if they would speak to us or at least provide a response. At first it appeared that they ignored our emails and we were getting a bit concerned as several days went by without a response. However, once we escalated to a phone call, we were then able to discuss the issue with the proper contacts and the vulnerability was fixed within 48 hours. We also spoke with their lawyer and they stated that they would notify those affected and get back to us with a statement.

Here is the statement from CSC:

————————– Original Message ————————–

Last month, CSC was contacted by Open Security Foundation (“OSF”) who had received an anonymous tip that an Internet-accessible Web site CSC had set up for a recruiting effort had security issues. Upon internal investigation, it was determined that the site created in 2006 was unintentionally architected in such a way as to allow for url manipulation once a person created a profile for themselves, giving them the ability to see other person’s resume information. CSC has no evidence that anyone other than the original anonymous tipster and those associated with OSF actually had access to resume information. This site was not properly de-provisioned and remained accessible until 2011 (although the last resume received was in September 2010). The contents, however, were not indexed or searchable by Google. There were approximately 300 profiles created with varying amounts of personal information provided. Although CSC did not ask for or require birth dates or Social Security Numbers, eight people provided either one or both. One person provided the last four digits of a SSN. CSC will provide formal notification as required by state law. In addition, where there is no state requirement, CSC will nonetheless send letters to inform everyone about the vulnerability.


Due to our delay, we have just now pushed this incident live and wanted to thank the anonymous submitter for providing us the information so we could responsibly report it and to CSC for responding to the breach appropriately.

To be clear, after we spoke with CSC on the phone and were able to get connected to the right people they responded promptly, did a thorough investigation, and then to our knowledge notified everyone. Our delay in posting this update and pushing the incident live in no way is an indication one way or the other about CSC. In fact, it just highlights the continued challenges for the Open Security Foundation to keep up with the massive amount of breaches that continue to occur every day.

In addition, we thought we would post this particular example to share some of the work that happens behind the scenes at OSF, that many people would never know exists. Coordinating with organization such as this can take a great deal of time and patience on both sides. Whenever possible and practical we do go out of our way to alert entities to breaches, but at other times we unfortunately just have to post the breach. We would love to contact all entities to confirm they are aware of the incident and offer assistance but this is not possible. For example, while we may from time to time we don’t typically contact organizations for breaches when the data is posted publicly such as when information is dumped to Pastebin or other paste sites. Unfortunately, we do not have sufficient staff to always do that and some sites do not make it easy to contact them.

We would love to be able to do more with the project, but unfortunately just have not been able to get the support or volunteers required. Moving forward, we will be making changes with the project to help ensure our future. This will begin with a new partnership with Risk Based Security, which will be able to bring more resources to better support the project and continue our research.