Security

Security

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.

Credit Card Security for Small Business (Pt. 1)

Business, Data Breach, PCI DSS, Prevention, Privacy, Security, Uncategorized 3 comments

Staples recently suffered a data breach that resulted from malware infecting its point-of-sale (“POS”) systems at several stores.  This should not be surprising, since a recent study by Verizon showed that a significant portion of data breaches are the result of POS system intrusions. So what’s a business to do?

Many small businesses avoid this problem by refusing to accept credit cards and only accepting cash or checks.  But that’s not a solution for businesses that wants to accept credit cards.  For these merchants, the only realistic solution is to comply with the Payment Card Industry Data Security Standards (“PCI DSS”).

PCI DSS is administered and managed by the Payment Card Security Standards Council (PCI SSC) that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB).  PCI DSS is a rigorous set of security requirements (“Requirements”) designed to ensure that all companies that process, store or transmit credit card information maintains a secure environment in order to protect cardholder data.  “Cardholder data” is any personally identifiable data associated with a cardholder, such as an account number, expiration date, name, address, social security number, etc.

Every merchant that accepts credit cards agreed to abide by the PCI DSS as part of their merchant account processing agreement. See e.g., NPC Merchant Processing Agreement at § 12.B.ii, 14.O. Failure to adhere to these requirements can lead to stiff penalties, an exorbitant PCI DSS non-compliance fee, and/or increased transaction fees or a termination of the right to accept credit cards.

If a security incident, such as a data breach, occurs, a business is potentially liable for the following charges:

  • Data Security Fine– Up to $500,000 fine per security incident.
  • PCI Non-Compliance Fines– Up to $50,000 per day for non-compliance with published standards.
  • Card Replacement Fees– $3 – $10 per card x total number of cards compromised.
  • Refund Fees– Potentially held liable for all fraud losses incurred from compromised account holders.

These penalties are assessed by credit card brands, acquiring bank, and the merchant’s credit card processor, and are in addition to other losses, such as harm to business reputation, that can result from a data breach, as I discussed in an earlier blog post.

To avoid this parade of horribles and decrease the likelihood that cardholder data will be lost, small to mid-sized businesses need to regularly comply with PCI DSS requirements.

Compliance with PCI DSS is an ongoing process and typically involves the following four steps:

  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. ReportingPCI DSS Qualified Security Assessor (QSA) and/or business submits required documentation to validate compliance with PCI DSS (e.g., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)), including documentation of all compensating controls.
  4. Clarifications– QSA and/or business clarifies ROC and/or SAQ, if need at the request of the acquiring bank, processor or payment card brand.

The first two steps will be discussed in this week’s blog post and the last two will be discussed next week.

I.   SCOPE OF PCI DSS REQUIREMENTS

The first step of PCI DSS is to accurately determine the scope and breadth of the environment in your business regarding credit cardholder data.  The Cardholder Data Environment (CDE) is composed of all people, processes and technology that handle or have access to cardholder data or sensitive authentication data.  The scoping process includes identifying all system components that are located within or connected to the CDE and can include the following:

  • Network devices (wired and wireless)
  • Servers
  • Applications
  • Virtualization components, such as virtual machines, virtual switchers/routers, virtual appliances, virtual applications/desktops, and hypervisors.

Scoping needs to occur at least annually and prior to the annual assessment for PCI compliance validation. An organization must identify all locations and flows of cardholder data to ensure that all applicable parts of the CDE are included in the scope of PCI DSS assessment.

Network Segmentation

One helpful way to reduce the scope of PCI DSS assessment is to use segmentation, which isolates cardholder data environment from the remainder of your organization’s network.  Reducing the scope of PCI DSS assessment can lower the cost and difficulty of maintaining PCI DSS controls and reduce the risk for you business.

To be outside the scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that the security of cardholder data would not be compromised if the security of the out-of-scope component was compromised. More details on segmentation are contained in the Requirements at p. 11 and in Appendix D.

Use of Third Party Service Providers/Outsourcing

Another helpful way to reduce the scope of your PCI DSS assessment is by using a third-party to store, process or transmit cardholder data on your behalf or to manage CDE components. If you use third party service providers, however, you must clearly identify the specific roles and responsibilities of the service provider with respect to cardholder data and PCI DSS. PCI DSS specifically calls for developing and maintaining a responsibilities matrix for each service providers. See id. at Requirement 2.2.1.

Many service providers have these matrices available to describe their standard service to PCI merchants. To obtain one, simply ask for the “PCI Responsibilities Matrix.” If your service provider does not have any idea what you are talking about, it’s time to find a new service provider. PCI DSS allows you to outsource much of the handling of cardholder data to third-parties, but you cannot avoid responsibility for ensuring that the data is kept secure and complying with PCI DSS.

