Preparation

Preparation

Credit Card Security for Small Business (Pt. 2)

PCI DSS, Preparation, Prevention, Privacy, Security, Small Business 1 comment

In the last blog post, I discussed the first 2 steps of the 4 step process that small businesses need to follow to comply with the Payment Card Industry Data Security Standards (“PCI DSS”):

1.  PCI DSS Scoping – Determines what organization system components and computer networks are in scope for PCI DSS assessment.

2. Assessing – Exam and assess the compliance of system component and computer networks in scope following the testing procedures for each PCI DSS Requirement.

3. Reporting – PCI DSS Qualified Security Assessor (QSA) and/or business submits required documentation to validate compliance with PCI DSS, including documentation of all compensating controls.

4. Clarifications – QSA and/or business clarifies ROC and/or SAQ, if needed, at the request of the acquiring bank, or payment card brand.

This week I’ll look at the remaining 2 steps.

III. REPORTING

Reports are the official mechanism by which a business validates compliance with PCI DSS to your acquiring bank or payment card brand. Depending on the payment card brand and the acquiring bank, any of the following reports may be required:  Report on Compliance (ROC); Self-Assessment Questionnaire (SAQ); Quarterly scanning reports from Approved Security Vendors (“ASV”), if required; and possible others.

The form and extent of your validation reporting is made by your acquiring bank in accordance with the validation requirements set by the payment card brands. Visa, for example, divides merchants into 4 different risk levels based on the aggregate Visa transaction volume over a 12 –month period.  The more transactions a merchant handles, the greater the validation reporting requirements:

 

Level/Tier Merchant Criteria Validation Requirements
Level 1 Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region  • Annual ROC by Qualified Security Assessor (“QSA”) or Internal Auditor if signed by officer of the company

o The internal auditor is highly recommended to obtain the PCI SSC Internal Security Assessor (“ISA”) certification.

• Quarterly network scan by ASV
• Attestation of Compliance Form

Level 2 Merchants processing 1 million to 6 million Visa transactions annually (all channels) • Annual SAQ
• Quarterly network scan by ASV
• Attestation of Compliance Form
Level 3 Merchants processing 20,000 to 1 million Visa e-commerce transactions annually • Annual SAQ
• Quarterly network scan by ASV
• Attestation of Compliance Form
Level 4 Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually • Annual SAQ recommended
• Quarterly network scan by ASV if applicable
• Compliance validation requirements set by merchant bank

 

A merchant that suffers a data breach is automatically increased a level and may be required to fulfill the Level 1 validation requirements, even though it does not handle over 6 million Visa transactions.  MasterCard, Discover, and American Express also base validation requirements on transaction volume, although American Express breaks down the numbers a little differently.

Report on Compliance (ROC)

ROC’s are the most detailed and complicated of the validation reports required by the PCI Security Standards Counsel. ROC’s provide details about the organizations’ environment, assessment methodology, and documents the organization’s compliance for each PCI DSS Requirement.

The Official Template of the ROC for use with PCI DSS v.3.0 needs to be used by any QSA completing a ROC PCI DSS assessment for a business. The template includes the following sections:

  • Executive Summary – Description of organization’s payment card business and high level network diagram.
  • Description of Scope of Work and Approach Taken– Description of how the assessment was made, environment, network segmentation used, details of each sample set selected and tested, wholly owned or international entities requiring PCI DSS compliance, wireless networks or applications that could impact security of cardholder data, and version of PCI DSS used to conduct the assessment.
  • Details about Reviewed Environment – Diagram of each network, description of CDE cardholder data environment (“CDE”), list of all hardware and software in CDE, service providers used, third party payment applications, individuals interviewed, documentation reviewed, and details of managed service providers.
  • Contact Information and Report Date
  • Quarterly Scan Results – Summary of four most recent ASV scan results
  • Findings and Observations – Detailed findings on each requirement and sub-requirement, including explanation of all N/A responses and validation of all compensating controls.

As you can likely tell, the ROC is enormously complicated and expensive.  ROC’s are usually only required for entities that handle a significant number of transactions (over 6 million for Visa, MasterCard and Discover) or who have previously had a data breach.  They should only be completed by a QSA or ISA.  If you need a QSA, check out this list of approved QSA’s here.

Self Assessment Questionnaires (SAQ)

Most small businesses have less than 6 million credit card transactions and only need to file an annual SAQ rather than a ROC. A SAQ includes a series of yes-or-no questions about your security posture and practices with respect to each applicable PCI DSS requirement. If you answer “no” to a question, the business may be required to document the remediation steps that will be taken to correct the defect and when the remedial steps will be complete.

The type of SAQ that you business needs to complete depends on the manner in which you accept credit cards:

 

