The following legal update is posted on behalf of my colleague Jane Shea.
Despite the temporary relief provided by the six-month extension to June 1, 2010 of the Identity Theft Red Flags regulations deadline, businesses that are located in Massachusetts, or who have customers or employees that are domiciled in Massachusetts, find that they must maintain their focus on data security for another reason – the Massachusetts data privacy regulations compliance deadline is March 1, 2010.
Like the Red Flags regulations, the Massachusetts law deadline has been extended multiple times since its first deadline of January 1, 2009. In addition, the implementing regulations were twice revised in response to feedback received from affected businesses concerning the strict encryption requirements and the "one size fits all" mandate for the written security program that the original regulations imposed.
The Massachusetts Data Security Law (MGL Chapter 93H) and its implementing Regulations (201 CMR 17.00) (the "Massachusetts Regulations") apply to anyone engaged in commerce, and specifically, those who "store" personal information, in addition to those who receive, maintain, process, or otherwise have access to such information. The Massachusetts Regulations apply to the personal information of Massachusetts residents, whether they are customers or employees. Thus, the reach of the Massachusetts Regulations is not limited to businesses located or operating in Massachusetts. There are no exceptions or exemptions, so that both for-profit and non-profit organizations located inside and outside of Massachusetts must comply.
"Personal information" is defined as a Massachusetts resident's first name and last name, or first initial and last name, combined with one or more of "(a) Social Security Number, (b) drivers license or state-issued identification number, or (c) financial account or credit or debit card number, with or without any required security code, access code, personal identification number or password, that would permit access to a resident's financial account." Publicly available information is not included provided it has been lawfully obtained.
The requirements of the Massachusetts Regulations are comparable to the FTC's Safeguards Rule. This Rule requires financial institutions subject to the federal Gramm-Leach-Bliley Act to maintain the security of their customers' personal financial information by evaluating security risks and adopting a written security program, and to oversee service providers' practices with respect to such personal information. Similarly, the Massachusetts Regulations impose a duty on every person that owns or licenses personal information to develop, implement, and maintain a written comprehensive information security program (WISP). The recent revisions permit the business to take a risk-based approach to information security, much like the federal Safeguards Rule's approach. The WISP must address the administrative, technical, and physical safeguards utilized. However, the size and scope of the business, as well as its resources, and the nature and quantity of data collected or stored, may be taken into account in developing the WISP.
The original version of the Massachusetts Regulations imposed specific technical computer security elements. The revised version retained the specific listing of these elements as guidance only, by adding a standard of technical feasibility, so that the requirements are technology neutral.
Finally, the Massachusetts Regulations require businesses to oversee service providers, with the requirements revised to be consistent with federal law. Thus, a business is required to perform reasonable due diligence in selecting a service provider to determine that it uses appropriate security measures to protect personal information, and to contractually require such measures of their service providers.
As noted above, the deadline for compliance is March 1, 2010. The law is enforced by the Massachusetts Attorney General. Businesses with customers or employees in Massachusetts need to prepare and finalize a WISP, after reviewing and evaluating their information security operations and procedures. The suggested elements of a WISP are included in the Massachusetts Regulations, but as the revisions to the Regulations make clear, these are not intended to be a rigid template. The Regulations now recognize that the nature and operations of the businesses that are subject to the law vary considerably, and like the Identity Theft Red Flag Program requirements, each WISP will be unique based upon the particular business. Additionally, businesses subject to the Massachusetts Regulations need to review their outsourcing contracts that affect personal information to determine compliance with the Regulations by their service providers. The deadline for updating service provider contracts is March 1, 2012.
Monday, February 1, 2010
Wednesday, January 27, 2010
Microsoft Disaster Response
Was I the only person who saw the headline A view from Microsoft's disaster central and immediately thought that the following article would be about Microsoft's efforts to contain the damage from the explorer weakness that was exploited in the Google hack?
Probably. I guess it's an occupational hazard that comes from being a lawyer who focuses on computer software.
And speaking of software, I wanted to mention that, in my hiatus from Ephemerallaw, I started up a new blog, Developer Diary, which is devoted to my ongoing programming efforts. I also set up a page, By Hand Games where you can download some of the games I've written.
Of course, the above has nothing to do with information security or data privacy. Then again, I'm not exclusively devoted to information security and data privacy, and I see no particular reason why Ephemerallaw should be either.
Probably. I guess it's an occupational hazard that comes from being a lawyer who focuses on computer software.
And speaking of software, I wanted to mention that, in my hiatus from Ephemerallaw, I started up a new blog, Developer Diary, which is devoted to my ongoing programming efforts. I also set up a page, By Hand Games where you can download some of the games I've written.
Of course, the above has nothing to do with information security or data privacy. Then again, I'm not exclusively devoted to information security and data privacy, and I see no particular reason why Ephemerallaw should be either.
Sunday, January 24, 2010
Will Microsoft be sued for the vulnerability used in the Google hack?
Quick answer: I don't know, but it's less likely than it might initially appear.
Earlier this month several sources, including Wired, reported that over 30 large companies, including Google and Adobe, had been victims of a sophisticated hack, which Microsoft admits was made possible by a weakness in Internet Explorer 6. Microsoft also admits that it learned of the flaw in September, and that it was holding back a patch so that it could be released in a cumulative update that was due out next month. Given the above, and the notoriously litigious nature of the American public, it would seem that Microsoft is almost guaranteed to be hit by a lawsuit seeking damages based on the failure to release the patch earlier. Certainly, when I read that Microsoft had learned about the flaw and withheld the patch, my first thought was that this was something that would keep their lawyers busy in court for months (if not years) to come.
However, the more I think about the situation, the less I think Microsoft is guaranteed to go to court. If this had happened 3-4 years ago, I'd expect Microsoft would already have been hit by a class action lawsuit filed on behalf of consumers who used IE6. However, since that time, courts have been pretty uniformly unreceptive to claims that consumers are damaged by increased risks caused by unauthorized access to data by third parties (e.g., here). A consumer wanting to sue Microsoft for vulnerabilities in IE6 would be even less likely to succeed, since (unlike the unsuccessful plaintiffs in the security breach cases) the hypothetical consumer suing Microsoft wouldn't even be able to show that an unauthorized third party had accessed their system, only that they were at an increased risk of such access due to using IE6. Looking at that history, the chances of a consumer class action against Microsoft seem pretty slim.*
So, consumers aren't likely to sue Microsoft, what about the businesses who were victimized because of the flaw? While they'd have an easier time proving damages (after all, it is known that they were hacked, and at least some of what the hackers did), there are also forces which could prevent them from going to court. For one thing, most businesses try and work things out before involving the judiciary. In this case, I assume that Google, Adobe, et al have contacted Microsoft about helping them clean up the damage. Microsoft has a significant interested in trying to make sure those out of court efforts are successful, since a drawn out court battle could only hurt Microsoft's brand in the already competitive browser market. Similarly, the companies that have been hacked would probably like to avoid going to court as well, since any lawsuit would invariably have the effect of calling their own security into question, even if they could convince the public that the reason their systems weren't secure is because they were using unsafe products, rather than that their own internal practices were deficient.
Of course, strong incentives to avoid a court battle don't necessarily mean there won't be one. If the damage caused by the hackers is too expensive, Microsoft might be willing to fight not to pay it, and the injured company might be willing to fight to get paid. At this point it's impossible to say how likely that is to play out. However, I think, given the incentives on all sides to avoid it, the likelihood of a lawsuit against Microsoft on this is much lower than it would initially appear.
*Obviously, the chances aren't zero. If there was going to be a suit against Microsoft, I would expect it in a state which has allowed suits for increased risk of health problems as a result of a chemical spill. The analogy isn't perfect, but it does make it somewhat easier to prove damages.
Earlier this month several sources, including Wired, reported that over 30 large companies, including Google and Adobe, had been victims of a sophisticated hack, which Microsoft admits was made possible by a weakness in Internet Explorer 6. Microsoft also admits that it learned of the flaw in September, and that it was holding back a patch so that it could be released in a cumulative update that was due out next month. Given the above, and the notoriously litigious nature of the American public, it would seem that Microsoft is almost guaranteed to be hit by a lawsuit seeking damages based on the failure to release the patch earlier. Certainly, when I read that Microsoft had learned about the flaw and withheld the patch, my first thought was that this was something that would keep their lawyers busy in court for months (if not years) to come.
However, the more I think about the situation, the less I think Microsoft is guaranteed to go to court. If this had happened 3-4 years ago, I'd expect Microsoft would already have been hit by a class action lawsuit filed on behalf of consumers who used IE6. However, since that time, courts have been pretty uniformly unreceptive to claims that consumers are damaged by increased risks caused by unauthorized access to data by third parties (e.g., here). A consumer wanting to sue Microsoft for vulnerabilities in IE6 would be even less likely to succeed, since (unlike the unsuccessful plaintiffs in the security breach cases) the hypothetical consumer suing Microsoft wouldn't even be able to show that an unauthorized third party had accessed their system, only that they were at an increased risk of such access due to using IE6. Looking at that history, the chances of a consumer class action against Microsoft seem pretty slim.*
So, consumers aren't likely to sue Microsoft, what about the businesses who were victimized because of the flaw? While they'd have an easier time proving damages (after all, it is known that they were hacked, and at least some of what the hackers did), there are also forces which could prevent them from going to court. For one thing, most businesses try and work things out before involving the judiciary. In this case, I assume that Google, Adobe, et al have contacted Microsoft about helping them clean up the damage. Microsoft has a significant interested in trying to make sure those out of court efforts are successful, since a drawn out court battle could only hurt Microsoft's brand in the already competitive browser market. Similarly, the companies that have been hacked would probably like to avoid going to court as well, since any lawsuit would invariably have the effect of calling their own security into question, even if they could convince the public that the reason their systems weren't secure is because they were using unsafe products, rather than that their own internal practices were deficient.
Of course, strong incentives to avoid a court battle don't necessarily mean there won't be one. If the damage caused by the hackers is too expensive, Microsoft might be willing to fight not to pay it, and the injured company might be willing to fight to get paid. At this point it's impossible to say how likely that is to play out. However, I think, given the incentives on all sides to avoid it, the likelihood of a lawsuit against Microsoft on this is much lower than it would initially appear.
*Obviously, the chances aren't zero. If there was going to be a suit against Microsoft, I would expect it in a state which has allowed suits for increased risk of health problems as a result of a chemical spill. The analogy isn't perfect, but it does make it somewhat easier to prove damages.
Sunday, April 12, 2009
Turn on your Syndication
Sadly, my actual job, combined with some personal issues have been taking up essentially all of my time recently, and will likely continue to do so for the foreseeable future. I expect to be able to return to maintaining the blog on a more regular basis at some point in the future. However, at this point, I recommend taking advantage of the feed for the site, since coming back in order to see when I have a new post up is unlikely to result in finding anything.
Saturday, April 4, 2009
Federal Security Breach Notification is Here
After years of talk, and failed attempts, tucked into a corner of the massive American Recovery and Reinvestment Act, we get a federal security breach notification law. Actually, we get a whole chunk of health care related privacy legislation, but what I'm going to focus on is the security breach notification part of it, as there's simply too much there for a single post otherwise.
In any case, the relevant provisions are sections 13402 (Notification in the case of breach, starting at page 146 in the linked PDF) and 13407 (Temporary breach notification requirement for vendors of personal health records and other non-HIPAA covered entities, starting at page 155 in the linked PDF). The question that needs to be asked is: how do they stack up against existing state security breach notification laws? The answer: reasonably well. The new federal law covers security breaches which expose individually identifiable health information* which means it's actually broader than some state laws which limit their coverage based on how the information is stored (e.g., California's SB1386 which is limited to "computerized" data). The new federal law also includes a media notice provision, which requires notice to "prominent media outlets" if the unsecured protected health information of more than 500 residents is compromised. That provision is actually stricter than the media notice from California's security breach notification law (used as a model for similar laws around the country), which is triggered if the number of people to be notified exceeds 500,000.
On the other hand, while the new federal law is stricter in some ways, it lacks what I consider one of the most important features of an effective protection - an individual right to bring suit. The lack of an individual right in various state laws has been used against people seeking compensation before (e.g., here), and I think the fact that the new federal law could be used in the same way could undermine enforcement. However, even though enforcement is a little questionable, the substance of the new federal law looks like a significant expansion in the rights of individuals to be notified when their data is exposed to unauthorized parties.
*Note: I am aware that it says it covers "unsecured protected health information". However, if you look at the definitions, the "unsecured" part basically means unencrypted, while the "protected health information" refers back to the HIPAA regulations, and translates into individually identifiable health information which is either transmitted or maintained in any medium.
In any case, the relevant provisions are sections 13402 (Notification in the case of breach, starting at page 146 in the linked PDF) and 13407 (Temporary breach notification requirement for vendors of personal health records and other non-HIPAA covered entities, starting at page 155 in the linked PDF). The question that needs to be asked is: how do they stack up against existing state security breach notification laws? The answer: reasonably well. The new federal law covers security breaches which expose individually identifiable health information* which means it's actually broader than some state laws which limit their coverage based on how the information is stored (e.g., California's SB1386 which is limited to "computerized" data). The new federal law also includes a media notice provision, which requires notice to "prominent media outlets" if the unsecured protected health information of more than 500 residents is compromised. That provision is actually stricter than the media notice from California's security breach notification law (used as a model for similar laws around the country), which is triggered if the number of people to be notified exceeds 500,000.
On the other hand, while the new federal law is stricter in some ways, it lacks what I consider one of the most important features of an effective protection - an individual right to bring suit. The lack of an individual right in various state laws has been used against people seeking compensation before (e.g., here), and I think the fact that the new federal law could be used in the same way could undermine enforcement. However, even though enforcement is a little questionable, the substance of the new federal law looks like a significant expansion in the rights of individuals to be notified when their data is exposed to unauthorized parties.
*Note: I am aware that it says it covers "unsecured protected health information". However, if you look at the definitions, the "unsecured" part basically means unencrypted, while the "protected health information" refers back to the HIPAA regulations, and translates into individually identifiable health information which is either transmitted or maintained in any medium.
Tuesday, March 24, 2009
Red Flag Rules - Deadline May 1
My colleagues Jane Shea and Gretchen Ackerman have published a new business advisory on the FTC red flag rules. I am posting it here with permission.
The May 1, 2009 deadline for creating and implementing an Identity Theft Protection and Prevention Program required by FTC Rules is fast approaching. The Identity Theft Red Flag Rules apply to all organizations with accounts primarily for personal, family or household purposes that permit multiple payments. Creditors subject to these rules include utilities, retailers, local governments, and car dealers, if such organizations carry consumer accounts permitting multiple repayments. Many hospitals and patient care facilities extend credit to patients for deferred payment of treatment costs. These health care entities must implement an Identity Theft Protection and Prevention Program to identify, detect and respond to the possible existence of identity theft with respect to these accounts. Health care entities must also take care to ensure that these programs do not conflict with other Federal and State laws, rules and regulations such as EMTALA.
The FTC Rules require all such organizations to develop and implement a proactive identity theft prevention program, and provide detailed guidelines intended to provide assistance in creating such a program. Financial institutions regulated by a regulatory agency other than the FTC were required to adopt and implement an Identity Theft Protection and Prevention Program no later than November 1, 2008.
Federal regulators were required by the FACT Act of 2003 to issue regulations that implement Section 114 of the Act, which amended the Fair Credit Reporting Act to require financial institutions and other creditors which maintain consumer accounts to adopt and maintain a written Identity Theft Prevention Program to detect, prevent, and mitigate identity theft in connection with the opening of accounts maintained for personal, family or household purposes, so long as the accounts permit multiple payments or transactions. Examples include credit card accounts, patient deferred payment plans, mortgage loans, automobile loans, margin accounts, cell phone accounts, utility accounts, checking accounts or savings accounts.
The regulations provide organizations subject to the Rules with flexibility in developing their programs according to their relative size and complexity. However, the Program must include reasonable policies and procedures that:
identify relevant Red Flags, and then incorporate those Red Flags into the Program;
detect such Red Flags;
respond appropriately to any Red Flags to prevent and mitigate identity theft; and
ensure that the Program is updated periodically to reflect changes in risks to customers
What are the "Red Flags"? The regulations define them as a "pattern, practice, or specific activity that indicates the possible existence of identity theft." However, the concept is fleshed out considerably in the supplementary materials to the regulations. The federal regulatory agencies have adopted Interagency Guidelines on Identity Theft Detection, Prevention, and Mitigation. The Regulations include a section explaining the relationship of the rules to the guidelines, specifically, that each financial institution or creditor must consider the guidelines in developing its Program, and must include those Guidelines that are appropriate. They provide policies and procedures that can be used, where appropriate, to satisfy the regulatory requirements of the Rules.
Thus, the Guidelines provide with respect to risk factors an organization should consider in identifying red flags, likely sources of red flags, and categories of red flags that should be included in the Program. Additionally, the supplementary materials to the Guidelines include illustrative examples of Red Flags which may be incorporated into a Program, and break these down into five categories: 1) Alerts, Notifications or Warnings from a Consumer Reporting Agency; 2) Suspicious Documents; 3) Suspicious Personal Identifying Information; 4) Unusual Use of, or Suspicious Activity Related to, the Covered Account; and 5) Notice from Customers, Victims of Identity Theft, Law Enforcement Authorities, or Others Regarding Possible Identity Theft in Connection with Covered Accounts Held by the Financial Institution or Creditor. Examples include:
a fraud or active duty alert is included with a consumer report
a consumer reporting agency provides a notice of credit freeze in response to a request for a consumer report
a consumer reporting agency provides a notice of address discrepancy
identification documents appear to be forged
inconsistencies between identification provided and the consumer's/patient's appearance or the information actually provided by the consumer/patient
inconsistencies between personally identifying information provided and that obtained from external information sources
a new revolving credit account is used in a manner commonly associated with known patterns of fraud.
Once the Program has been established, the organization must administer the Program, and not simply place it on a shelf. This involves requiring that the board of directors or an appropriate committee of the Board approve the initial written Program, and that the Board, an appropriate Board committee, or a designated member of senior management be responsible for the oversight, development, implementation and administration of the Program. Additionally, training of relevant staff and effective oversight of third party service providers with respect to the Program is also required.
Organizations covered by the Red Flag Identity Theft Rules are subject to oversight by the appropriate federal regulators, and for those creditors that are not federally regulated financial institutions, the Federal Trade Commission provides oversight. Besides regulatory enforcement actions, violations of the FACT Act can subject an organization to civil actions for damages. The type and amount of damages available will depend on whether the violations are "negligent" or "willful." For a claim for negligent violation, a plaintiff must prove he or she suffered actual harm as a result of the defendant's negligence. In the case of a claim for a willful violation, most courts will require proof of actual knowledge and intentional violation of the relevant statute by the organization.
The May 1, 2009 deadline for creating and implementing an Identity Theft Protection and Prevention Program required by FTC Rules is fast approaching. The Identity Theft Red Flag Rules apply to all organizations with accounts primarily for personal, family or household purposes that permit multiple payments. Creditors subject to these rules include utilities, retailers, local governments, and car dealers, if such organizations carry consumer accounts permitting multiple repayments. Many hospitals and patient care facilities extend credit to patients for deferred payment of treatment costs. These health care entities must implement an Identity Theft Protection and Prevention Program to identify, detect and respond to the possible existence of identity theft with respect to these accounts. Health care entities must also take care to ensure that these programs do not conflict with other Federal and State laws, rules and regulations such as EMTALA.
The FTC Rules require all such organizations to develop and implement a proactive identity theft prevention program, and provide detailed guidelines intended to provide assistance in creating such a program. Financial institutions regulated by a regulatory agency other than the FTC were required to adopt and implement an Identity Theft Protection and Prevention Program no later than November 1, 2008.
Federal regulators were required by the FACT Act of 2003 to issue regulations that implement Section 114 of the Act, which amended the Fair Credit Reporting Act to require financial institutions and other creditors which maintain consumer accounts to adopt and maintain a written Identity Theft Prevention Program to detect, prevent, and mitigate identity theft in connection with the opening of accounts maintained for personal, family or household purposes, so long as the accounts permit multiple payments or transactions. Examples include credit card accounts, patient deferred payment plans, mortgage loans, automobile loans, margin accounts, cell phone accounts, utility accounts, checking accounts or savings accounts.
The regulations provide organizations subject to the Rules with flexibility in developing their programs according to their relative size and complexity. However, the Program must include reasonable policies and procedures that:
identify relevant Red Flags, and then incorporate those Red Flags into the Program;
detect such Red Flags;
respond appropriately to any Red Flags to prevent and mitigate identity theft; and
ensure that the Program is updated periodically to reflect changes in risks to customers
What are the "Red Flags"? The regulations define them as a "pattern, practice, or specific activity that indicates the possible existence of identity theft." However, the concept is fleshed out considerably in the supplementary materials to the regulations. The federal regulatory agencies have adopted Interagency Guidelines on Identity Theft Detection, Prevention, and Mitigation. The Regulations include a section explaining the relationship of the rules to the guidelines, specifically, that each financial institution or creditor must consider the guidelines in developing its Program, and must include those Guidelines that are appropriate. They provide policies and procedures that can be used, where appropriate, to satisfy the regulatory requirements of the Rules.
Thus, the Guidelines provide with respect to risk factors an organization should consider in identifying red flags, likely sources of red flags, and categories of red flags that should be included in the Program. Additionally, the supplementary materials to the Guidelines include illustrative examples of Red Flags which may be incorporated into a Program, and break these down into five categories: 1) Alerts, Notifications or Warnings from a Consumer Reporting Agency; 2) Suspicious Documents; 3) Suspicious Personal Identifying Information; 4) Unusual Use of, or Suspicious Activity Related to, the Covered Account; and 5) Notice from Customers, Victims of Identity Theft, Law Enforcement Authorities, or Others Regarding Possible Identity Theft in Connection with Covered Accounts Held by the Financial Institution or Creditor. Examples include:
a fraud or active duty alert is included with a consumer report
a consumer reporting agency provides a notice of credit freeze in response to a request for a consumer report
a consumer reporting agency provides a notice of address discrepancy
identification documents appear to be forged
inconsistencies between identification provided and the consumer's/patient's appearance or the information actually provided by the consumer/patient
inconsistencies between personally identifying information provided and that obtained from external information sources
a new revolving credit account is used in a manner commonly associated with known patterns of fraud.
Once the Program has been established, the organization must administer the Program, and not simply place it on a shelf. This involves requiring that the board of directors or an appropriate committee of the Board approve the initial written Program, and that the Board, an appropriate Board committee, or a designated member of senior management be responsible for the oversight, development, implementation and administration of the Program. Additionally, training of relevant staff and effective oversight of third party service providers with respect to the Program is also required.
Organizations covered by the Red Flag Identity Theft Rules are subject to oversight by the appropriate federal regulators, and for those creditors that are not federally regulated financial institutions, the Federal Trade Commission provides oversight. Besides regulatory enforcement actions, violations of the FACT Act can subject an organization to civil actions for damages. The type and amount of damages available will depend on whether the violations are "negligent" or "willful." For a claim for negligent violation, a plaintiff must prove he or she suffered actual harm as a result of the defendant's negligence. In the case of a claim for a willful violation, most courts will require proof of actual knowledge and intentional violation of the relevant statute by the organization.
Sunday, March 22, 2009
EPIC Files Interesting Complaint Regarding Google Services
Earlier this month, Google sent out an email admitting to a bug (subsequently fixed) which caused some documents on Google's cloud computing services to be shared without their owners' knowledge or consent (a copy of the email can be found in this blog post). Now, the Electronic Privacy Information Center (EPIC) has filed a complaint with the FTC asking it to investigate Google's procedures, to force Google to revise its terms of service, and to spend $5,000,000 on security research. The complaint also asks that Google be enjoined from offering cloud computing services until "safeguards are verifiably established." The complaint can be found here.
At this point, I actually don't want the complaint to succeed - at least, not to succeed in full, as I use some of the services in question, and I don't want to wait for Google to get its act together on privacy before using them again. However, while I don't want the complaint to succeed, I do think it makes for interesting reading for people who care about, but aren't familiar with, the FTC's role in protecting consumer privacy. Highly recommended reading, at least for that class of reader.
via
At this point, I actually don't want the complaint to succeed - at least, not to succeed in full, as I use some of the services in question, and I don't want to wait for Google to get its act together on privacy before using them again. However, while I don't want the complaint to succeed, I do think it makes for interesting reading for people who care about, but aren't familiar with, the FTC's role in protecting consumer privacy. Highly recommended reading, at least for that class of reader.
via
Subscribe to:
Posts (Atom)