II.  PCI DSS ASSESSMENT

The second step is to assess whether your business’s CDE complies with the 12 PCI DSS Requirements and the accompanying procedures contained in the Requirements. There are two main ways to fulfill your assessment obligations:

  1. Hire a PCI DSS QSA
  2. Do-It-Yourself

Hiring a PCI DSS QSA

PSI DSS QSA’s are organizations that have been certified by the PCI Security Standards Council to assess compliance with PCI DSS standards. QSA’s perform data security assessments, make recommendations, and certify compliance. Hiring a QSA will save you the time it would take to perform your own PCI DSS assessment and provide you with the peace of mind that the job was done properly.

The big downside to hiring a QSA is cost. QSA fees are generally quite expensive. One quote charged a base $5,000 fee plus $200 for every hour. Additional costs may include the equipment/software to fix whatever problems the QSA finds, which is also costly.

If you’re interested in hiring a QSA, here is a list of PCI DSS certified QSA companies.

Do-It-Yourself

Another way to assess your CDE for PCI DSS compliance is to do-it-yourself.  This may seem like a daunting task but it can be done and may not be that difficult depending on the complexity of your organization and how you process cardholder data.  The PCI SSC website provides a helpful section here that is geared towards helping small merchants comply with the Requirements.

The website also provides a helpful Quick Reference Guide that summarizes the Requirements.  It is a must-read for any business that accepts credit cards and is considering conducting their own PCI DSS assessment.  The Guide is a fairly readable 40 pages with helpful tips and explanations.

Here’s a brief overview of the Requirements and some tips for assessing in order to give you an idea of about whether self-assessment is feasible. This overview is not sufficient to assess whether your organization’s CDE complies with the Requirements. To conduct your assessment, you need to review the Requirements and follow the procedures for assessment.

Requirement 1:  Install and Maintain a Firewall Configuration to Protect Cardholder Data

This Requirement is fairly straightforward and easy to implement.  A firewall should be installed on any network, computer or device that is part of your CDE and contains or accesses cardholder data.  For most small businesses, this means ensuring that your PC’s and network have a firewall.  Most operating systems come with some sort of security package that includes a firewall.  Just make sure that you regularly check to see that the firewall is working, and update it as necessary.  If you don’t have a firewall, look into a commercial firewall, such as Symantec, to install on your computer and protect your network.

Requirement 2:  Do Not Use Vendor Supplied Default Passwords

This Requirement is also fairly straightforward and easy to implement.  The easiest way for a hacker to access your internal network is to try vendor default passwords or default system software settings in your payment card infrastructure.  Far too often, merchants do not change default passwords or settings when hardware or software is deployed.

 Don’t let this happen to you! Change your vendor supplied passwords and system settings immediately.  Follow these Microsoft Tips for Creating a Password when choosing a new password or use this password generator.

Requirement 3:  Protect Stored Cardholder Data

As a general rule, cardholder data should not be stored unless it is absolutely necessary to meet the needs of your business. Sensitive data on the magnetic stripe or chip must never be stored.

If your business stores the primary account number associated with a credit card, it must be made unreadable through encryption or other technological measures. This can get very expensive and risky, so consult with a QSA to ensure compliance with PCI DSS. Best practice, however, is not to store any cardholder data.

Requirement 4: Encrypt Transmission of Cardholder Data across Open Public Networks

Cybercriminals may be able to intercept transmissions of cardholder data over open public networks, so it is essential to prevent their ability to view this data.  Encryption renders transmitted data unreadable by an unauthorized person.

If you accept credit card data on your website, then you should obtain an SSL Certificate.  A SSL certificate ensures than any sensitive data transmitted through your website is encrypted. One place to use a SSL is on a payment page during checkout.  There are plenty of SSL Certificate vendors out there, so choose one that’s reputable.

If credit card data is transmitted over a wireless network, your wireless router should be password-protected and encrypted.  This is fairly easy to do and your wireless router should have instructions about how to password protect and encrypt your router.  Encrypt your  wireless router with the industry standard IEEE 802.11i (WPA2) and not WEP, which is no longer accepted as a security control by PCI DSS.

Requirement 5: Protect systems against malware and regularly update anti-virus software

This is also a no-brainer and easy to do.  Use anti-virus software on all systems, such as PCs and servers, commonly affected by malicious software.  This anti-virus software should be kept current, perform periodic scans, and generate audit logs that need to be retained according to PCI DSS Requirement 10.7.  Make sure that the anti-virus mechanisms are continuously running and cannot be disabled or altered by users.