SAQ Description
A Card-not-present merchants (e-commerce or mail/telephone-order) that fully outsource all cardholder data functions to PCI DSS compliant third-party service providers. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.Not applicable to face-to-face channels.
A-EP E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.Applicable only to e-commerce channels.
B Merchants using only:
• Imprint machines with no electronic cardholder data storage; and/or
• Standalone, dial-out terminals with no electronic cardholder data storage.Not applicable to e-commerce channels.
B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor. No electronic cardholder data storage.Not applicable to e-commerce channels.
C-VT Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage.Not applicable to e-commerce channels.
C Merchants with payment application systems connected to the Internet. No electronic cardholder data storage.Not applicable to e-commerce channels.
P2PE-HW Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage.Not applicable to e-commerce channels.
D SAQ D for Merchants:  All merchants not included in descriptions for the above SAQ types.SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete a SAQ.

 

Each SAQ is only intended to be used by the merchant that fits the description, and the questions are tailored to the PCI DSS requirements suitable to that type of credit card processing.  As such, some of the questionnaires have fewer questions and are easier to complete than others because the merchant has less contact with credit card data.  Choose the questionnaire that fits your business.  If you’re not sure what type of SAQ to fill out, check with your acquiring bank that can provide guidance.  Many processors will even fill out the self-questionnaire for you (usually for a fee), but you should make sure to review to ensure that it is the right one.

Quarterly Network Scans

As discussed last week, an organization usually has to have quarterly scans of their systems by an Approved Scanning Vendor (ASV) to check for internal and external vulnerabilities.  See Credit Card Security for Business (part I) at no.11, see also PCI DSS Requirements and Assessment Procedures at Req. 11.  Hire an ASV to conduct your quarterly scanning and follow the recommendations of your acquiring bank regarding the form and process for reporting compliance.

Attestation of Compliance

The Attestation of Compliance (“Attestation”) is your organization’s declaration that the relevant PCI requirements have been met.  There are 9 different versions of the Attestation, depending on which specific SAQ or ROC use.  If your business uses a ROC, use the Attestation for ROC’s.  If it uses SAQ A then use Attestation for SAQ A. And so on.

Each Attestation requires your business to provide:

  • Details about the business and the individual conducting the PCI DSS Assessment;
  • Executive summary of the manner in which your business accepts credit cards, the CDE covered by the assessment, third-party service providers, and your eligibility to use the validation report being used (ROC, SAQ A, SAQ A-EP, etc.);
  • Date that validation report was completed;
  • Whether your business complies with all of the PCI DSS requirements specified in the validation report;
  • Action Plan for any Non-Compliant Requirements.

The Attestation should be accurate and without misrepresentations regarding that status of your PCI DSS compliance. It’s far better to identify certain deficiencies and develop a plan for mediating them, rather than making a false statement to secure compliance.

IV. CLARIFICATIONS

Occasionally, the acquiring bank or credit card brand will ask for a clarification regarding some aspect of your PCI DSS compliance. Do not panic! This is not uncommon. Cooperate fully and be as helpful as possible to understand and solve the problem. Forward copies of any documents requested, and make sure to properly document any request, your answer, and any documents that are sent.

If your acquiring bank wants to conduct a PCI DSS Audit, comply fully. A PCI DSS Audit usually occurs when a data breach is suspected. If notified of an upcoming audit, gather all relevant information related to PCI DSS compliance and have it ready for the inspectors when they arrive. You want the audit team to rest assured that you take PCI DSS compliance seriously and are on-board for full cooperation. This will make the process smoother and get your business up and running again as soon as possible.

The audit team comes in and checks to see whether a security breach has occurred and the circumstances of the breach. The auditors also determine whether your business is actually compliant with PCI DSS requirements. If your business meets PCI DSS requirements, you are not responsible for any fines, credit card replacement fees, or fraud refunds that result from the breach. If your business is not compliant, you are potentially on the hook for any of these costs.

That’s it for this week. Thanks for reading. Let me know if you have any questions regarding PCI DSS or anything else.

Mobile Apps, Children’s Privacy and COPPA

Tags: , , , , , , Apps, COPPA, Preparation, Privacy 1 comment

It was recently reported that mobile apps are still collecting lots of personal information about children and still may not be complying with the Children’s Online Privacy Protection Act, 15 USC 91 §6501-6506 or the Federal Trade Commission’s (“FTC’s”) Final Amended COPPA Rule (collectively, “COPPA”).  See also FTC, “Complying with COPPA: Frequently Asked Questions”, July 16, 2014.  App developers need to make sure their apps comply with COPPA, as the FTC is actively cracking down and there is an increased risk of a class action lawsuit based on a COPPA violation.

COMPLIANCE WITH COPPA

