You Cannot Outsource the Consequences of a Breach

Mozilla is known to most people for its open-source and free software, most notably Firefox. However, starting around August 4th, it also became known as yet another company whose merchandise store was breached. Following the announcement on the company’s blog and closure of Mozilla’s store, the following headlines filled trade pubs and the blogosphere: “Mozilla Store Breached” – PC Magazine, “Mozilla shuts Firefox e-store after security breach” – Computerworld, and “Mozilla Store Security Breached” – InformationWeek. A careful reading of these articles, however, revealed that the breach did not happen by any fault of Mozilla; rather, it was caused by a company called Gateway/CDI, a third-party e-commerce processor. Even though most news stories about the breach mentioned this critical fact, my conversations with non-techie friends proved that such details went largely unnoticed and that Mozilla was viewed as the guilty party. This only goes to prove that unless the reader has a reason to take an interest in the story, the headline will be the only thing read. Unfortunately, headlines such as “Mozilla shuts down online store after third-party security breach” ( are rare and tend to appear only in technical and security-oriented news sources. What all this adds up to is that when considering the outsourcing of storing, processing, or transmitting critical data to a third party, organizations must recognize that in the event that such a third party is breached, it will be their name in the headlines, not the vendor’s. The solution is for companies to carefully evaluate whether outsourcing is really the best option for them and for their clients. Personally, I think that companies are outsourcing too much, completely ignoring the risks associated with letting your data outside of the trusted network perimeter. However, if outsourcing still makes business sense, careful attention must be paid to ensuring that the vendor takes all appropriate precautions to make sure your data remains safe. Ideally, this should be done during the initial negotiation, as that will be the time when a client has the most influence and power over the vendor. Typical validation steps may include a combination of any of the following tactics:

  1. Ask if the vendor has a SAS-70 on file. (Make sure it explicitly covers the service you are purchasing, and request an independent review of the report to make sure it was provided by a reputable audit firm.)
  2. Involve Internal Audit to request that the vendor fill out a questionnaire, indicating its information security practices. Make sure to ask for proof for some of the most critical controls.
  3. Hire a security consulting firm to perform an independent audit of the security controls the vendor has in place.
  4. Request your internal information security team to perform a thorough review of the vendor’s security controls.

The most important thing to remember is that even though your organization may be outsourcing to a third party, the overall responsibility for the protection of the data in the eyes of your current and future customers will always remain with your company.


Social Media and Corporate Guidance

One of the common themes I took away from the 2009 Blackhat Briefings was the inherent security risks associated with using social media and networking sites. (These concerns have also received some coverage in trade pubs; see, for example a recent Computerworld article: Using social media applications is not just a personal computing trend; they have also become integrated into our corporate cultures. Many organizations are using these sites for corporate marketing, file sharing, communications, and recruiting. In the past, the corporate policy of most organizations was not to post resumes online, use your corporate email account as your username to access a website, or post pictures from the company holiday party on a website (at least the potentially incriminating ones). Now, corporations are eager to get the word out about how great it is to work there, or connect with employees, or find out what events they will be attending, even posting opinionated blog entries such as this one. While these applications can open great new doors, they need some associated corporate guidance. I say guidance because a more explicit security policy regarding usage of Twitter, LinkedIn, or Facebook is likely to be unenforceable. Employees may refrain from using corporate accounts for these applications, but if they like them, they will find ways to use them. Here are some basic guidance points that you may consider in your next security-awareness email.

  1. When using social media sites, be sure to use different passwords for different sites, and never use your corporate password. These sites have varying password reset controls; don’t let a breach of one account impact all your accounts.
  2. Remember, in the case of company documents, if it’s not meant for the company’s public website, it probably isn’t meant to be shared on some-one else’s–-even if they told you it is secure. Watch out for sites like Google docs or that create a perception of privacy and security. Let your security team determine acceptable sites.
  3. There are a couple of key items that you should never post publicly, such as your birth-date, social security number, or employee ID. If the site requires such data, consider making something up or ensuring it’s not displayed in a public profile.
  4. There are certain items that companies don’t technically classify as confidential, yet keeping them a secret and off the social networking sites is a good thing. This could includes rumors, planned purchases, technology used, and projects you’re working on. Posting your job history may be OK, but for current activities, just keep it generic.

Healthcare Organizations and Tighter Security Requirements

Because of increasing threats, high-profile data breaches, and increased awareness of the damage they cause, we anticipate a substantial tightening of regulations and contractual requirements that will significantly impact information security in healthcare.

Today, HIPAA, CCHIT, and state breach notification laws are the main standards that govern security within healthcare systems that deal with protected health information (PHI). But these are generally high-level requirements with low levels of enforcement. The American Recovery and Reinvestment Act (ARRA) of 2009 contains legislation mandating broader and deeper security for healthcare, and the consensus view is that more legislated regulations will follow. The Healthcare Information Trust Alliance (HITRUST) is an industry group that has developed a set of standards, the Common Security Framework (CSF). This set of standards generally follows industry best practices and is very comprehensive. Important members of this group (Humana, United Health Group, Blue Cross Blue Shield, and Columbia HCA, to name a few) are pushing to mandate these standards across the industry. It is possible that many of these standards will be adopted by the group members through a contractual stipulation that the software they purchase meet the HITRUST CSF standards. In addition to HIPAA and CSF, Payment Card Industry (PCI) standards also affect healthcare payers and providers when credit card information is involved in any way (processing, storing, or transmitting). For healthcare payers and providers, the PCI Data Security Standard (PCI DSS) applies. For healthcare software providers whose applications touch credit card data, the PCI Payment Application Data Security Standard (PA-DSS) applies. It is likely that the Obama administration will implement much stricter security standards in healthcare, in conjunction with its emphasis on greater use of electronic health records (EHR). It is also likely that these standards will follow industry best practices and be based on the most successful existing standards, such as PCI and HITRUST. Based on this likely increase in regulations and the increasing number of threats, healthcare organizations should develop a risk-based security strategy that includes industry best practices using HIPAA, CCHIT, PCI and HITRUST as a guide.


The Far-Reaching Impact of the PCI DSS

The last few years have seen a great deal of discussion, arguing, hand-wringing, and posturing within the retail / hospitality community regarding the PCI DSS.  It has also driven a lot of investment in technology–and a lot of investment by technology companies. Then PA-DSS came along. The PCI Council took a voluntary program (PABP) and turned it into a robust, mandatory security standard, the impact of which is still being absorbed by software vendors that provide solutions to retail and hospitality merchants. Again, there was much hand-wringing, posturing, and general frustration (this time from the vendors.) The remarkable thing to me is the degree to which, until very recently, this consternation over PCI and its applicability and requirements has largely been isolated to the retail / hospitality community. Slowly, the rest of the business world is waking up to the fact that PCI reaches far beyond retail. Electronic currency (i.e., debit and credit) is not a payment mechanism isolated to any one vertical; instead, it’s increasingly used by consumers in all aspects of their spending. This realization ’process’ looks an awful lot like the classic grieving process–denial, anger, bargaining, depression, and finally, acceptance–and is the same process that the retail community has gone through for the last five years (for L1 & L2 merchants I think we’ve pretty much gotten to the acceptance stage). A lot of hospitals, higher education organizations, healthcare technology firms, and the like are really just beginning this process – denial is still a big part of the conversations that we have with these organizations. Now, this is certainly not a universal situation. NetSPI is working with some very forward-thinking, security-focused organizations on PCI and related security initiatives, but it’s common enough to note and it’s where we spend a lot of time working to educate the broader community. Luckily, we have a lot of experience with these other industries and can help our clients work through this process with more than just a retail/hospitality perspective. The fact that other standards are also applicable in some instances may be causing some of the difficulty in accepting the fact that PCI is important and applies. HIPAA, for example, has security requirements to protect personal health information. I have had numerous conversations about PCI with companies in healthcare that have sounded something like “I have to adhere to the HIPAA security standards, so I’m covered.” Actually, if you take credit card payments, and you are just worrying about HIPAA’s security requirements, you have a serious problem. Anyone that takes or manages electronic payments–healthcare providers, lawn care companies, hospitals, insurance companies, doctor’s offices, accounting firms, tax preparation services, plumbers, event scheduling services, etc, etc, etc, etc.–is subject to PCI’s requirements. The software vendors that service and support all of these industries and handle PCI-relevant information within their solution are also subject to PCI’s requirements (via PA-DSS). So my advice – learn to accept PCI and take the steps today that will help make compliance more efficient and improve overall security. Find a partner that is focused on PCI guidance, not just auditing.  Make sure that they understand your industry, ask good questions that go beyond the scope of compliance, and give you honest feedback. If you accept electronic payments, PCI applies to you. If you are in denial, you need to move through your grieving process quickly so that you can make critical decisions and take the actions required to protect your organization and minimize risk.

Discover why security operations teams choose NetSPI.