Requirement 6:  Develop and Maintain Secure Systems and Applications

Security vulnerabilities in systems and applications allow criminals to access cardholder data. Some of these vulnerabilities are eliminated by using PCI approved PIN transaction security devices (i.e. PIN pads and credit card terminals) and PCI validated POS (Point-of-Sale) & payment gateway software.  Check the links above to make sure your current security device is compliant and your current software is validated.  If not, both should be upgraded.  Regularly install all vendor-provided updates, software and security patches to maintain compliance.

Requirement 7: Restrict Access to Cardholder Data

Cardholder data should only be accessed by authorized personnel and not by everyone in your company. Put systems and processes in place to limit access based on need to know and according to job responsibilities. Janitorial staff that cleans your offices should not be permitted to have access to cardholder data!

Requirement 8:  Identify and Authenticate Access to System Components

Assign a unique identification (ID) to each person with access to cardholder data and don’t allow sharing of ID’s. You want to be able to trace all activities relating to cardholder data on your system to known and authorized users. If there is a problem, you will be able to determine and isolate the source in order to prevent additional difficulties. If an employee with authorized access gets terminated, lock out their ID and prevent them for continuing to access cardholder data.

Requirement 9: Restrict Physical Access to Cardholder Data

Any physical access to data or systems that house cardholder data provides an opportunity for a person to access or remove devices, data, systems or hardcopies. To minimize this risk, restrict access to appropriate personnel and develop procedures to ensure that only appropriate personnel have access to cardholder data.

One way to do this is through the use of ID cards that only allow certain employees to have access to certain areas. Visitors should only be allowed access to certain locations, such as the front of a cash register, and not be allowed to view cardholder data. Furthermore, all media containing cardholder data should be locked in a secure location that only authorized personnel can access.

Requirement 10:  Track and Monitor All Access to Network Resources and Cardholder Data

Organizations must also track and monitor all access to cardholder data and related network resources. Logging mechanisms and the ability to track user activity are critical for effective forensics and vulnerability management, and a merchant must ensure the presence of logs that allows thorough tracking and analysis in the event something goes wrong and cardholder data is improperly accessed.

Requirement 11:  Regularly Test Systems

An organization must also have their system scanned for internal and security vulnerabilities by an Approved Scanning Vendors (ASVs).  ASVs are organizations that validate adherence to certain PCI DSS requirements by performing vulnerability scans of merchants and service providers.

Internal and external vulnerability scans are conducted in a similar fashion.  Both scans are automatically administered via a computer program and an Internet connection, but one program usually cannot simultaneously conduct both scans.  An external vulnerability scan looks for holes in your network firewall(s), where malicious outsiders can break in and attack your network.  By contrast, an internal vulnerability scan operates inside your business’s firewall(s) to identify real and potential vulnerabilities inside your business network.  Internal scans may be performed by internal staff, but all external scans must be performed by ASVs for PCI DSS compliance.  Scans must be performed as needed, until passing scans are obtained.

To comply with PCI DSS, your business needs to pass an initial internal and external scan, and then pass 4 consecutive quarterly scans in subsequent years.  As part of these scans, regularly check PIN entry devices and PCs to make sure no one has installed rogue software or “skimming” devices.  Talk to your ASV to make sure that they are checking for this and for tips about how to monitor yourself.

Requirement 12:  Maintain a Policy that Addresses Information Security for all Personnel

Your organization must also develop and maintain an information security policy that informs employees of their expected duties related to security.  All employees should be aware of the sensitivity of cardholder data and their responsibilities for protecting it.  This policy should be reviewed annually and updated when the environment changes.

That’s it for this week.  Thanks for reading and please let me know if you have any questions. Check back next week for the last two steps that need to be taken in the process of complying with PCI DSS.

BYOD, Privacy and Security

Tags: , , , , , Business, BYOD, Privacy, Security 1 comment

It is very common for employers to allow or require employees to bring their own mobile devices, iPads and laptops into work and use the devices for work (“BYOD”).  A recent study reveals that the numbers are staggering:

• 89% of employees mobile devices connect to corporate networks
• 65% of companies allow personal devices to connect to corporate networks;
• 78% of companies note that 2x as many BYODs connect than did 2 years ago;
• 68% of American small businesses already embrace BYOD.

BYOD is obviously popular with businesses and their employees.  But it creates enormous risks and concerns for businesses and employees that can only be properly handled by an effective BYOD Policy.

Business Risks and Concerns