The primary goal of COPPA is to place parents in control over what information is collected from kids under the age of 13 (“Children”) online, while accounting for the dynamic nature of the Internet.  To comply with COPPA, an app developer should follow these steps:   See FTC, Children’s Online Privacy Protection Rule: A Six-Step Compliance Plan for your Business

1.  Determine if COPPA Applies to Your App or Website

COPPA only applies to the following:

• Operators of commercial websites or online services that are directed to Children and collect, use, or disclose Children’s’ personal information;

• Operators of general audience websites or online services with actual knowledge that they are collecting, using or disclosing personal information from Children.

• Operators of websites or online services with actual knowledge that they are collecting, using or disclosing personal information directly from users of another website or online service directed to Children.

Several key terms need a little more explanation to appreciate the scope of COPPA:

Website or Online service:  This term is defined broadly by COPPA. Aside from websites, the following are potentially within COPPA’s scope:

o Mobile apps that send or receive information online,

o Internet-enabled gaming platforms,

o Plug-ins,

o Advertising networks,

o Internet-enabled location-based services, and

o Voice-over internet protocol services

Personal Information: The definition of personal information under COPPA is shockingly broad and includes any one of the following categories of information (“Personal Information”):

o First and Last Name;

o A home or physical address including street name of a city or town;

o Online contact information;

o A screen or user name that functions as online contact information;

o A telephone number;

o A social security number;

o A persistent identifier that is used to recognize a user over time and across different websites or online services;

o A photograph, video, or audio file that contains a child’s image or voice;

o Geolocation information sufficient to identify the street name and city or town name; or

o Information concerning the child or child’s parents that the operator collects online and combines with an identifier above.

Directed at Children: The FTC looks at a variety of factors to determine if an app is directed at Children :

o the subject matter of the site or service,

o audio/visual content,

o the use of animated characters,

o child-oriented activities and incentives,

o the age of models,

o the presence of child celebrities,

o ads directed to children, and

o Other reliable evidence about the age of the actual or intended audience.

Collect: Under COPPA, an app collects Personal Information if it does one of the following:

o Requests, prompts, or encourages the submission of information, even if it’s optional;

o Lets Personal Information be made publicly available (such as in a public chat), unless you take reasonable efforts to delete virtually all Personal   Information before postings are made public AND delete all information from your records; or

o Passively tracks a child online.

If your app or website is covered by COPPA , move on to step 2. Congratulations if you think it is not covered! But I suggest you talk with an attorney to confirm that COPPA does not apply your app. You do not want to be wrong here!

2.  Post a COPPA Compliant Privacy Policy

If covered by COPPA, your app must post a post a privacy policy that clearly and comprehensively describes how Personal Information is collected from Children and how it is handled. To complicate matters, the privacy policy must describe your policies AND the practices of any third parties collecting Personal Information on your service, such as plug-ins or ad networks.

To comply with COPPA, your privacy policy should be clear, easy to read, and include the following information:

A List of All Operators Collecting Personal Information:  Your policy should identify each operator that collects or maintains a child’s Personal Information through your app.  Include a name and contact information (address, telephone number, and email address) for each operator.  If more than one operator collects Personal Information, it is acceptable to only provide contact information for one operator, so long as the selected operator will respond to inquiries about your app’s practices with respect to the other operators.  The other operators still need to be identified in your privacy policy.

A Description of the Personal Information Collected and How It’s Used:  Your privacy policy must describe the following:

o Types of Personal Information collected from Children;

o Ways that the Personal Information is collected (direct or indirectly through cookies);

o How Personal Information will be used (i.e. marketing, notifying contest winners, incentives, or allowing children to post information);

o Whether app discloses Personal Information to third parties, such as ad networks, and how the third parties use the information.

Description of Parental Rights:  Your app’s privacy policy must tell parents that:

o Your app won’t require a child to disclose more Personal Information than reasonably necessary to participate in the app’s activity;

o They have the right to review the child’s Personal Information, can direct you to delete it, and refuse to allow any further collection or use of the child’s Personal Information;

o They can agree your app’s collection and use of their child’s Personal Information, but still forbid disclosure to third parties unless that’s part of the service (such as social networking); and

o The procedures that a parent must follow to exercise their rights.

Make sure that your privacy policies accurately describes your app’s practices and that you follow through on all promises made. Nothing will generate an FTC enforcement action quicker than a privacy policy that misrepresents the practices of the app.

3.  Notify Parents Directly Before Collecting Personal Information from Children

COPPA requires that your app provides parents with “direct notice” before collecting Personal Information their child. The notice should be clear, easy to read and should tell parents:

• Your app collected their online contact information for the purpose of getting their consent;

• Your app wants to collect Personal Information from their child;

• The parent’s consent is required for the collection, use, and disclosure of the child’s Personal Information;