The primary concern of most employers is security and the unauthorized dissemination of confidential business information to third-parties.  Allowing personal mobile devices increases the risk of unauthorized access, disclosure and destruction of business data, as employees can lose their mobile devices that contain confidential information.  Or an employee can download viruses or malware along with the latest app that can than infect the entire corporate network.

A related concern is an increased risk for potential liability from a data breach, particularly those breaches involving access to personally identifiable financial or health information. For example, doctors regularly lose mobile devices, or have them stolen, that contain patient personal health information.   These data breaches cost companies a significant amount of money and can lead to an unwanted and costly government investigation.

To the extent that nonexempt employees use personal mobile devices for work, the employer may also face exposure under the federal Fair Labor Standards Act or similar state statutes for failure to compensate these employees for overtime.  If nonexempt employees use these devices for work-related purposes outside their normal work hours, the employer may be required to pay them overtime compensations.

Employee Privacy Concerns

The use of personal devices for work-related activities offers employees greater convenience, flexibility and other advantages.  Employees are very attached to their personal mobile devices and a recent study shows that nearly 1/3 of employees would rather lose their wallet than their mobile device.  Using personal mobile devices for work raises some serious concerns among employees as work encroaches more and more on their personal life.

Loss of privacy and control over their electronic information are the two biggest concerns employees typically have with BYOD.  With respect to privacy, employees are concerned that employers will inappropriately access or use their personal information, particularly financial and health information, in ways that will harm them at work.  Employees are also concerned about losing control of their electronic information (e.g. photographs, videos, contacts, etc.) when employers attempt to remove or “wipe” business information from the employees’ device, which can be done remotely.  Employees store a lot of irreplaceable pictures, videos and other personal information on mobile devices and don’t want to lose these valuable memories.

BYOD Policy

To deal with these concerns, employers should develop a comprehensive BYOD policy and program that includes regular training and monitoring.  Below are some of the key issues that should be addressed:

Eligibility

Organizations should make clear who in the organization is allowed to use personal devices, whether on an ad hoc basis for a specific purpose or as a permanent replacement for corporate devices.  This can be viewed as a privilege to be earned, a response to employee demand, a requirement for certain types of roles, or a combination of these things.  For example, attorneys at different law firms are now regularly permitted to use their own mobile devices and iPads, but administrative assistants are not.  This is a function of client and partner demands and the need to be available 24 hours a day, 7 days a week.  Administrative assistants do not want or have the same client demands, so they are not permitted to use their mobile devices to access law firm networks.

Allowed Devices/Operating Systems

Organizations should also make a decision about what operating systems will be supported on their BYOD policies.  Two areas that are a real challenge for BYOD policies are the diversity and the frequency of updates for the operating systems on the various devices.  The various choices include Android from Google; iOS from Apple; Windows Phone and Windows Mobile from Microsoft; Blackberry OS from RIM; Symbian from Nokia; and a few others.  What’s worse, some operating systems have multiple versions and the updates to the devices may or may not be automatic from the carrier company or controlled by the enterprise.

These conditions make it very challenging to standardize just a few configurations that you will allow workers to use and support.  However, it is a best practice to set a minimum operating system version threshold for users to bring in their own devices as a baseline requirement to protect corporate data and apps running on them.  This may eliminate some of the older phones that are still in use, but you need to take minimal steps to ensure the security of your corporate network without draining company resources.

Wiping Data off the Device

When a smart phone is lost or stolen, or when a worker is no longer employed by the company, it may be necessary to forcibly wipe data off the employee-owned device.  The manner that this is done is largely a factor of the mobile device management tools that are used.  Some tools allow a selective wipe so that only corporate data is removed while not affecting the personal data.  Other management tools simply wipe the entire device clean.

Make sure that the BYOD policy clearly explains the data wipe method you will be using and get a signed acknowledgment if the employee chooses to use their own device.  Also consider using a user agreement, which will be discussed below.  To the extent feasible, it is better to selectively wipe corporate data and to levee personal data alone.  This will minimize the future risk of an employee lawsuit while still protecting the organization’s confidential information.

User Agreements

Companies should tread lightly when enforcing policies on personally-owned devices that are used for business.  From a legal standpoint, you should have a user agreement, which is a contract between the company and the end user regarding the use of the employee’s personal mobile device in the business environment.  Best practice is to have this contract presented to the employee regularly and have it affirmed periodically, typically once a year.

Key topics that should be considered for a user agreement include:

The Data Wipe Policy – The user agreement should specifically identify when information will be wiped from the device and what types of data will be wiped.

The Photo Policy – The user agreement should specifically identify what employees are not permitted to snap photos of (e.g. sensitive areas of the work environment; products in development; white boards and sensitive info or drawings).

Definition of Company Information – The user agreement should clearly explain what information is considered company information, how it must be handled, and that the organization ultimately owns all company information.

Web Filtering Requirements – Employees are expected to police their own behavior in terms of what shows up on their screens while connected to the corporate network and at work (e.g. no pornographic photos when the device is used in a business context).

Data Breach Trigger Policy – Employees must promptly report the loss or theft of the device and help the company determine if sensitive data is at risk.  The user agreement should specify the time-frame for reporting a lost or stolen device and the procedures regarding locking and wiping the device.

Maintain Certain Security Measures – The user agreement should also specify what security measures the employee should maintain with the device, such as installing certain software, maintaining updates, requiring antivirus protection, and other security measures.  It should also require a strong password to access the device.

Acceptable Use Policy– Additionally, the user agreement should specify how employees handle company information on their personal device and what can be done with this information.  Typically, these policies prohibit employees from downloading company information onto third-party cloud service document storage sites, such as Dropbox or Google Drive.

Monitoring Policy– The user agreement should also inform the employee about what kind of monitoring will be used by the employer with respect to the device and the BYOD policy.  This may include tracking the device’s location, monitoring internet and other activities, key-stroke logging, phone call monitoring, and other types of monitoring.  This is a very sensitive area for employees, so be sure to consult with an attorney to determine the scope of monitoring that is legal in your jurisdiction, explain the policy clearly to employees, AND obtain the employee’s consent.

eDiscovery –The user agreement should also let employees know how e-discovery requests will be handled, should the need arise.  This will be discussed further below.

Cost Sharing/Reimbursement

A primary reason why employers adopt a BYOD policy is to shift costs to employees.  The BYOD policy should clearly identify what costs will be borne by the employee and what costs will be reimbursed.

Some of the questions to ask and answer in connection with the policy are:

• Are individual users entitled to reimbursement?

• If so, for what services and under what conditions (e.g., voice usage, data usage, Wi-Fi hotspot usage, roaming usage, business vs. personal usage, manager approval, etc.)?

• Are any services not eligible for reimbursement (e.g., SMS/MMS, ringtone downloads, 411 calls, any service not explicitly identified as eligible for reimbursement)?

• Are there any caps on reimbursement (e.g., in the form of fixed monthly stipends or maximum-expense limits, independently of charges incurred)?

• Are individual users ever eligible for full or partial reimbursement of device acquisition or replacement costs?

Different companies answer these questions in different ways and there are numerous acceptable BYOD policies.  Choose the one that’s best for your business.

eDiscovery

When an employer is involved in litigation, it needs to know where company information is located, it’s content, and needs to review it in order to determine whether to ultimately produce it.

Electronically stored information, or ESI, is subject to discovery, which means it can be requested as evidence in a court case.  ESI is a category of discoverable information separate from print documents, and includes both structured and unstructured data such as emails, instant message logs, Word documents, Power point presentations, and other types.

In litigation, eDiscovery is the process of identifying, collecting, preserving, reviewing and producing relevant electronic data or documents.  Determining which ESI is relevant is complicated and expensive due to the vast quantities of electronic information, and the difficulty in obtaining it and reviewing it to determine what information is relevant and to not produce privileged or confidential information.

BYOD and mobile devices present four challenges to eDiscovery:

• The company does not own or physically control the devices;

• There are a wide variety of potential data types to consider;

• The data can potentially reside in multiple locations;

• Safeguarding and retrieving the data can be difficult.

If you have a BYOD policy, or are considering implementing one, consider the following best practices to ensure that it is eDiscovery friendly:

• Mandate that employee devices be configured to save information directly to the company servers.

• Sync data between employee devices and company servers regularly.

• Ensure that your BYOD policy is forthright and outlines the exact process for eDiscovery, including a clear chain of custody.

• Consider purchasing and implementing one of the many applications capable of separating business data and personal data, making it especially easy for employers to locate discoverable data.

By taking these steps, you will minimize the costs associated with eDiscovery in case you are ever involved in litigation.

Termination of Employment Relationship

As part of your BYOD policy, you should outline the process for what happens when the employment relationship is terminated.  In most cases, a company wants to remove its data from an employee’s personal device when he or she leaves.  To accomplish this, the organization may require the employee to submit the device to the IT department, wipe it remotely, or simply tell the employee to delete the data.  Choose what policy and procedures work best for your organization.  Also make sure that employees are disconnected from the corporate network and are no longer able to access it after the employment relationship is ended.

That’s it for this week. Let me know if you have any questions about BYOD or if your BYOD policies contain some interesting provisions. Have a Happy Holiday!