• The specific Personal Information your app wants to collect and how it might be disclosed to others;

• A link to your online privacy policy;

• How the parent can give their consent; and

• If the parent does not consent within a reasonable time, you will delete the parent’s online contact information from your records and their child will not be able to use the app.

4.  Get Parent’s Verifiable Consent Before Collecting Information

Your app must also obtain parent’s verifiable consent before collecting Personal Information about the child.  COPPA does not specify how to obtain verifiable consent, but it is critical to use a method that is reasonably designed in light of available technology to ensure that the person giving the consent is the child’s parent.

Acceptable methods of obtaining verifiable consent include:

• Provide a consent form to be signed by the parent via U.S. mail, fax or electronically;

• Require the parent, in connection with a monetary transaction, to use a credit card, debit card, or other online payment system that provides notification of each discrete transaction to the primary account holder;

• Have the parent call a toll-free number staffed by trained personnel, or have the parent connect to trained personnel via video-conference;

• Verify the parent’s identity by checking a form of government-issued identification (such as driver’s license or passport) against databases of such information. Make sure to delete the parent’s identification info after completing the verification;

• Use the “email plus” method if you are only going to use Children’s Personal Information for internal purposes and will not be disclosing to any third party;

• Use a common consent mechanism between multiple app developers who use the same system of obtaining verifiable consent;

• Rely on an app store to gain parental consent on you app’s behalf. Note that entry of parent’s app store account number or password is not sufficient. The account number and password needs to be used with other indicia of reliability to show that it is the parent giving the consent. Also, your app still needs to meet COPPA’s other requirements (such as the direct notice requirement);

• You can also apply to the FTC for pre-approval of a new method.  The FTC had already accepted some proposed new methods of verifiable consent and is regularly evaluating new ones.

There are certain circumstances under COPPA where your app can collect and use a narrow class of Personal Information without obtaining parental consent.  Check out the FTC’s website for a helpful chart of these limited exceptions.

5.  Respect Parents’ Ongoing Rights

Make sure to respect parent’s ongoing rights with respect to their child’s Personal Information.  If a parent asks, you must:

• Give the parent a way to review the Personal Information collected about the child;

• Give the parent a way to retract their consent and refuse the further use or collection of Personal Information about the child; and

• Delete the child’s Personal Information.

Note that you must walk a fine line before disclosing Personal Information about a child.  Take reasonable steps to ensure that you are dealing with a child’s parent and not some stranger. But do not make these steps so onerous that the real parent can’t find out what Personal Information your app is collecting about the child.

6.  Implement Reasonable Safeguards for Children’s’ Personal Information

COPPA requires you to establish and maintain reasonable procedures to protect the confidentiality, security, and integrity of Children’s Personal Information.  The first step is to limit the Personal Information collected and only collect what is absolutely necessary for your app’s services.  Then take reasonable steps to only release Children’s Personal Information to third parties capable of maintaining its confidentiality, security and integrity.  Obtain contractual assurances that the third parties will live up to those responsibilities.  Finally, only retain the Children’s Personal Information as long as reasonably necessary, and securely dispose of as soon as you no longer have a legitimate reason for retaining it.

7. Investigate Participating in a COPPA Safe Harbor Program

As an app developer, one alternative worth investigating are FTC approved COPPA Safe Harbor Programs.  COPPA Safe Harbor programs are self-regulatory guidelines developed by various industry groups that have been approved by the FTC for complying with COPPA.

You can obtain two benefits by participating in one of these programs.  First, your app will be deemed compliant with COPPA so long as it follows the program’s guidelines.  Second, your app will be subject to the review and disciplinary procedures outlined in the program’s guidelines instead of a formal FTC investigation and enforcement.  Both are worthwhile, so you should consider participating in one of these programs.

ENFORCEMENT OF COPPA

COPPA is usually enforced by the FTC, although some state attorney generals have brought COPPA enforcement actions in the past. New Jersey, in particular, has brought and settled at least two COPPA enforcement actions against app developers.

The FTC has recently warned that mobile apps will be an enforcement priority under COPPA, and has already announced two settlements with mobile app developers:

1. Yelp:  Yelp, the online review website and app, paid $450,000 to settle charges that it violated COPPA by collecting Children’s Personal Information without sufficient parental notice or consent.  Yelp allegedly employed an age-screening mechanism that required a birth-date in order to register for its app, but thousands of Children were allowed to register, without notice or parental consent, after providing birth-dates that showed they were under 13.

2. TinyCo:  TinyCo, the developer of Tiny Pet and other apps, paid $300,000 to settle charges that it violated COPPA by collecting Children’s email addresses without sufficient notice and parental consent.   The email addresses were allegedly collected in exchange for free in-app currency.

In light of the FTC’s warnings, more enforcement actions against app developers are likely and the costs can be significant. In addition to the investigatory costs and the hit to your reputation, violators of COPPA can be penalized up to $16,000 per violation. That’s not chump change!

There is also a heightened risk of a class action lawsuit suit for failure to comply with COPPA.  Usually, COPPA violations are considered unlikely contenders for class action lawsuits because COPPA does not provide a private cause of action.  Without a cause of action, an individual or class cannot allege a COPPA violation as the basis for a complaint a damages.  This calculation may have changed in light of a recent Connecticut Supreme Court case:  Byrne v. Avery Center for Obstetrics and Gynecology, No. 18904, (Conn. Nov. 11, 2014).

In Byrne, the Court found that the Health Insurance and Portability and Accountability Act of 1996 (“HIPAA”) and the regulations of the Department of Health and Human Services (“HHS”) can “inform” the standard of care for a common law negligence action.  In this case, Emily Byrne received medical care from the Avery Center (“Center”), while in a personal relationship with Andro Mendoza. Mendoza filed a paternity suit and the court issued a subpoena to the Center to appear with Byrne’s medical records.  Byrne did not want the Center to release her medical records.  But, the Center mailed a copy of the medical forms to the court.  Byrne claimed that the disclosure of the medical forms was not done in accordance with HIPPA and that she should have been notified of the subpoena.

As a result of the disclosure, Byrne filed suit for breach of contract, negligently releasing her medical file without authorization, negligent misrepresentation of the Center’s privacy policy, and negligent infliction of emotional distress.  After a motion for summary judgment, the trial court dismissed part of Byrne’s complaint and found that Byrne’s common law negligence and infliction of emotional distress claims were preempted by HIPAA, which does not provide a private cause of action.  The Connecticut Supreme Court reversed and concluded that “to the extent it has become the common practice for . . . follow the procedures required under HIPAA in rendering services to their patients, HIPAA and its implementing regulations may be utilized to inform the standard of care applicable to such claims arising from allegations of negligence in the disclosure of patients’ medical records pursuant to a subpoena.”

This decision is significant in several respects.  For app developers, the most important consequence is that it provides a road map for a potential plaintiff about how to sue for a violation of COPPA.  The plaintiff would need to plead a common law negligence claim related to the violation and argue that COPPA and the FTC regulations inform the duty of care applicable to these actions.  Alternatively, the plaintiff could argue that the COPPA violation is an unfair and deceptive trade practice under the state’s consumer protection.

It is still unclear whether these strategies will work or whether these strategies are preempted by COPPA.  I will postpone this discussion for another blog post.  But if app developers continue to ignore COPPA, plaintiffs and their attorneys may start actively pursuing these cases.  There is too much money potentially at stake.  Stay tuned for further developments.

Thanks for reading.

How to Prepare for A Data Breach (Part 2)

Tags: , , Business, Data Breach, Preparation, Small Business, Uncategorized 1 comment

In addition to the steps discussed last week, a business should take the following steps to prepare for a data breach:

Step 5: Arrange Possible Remedies for Customers

A recent study shows that 25% of individuals notified of a data breach go on to suffer identity theft.  To combat this, most companies now offer – and consumers expect – some form of credit monitoring services for affected individuals.

Credit monitoring services are directed at fraud in connection with new financial accounts.  This fraud occurs when a criminal uses a victim’s personal information to open a new credit card or other financial account.  Credit monitoring does not prevent the opening of new accounts, but notifies an individual when a new account is opened, so that the individual can determine whether it is fraudulent.

Although credit monitoring service is nice, it is not that effective at actually preventing identity theft and is often a waste of money.  See Brian Krebs “Are Credit Monitoring Services Worth It?”  Notably, there are at least five types of identity theft fraud not covered by credit monitoring services:

Existing account fraud:  Occurs when a criminal uses an individual’s current financial account, such as a credit card account or bank account, to make a purchase from a vendor or withdraw money from the individual’s bank account.

Social Security number and tax refund fraud:  Occurs when a criminal uses an individual’s SSN to obtain employment, for tax reporting purposes, or for other illegal transactions.  Tax refund fraud is a rapidly growing problem and the IRS is attempting to combat it.

Criminal identity theft:  Occurs when an imposter provides another person’s name and personal information to a police officer during an arrest.  The imposter often fraudulently obtained a driver’s license in the victim’s name and provides the identification document to law enforcement.

Medical Identity Theft:  Occurs when a crook uses an individual’s name and/or other information, such as insurance information, to obtain or make false claims for medical goods or services.  Medical identity theft may result in false entries being entered into a medical record, or the creation of fictitious records in the victim’s name.

See Privacy Rights Clearinghouse, Fact Sheet 33: Identity Theft Monitoring Services.

To try and combat some of these other types of identity theft, many vendors now offer expanded identity theft monitoring services that provide additional monitoring services, such as monitoring commercial and public databases and online chat rooms.  These services vary widely, so you’ll need to investigate carefully to determine what service is best for your customers in the event of a data breach.  The Consumer Federation of America provides some helpful guidance about selecting an identity theft service provider and some assessments of the services offered.  See Consumer Federation of America: Best Practices for Identity Theft Services: How Are Services Measuring Up? Things may have changed since 2012, so make sure to update the information and look for additional identity theft monitoring service providers.

By looking into remedies now, you will be able to evaluate and assess the complete range of available remedies, and select the one that makes the most sense for your customers and business in the event of a data breach. You may also be able negotiate the best price and gain service concessions. None of this could be done in the middle of a data breach crisis.

Step 6: Draft Incidence Response Plan

You can now be begin drafting your Incident Response plan (the “Plan”). As a word of warning, this document can get very long and detailed, depending on the size and complexity of your organization. There are a lot of available on-line guides that can give provide guidance, such as the guides at the SANS Information Security Resources, However, to ensure the Plan is done properly, you may want to consult with a privacy and data security attorney or some other third-party vendor.

The basic elements to include in the Plan are:

Overview:  The Plan should have an overview section that outlines the goals, scope, purpose and assumptions of the Plan.

Roles and Responsibilities of Incident Response Team members:  The Plan should identify each incident response team (the “Team”) member, their contact information, and his/her role or responsibility.  It is better to have this information in writing so each Team member knows exactly what he/she is responsible for when a data breach occurs.  This information should be continuously updated, especially if one member leaves the organization.

Incident Definition and Classification:  The Plan should create an event classification system that defines what constitutes an incident, when an incident is serious, and the specific types of incidents that will set the plan in motion.  For example, port scans are not usually particularly serious, and it is doubtful that these events will set the Plan in motion. But a web security breach or a malware infection should warrant a more urgent response and the Team may need to be notified and the Plan set in motion.

Notification:  The Plan should identify the specific triggers to notify and procedures to follow when notifying the following:  the Team, insurers, law enforcement, outside attorneys, third-parties and customers.  Depending on the type and severity of the event, these groups will be notified at different times, and there will be specific procedures that need to be followed.  Include all statutory and contract breach notification requirements in the Plan.  Also include all insurance notification requirements.  If you choose to use a third-party vendor to notify customers, include all relevant contact information and details of any negotiated deal in the Plan.

Current Network Infrastructure & Payment Processing Systems:  The Plan should also identify, diagram, and include all supporting documentation regarding your organization’s web system architectures, network infrastructure, information flows, payment processing systems, and any other applicable system that contains or processes sensitive personal information.

Existing Security Safeguards:  The Plan should identify all currently operating safeguards that can assist with detection and prevention, including an intrusion-prevention system (IPS), firewall, web-application firewall (WAF), and endpoint security controls for the web, applications, and database servers.

Detection, Investigation and Containment:  The Plan should outline the procedures for detecting, investigating and containing the incident.  Keep in mind that these procedures should vary by the type of incident, the system involved, and may involve contacting third-parties such as law enforcement and forensic investigators.  Identify the circumstances when these third-parties will be brought in and include all potentially relevant information in the Plan.

Customer Remedies:  If your organization chooses to offer remedies to customers, such as identity protection service, then your Plan should identify the specific circumstances when the remedies will be offered. It should include the contact information of the third-party service provider and the terms of any deal that was negotiated.

Eradication, Cleanup and Recovery:   The Plan should also contain the procedures to follow to get the infected system back up and running.  The cleanup will vary depending on the type of system and the type of attack, but you want policies and procedures in place about how to handle it.  In order to preserve other parts of your IT system, you also want to have procedures about the steps to take before putting the infected system back into production.

Post-Incident Review and Follow-up:  Your Plan needs to include the date for a mandatory follow-up meeting with the Team in order to learn from the incident.  The purpose is to process all of the information that was learned from the incident and figure out if your security posture needs modification to prevent future attacks.  There are likely several questions that will need to be addressed, but try to avoid spending the meeting finding someone to blame. It will be a waste of time and energy and will not improve the security of your organization.

Step 7: Employee Awareness and Readiness Training

As part of your organization’s privacy program, your employees are probably already trained on privacy fundamentals like data collection, retention, use and disclosure.  Your organization should also train every employee about basic breach response procedures and protocols, like what constitutes a data breach and whom to call if a data breach is suspected.  You should also require third-party vendors to do the same.  Team members should receive regular in-depth training about how to investigate a data breach, report findings, and communicate with media and regulatory authorities.  Any completion of required training should be documented and reported to management for internal policy compliance.

Step 8: Crisis Simulation & Revision

It is important to know how your organization will fare during a breach crisis and identify and correct any gaps.  The best way to assess your organization is by running two types of breach crisis simulations: a table-top exercise and a “live” simulation.

A tabletop exercise is a simple way to practice executing your Plan without the expense or interruption of a full scale drill.  In a tabletop exercise, Team members talk through a breach crisis scenario in a “war room” type of setting.  These exercises should involve everyone on the Team so that every member has an opportunity to think through their role during a breach event.

“Live” simulations are more elaborate and tend to mimic real-world conditions more closely than tabletop exercises.  “Live” simulations are usually impromptu events that can occur at any time, including the evening or a holiday, like a real breach.  The most effective simulations involve breach response vendors that your organization has contracted with, as well as your internal Team.  In a “live” simulation, systems are actually compromised and even social media uproars can be created. Talk with your service providers to develop simulation exercise that includes everyone.

After conducting simulations, evaluate the effectiveness of your Plan to identify any gaps in your organization’s response.  Revise your Plan to fill these gaps and ensure that your organization improves.

If you follow all eight of these steps, your organization will be better prepared for the inevitable data breach.  Thanks for reading.  Please let me know if you have any questions or wish to offer suggestions based on your experience.

How to Prepare for a Data Breach (Part I)

Tags: , , Business, Data Breach, Preparation 1 comment

In the last blog post, I discussed ways that a business can try to prevent a data breach. The sad and unfortunate reality, however, is that no matter what you do, most privacy and security experts agree that your business is going to suffer a data breach.  See J.F Rice, “Are Breaches Inevitable?” Computerworld, Sept. 3, 2014. The Ponemon Institute, a leading research center, puts the probability of suffering a material data breach of more than 10,000 records in the next two years at 19%.  See Ponemon Institute, 2014 Cost of Data Breach at 1-3.

So what should a business do? Start planning NOW for a data breach by creating an Incident Response Plan that your organization will follow in the event of a data breach.  Doing so can reduce the cost of a data breach by, on average, $18 per record. Id. There are eight steps involved in preparing for a data breach and creating and implementing an adequate Incident Response Plan. The first four steps on how to prepare for a data breach will be discussed today, and the next four steps will be discussed next week.

Step 1: Assemble an Internal Incidence Response Team

Data breaches are multi-faceted events that require coordinated strategies and responses across the organization. To deal with one, you need an incidence response team with representatives from all of your company’s functional groups.  At the very least, your incidence response team should include representatives from the following groups who are available 24/7 in the event of an after-hours emergency:

Executive Management: Ideally, your team should have a management level executive with broad decision-making authority to insure that the breach management process moves quickly. A quick response time and effective implementation are critical factors when trying to minimize the financial and reputational harm that can occur from a data breach.

If an upper management executive can’t be spared, some companies appoint a lead on the incident response team with delegated authority to take certain actions and make certain decisions. This approach is a great alternative, but it will be inefficient when an action exceeds the lead’s delegated authority and requires approval from the executive management team. But this inefficiency will have to be tolerated in the absence of an upper level executive.

IT and Security: IT and security team member play a critical role by identifying the problem with your computer system as they are the most familiar with the network systems and security controls in your organization. Usually, however, the internal IT and security team does not conduct the forensic investigation that is needed to track down the breach and how it occurred.  Instead, you will need an outside forensic group that possesses specialized skills and training to perform digital forensic identification and mitigation of the breach. Your internal team will be the liaison with this outside forensic group and work with them to explain your network and its security controls.  Don’t try to cut down costs by avoiding the outside forensic group.  Although your internal IT staff might be outstanding, it will cost you more time and money over the long run by having them try to identify the breach. Remember that time is critical and you want to identify the problem and fix it as soon as possible. Better to use reputable forensic specialists for this task.

Legal and Compliance: You need someone from legal and/or compliance to identify the notification, legal and regulatory requirements of the breach response. This includes determining if there is an obligation by law or contact to notify internal organization clients or business partners of the breach and what the content of the notice should be. Breach notification requirements vary by state and contract, so you will need someone from legal and/or compliance to make sure you fulfill your legal obligations with respect to the data breach. This will be discussed more fully below at Step 4. If your organization does not have a legal department, hire an outside attorney who specializes in privacy and data security to help you understand your notification obligations in the event of a data breach.

Public Relations/Communications: You should also have someone who is responsible for disseminating information about the breach to your internal organization and coordinating the response to external public. With respect to the internal organization, your internal communications team will make sure that all your employees have talking points about the breach if they are approached.  For external communications to the public, you should hire a PR firm that specializes in crisis communication, and have this PR firm take directions and work closely with your internal communications team to coordinate the response.  Don’t skimp by trying to have your internal communications team handle the media and public communications. Your reputation and business could be irreparably harmed if public communications are done poorly or improperly.

Customer Service: After a data breach, customers have lots of questions, especially ones who are worried about identify theft and fraud. Your organization’s customer service department plays an important role in rebuilding your customers’ trust and ensuring that they understand what happened and how your organization is responding.  If your organization cannot handle the anticipated call volume, many organizations engage a call center and set up a dedicated hot-line that consumers can call to get information about the breach.  Websites have also proven to be useful, so that is another option to be considered. No matter what method used, you will need your customer service department to help you understand the best way to regain your customers trust.

For small organizations, it may not be possible to have different people serve these different functions, since there may not be a separate communications or a legal department. That doesn’t matter. The important point to recognize is that these roles are needed if a data breach occurs, and the business needs to identify who is going to fill them – even if it’s the same person!

Step 2: Establish Relationships with Breach Response Vendors and Law Enforcement

The second step is to establish relationships with breach response vendors, regulators and law enforcement before having a data breach.

With respect to regulators and law enforcement, reach out to the relevant Attorney Generals, Secret Service, FBI, and any other relevant regulator to introduce your business and discuss data privacy issues as soon as possible. It shows that your organization is serious about data protection and privacy and might earn your regulators’ trust and respect. You don’t want your first introduction to be when you report a data breach! A prior personal relationship may aid you when it comes time to report a data breach, and the regulators may be more inclined to offer advice, listen to your side of the story, and give you the benefit of the doubt about the steps you have taken.

With respect to vendors,  several types of third-party vendors perform critical functions and are needed during a data breach.  The most relevant to investigate provide the following services: Computer forensics, public relations, notification activities, consumer remedies (credit monitoring and identity theft), call centers, and legal services.

By contacting vendors before a breach occurs, you can explore the different options available and determine the best option for your organization. It is much more difficult to assess options while in the middle of a crisis, and you are more likely to purchase services that you don’t need. Also, if you are reaching out to a vendor for the first time in the middle of crisis, you are much more likely to be charged a higher rate for emergency services. By preparing in advance, you can negotiate on price and services and get the best available deal.

Step 3: Cyber-Liability Insurance

As part of your incident response plan, consider whether your organization needs cyber-liability insurance. Effective May 1, 2014, the Insurance Services Office (ISO) revised its Commercial General Liability (CGL) Policy form to exclude losses associated with a data breach.  See Insurance Journal, ISO Comments on CGL Endorsements for Data Breach Liability Exclusions, July 18, 2014.  Since the vast majority of U.S. CGL polices are partially or completely written on ISO’s standard form, your organization’s future CGL policies will likely exclude data breaches, if they don’t already.

To correct this insurance gap, consider purchasing cyber-liability insurance, which provides coverage two categories: first-party or third-party losses. First-party losses are the expenses incurred as a direct result of responding to the breach, such as computer forensics, public relations, notification costs, and others. Third-party losses are the losses incurred from claims for damage brought by customers, consumers, and others. Depending on your organization’s needs, it may be wise to purchase insurance for one or both types of losses. Given the exorbitant costs of a data breach, it may be well worth it.

Step 4: Determine Breach Notification Requirements

Organizations should be familiar with the data breach notification requirements that govern their company in the event of a data breach. These requirements come from two sources: contracts with third parties and the states where you conduct business and/or have customers.
Nearly all of the states (47 states plus the District of Columbia, Puerto Rico, and the Virgin Islands) have passed some form of a data breach notification law. These laws contain the following general categories of information:

•  The definition of “personal information” identifying specific data elements that trigger reporting requirements;
•  The definition of what entities are covered;
•  The definition of a “security breach” or “breach” of a security of a system”
•  The level of harm requiring notification;
•  Whom to notify;
•  When to notify;
•  What to include in the notification letter;
•  How to notify
•  Exceptions that may exist to the obligation to notify (or when notification may be delayed);
•  Penalties and rights of action.

Although all breach notification laws contain the same general categories of information, the details often differ drastically and you need to know what specific states apply to your organization and what is required by the state’s breach notification law. For example, Massachusetts differs substantially from many other states about who needs to be notified and the content of the data breach notification letter. See M.G.L. c. 93H. Consult with an attorney and/or a data breach notification vendor to help you assess your current situation and determine what breach notification statutes are applicable.

After determining the requirements from the relevant breach notification statutes and contracts, create a chart or spreadsheet that identifies the critical details for each state, when these requirements are triggered, and the steps that need to be taken in the event of a data breach. This chart will become part of your incident response plan, so update it regularly so that it remains current. All of this may become moot if a national breach notification statute is ever passed, but I’m not going to hold my breath.

This completes the first four steps about how to prepare for a data breach and develop an incidence response plan.  Thanks for reading. Check back next week for Part II.