Category Archives: Security

The Future of Phishing is Deepfakes. Here’s How You Can Combat “Deep Phishing.”

Posted on by

Phishing is used by bad actors to send a communication, e.g., an email or IM, pretending to be a trustworthy source in order to get people to divulge sensitive information such as usernames, passwords, credit card information, date of birth/SSN, etc. An example is where you receive an email that appears to be from your bank saying your account has been suspended, providing a (malicious) URL you can use to verify your credentials or credit card information to unlock your account. General phishing attacks are sent in waves to large groups of recipients, hoping some will think it’s real and divulge their information.

Bad actors also use targeted phishing, where a phishing communication is targeted to one or a small group of recipients, often where the actor has some basic information about the recipients. Two examples of targeted phishing are spear phishing, which is a phishing attack targeted at a single company, organization, or individual, and whaling, which is a spear phishing attack targeted directly at company executives, finance personnel, and other high-value targets within an organization. Targeted phishing communications, especially whaling, usually include credibility-enhancing details designed to entice someone to transfer company funds, provide sensitive company information, or obtain credentials that can be used to attack a company’s network. A well-known example of whaling is an email purportedly from a CEO to a controller containing some information designed to trick the recipient into thinking the communication is legit, directing the controller to pay a fake vendor invoice right away in an attempt to trigger a wire transfer to the bad actor’s own account. 

Anti-phishing tools and strategies employed by many companies, as well as anti-phishing training which is becoming more prevalent, have helped minimize the success of phishing attacks. Unfortunately, a dark revolution in phishing is on the horizon. “Deepfakes” (derived from “deep learning” and “fakes”) use artificial intelligence to create video or sound of a human that is virtually indistinguishable from an authentic recording. A well-known early example is a deepfake created by Jordan Peele of Barack Obama giving a public service announcement warning the public of the dangers of deepfakes (you can view it by clicking here). While deepfakes’ first broad application was in the realm of pornography and deepfakes often have telltale signs that they are not authentic, technology continues to improve by leaps and bounds. People have begun to create sophisticated, difficult-to-spot deepfakes and edited videos for nefarious purposes, such as political attacks. Imagine the well-timed online release of a video that appears to be a prominent politician admitting he took a bribe; even if it’s fake and the politician vehemently denies the veracity of the original video, the bad publicity may be enough to sway an election.

It is only a matter of time before deepfakes are used regularly in targeted phishing attacks against companies and individuals. Imagine the whaling emails of the 2010s replaced with a deepfake voicemail sounding exactly like your CEO, a deepfake video message that appears to be from your CEO, or even a deepfake audio or video call with your “CEO,” asking you by name to expedite a large wire transfer to a vendor. I call the use of deepfakes for enhanced phishing attacks “deep phishing.” Where in the past sophisticated makeup and sets would be needed to fool someone into thinking they were talking to someone else, deepfakes will make doing so disturbingly easy and relatively inexpensive with the right technology. It’s only a matter of time.

Strategies to Combat Deep Phishing

It’s impossible to predict when deep phishing attacks will become prevalent. While security companies will likely develop and offer solutions in the future designed to help companies detect deepfakes, such solutions do not exist today, and even if they are available in the future not all companies will be able to afford or implement such tools. Companies should consider proactively employing less-costly, easier-to-implement strategies today to protect against deep phishing attacks. These strategies that may help protect your company against today’s targeted phishing attacks as well. Here are some suggested approaches:

Manual Verification of Targeted Communications

The simplest way to combat deep phishing is to manually verify any communication typically used in targeted phishing attacks, such as a request to transfer funds over a certain threshold to a third party, a request to send your login credentials to someone, or a request to send sensitive customer or business information to someone. We’ll call these types of communications “targeted communications.” By designating two people that must sign off, and by ensuring that one verification must be provided via contact initiated from the recipient (using the company’s phone book – beware spoofed phone numbers in phishing emails), companies can help reduce the risk of falling prey to a phishing or deep phishing attack.

Authenticated Communications

Another strategy to combat deep phishing is to use an authenticated communication. Authenticated communications use an auditory, written, visual, or action key or watermark, changed periodically, which must be included in targeted communication. If a communication includes the key, the communication can be considered authentic. For example, depending on the level of security required, a key could be a spoken phrase (e.g., “seventeen bravo charlie”) or keyword (e.g., “tangerine”) in audio; a specific pin worn on a lapel, or specific background item or hand signal, in a video; or a specific image file or special signature inserted into a written communication. A key could also be an action such as a 5-second pause in a recording. Companies could also use multiple keys, or rotate among different key types. Unless the bad actor knew the authentication key(s), a company would have a greater chance of catching a deep phishing attempt before it was successful.

For enhanced security, consider using an algorithmic key (e.g., a 6-digit code generated by an RSA token or Google Authenticator that changes every 60 seconds). Use of an algorithmic key will make it extremely difficult for a bad actor to successfully conduct a deep phishing attack.

Multiple Vector Communications

Another strategy to combat deep phishing is the use of a multiple vector communication. Just as multi-factor security authentication requires you to provide two or more things you know, have or are in order to authenticate your identity, a multiple vector authorization would require a targeted communication be sent through two or more communications methods, or “vectors,” at or close to the same time. For example, in order to be considered genuine, an email or voicemail communication must be accompanied by a text message from the requestor verifying the request within 10 minutes. Without the verifying communication, the original request would be rejected.

Multiple Vector Authentication

For extremely sensitive requests, companies could consider combining both authenticated communications and multiple vector communications into a multiple vector authentication. In order for someone to take action on a target communication, the requestor must provide a key broken into two or more parts, each sent via a separate communications vector. Once all communications are received, the key can be assembled and verified by the recipient. The key would need to be changed regularly. If any of the communication vectors is missing the key or has an old key component, there’s a good chance it’s a phishing or deep phishing attack.

Make Phishing and Deep Phishing Training Your Cornerstone

Finally, it’s worth reiterating that the most important thing a company can do to combat phishing or deep phishing attacks is to continually educate your employees on the dangers of phishing and deep phishing. Make this a cornerstone of your anti-phishing strategy. Ensure all employees know what to look for when it comes to phishing, and train them on the dangers of deep phishing. Training should apply to anyone who has access to sensitive information or system access. Ensure your vendors (especially those with integrations to your systems) are contractually obligated to perform anti-phishing training for their personnel at least semi-annually and to have reasonable administrative, procedural and technical security measures in place. If you use a strategy to combat deep phishing, ensure the right personnel are trained on it, and that the details are kept strictly confidential. Otherwise, ensure targeted communications are verified manually before they are acted upon. The best anti-phishing strategy in the world won’t stop a phishing or deep phishing attack if it’s not applied in practice.

Eric Lambert is commercial counsel with Trimble Inc., a geospatial solutions provider focused on transforming how work is done across multiple professions throughout the world’s largest industries. He serves as division counsel for the Trimble Transportation business units, leading providers of software and SaaS fleet mobility, communications, and transportation management solutions for the transportation and logistics industry. He is a corporate generalist and proactive problem-solver who specializes in transactional agreements, technology/software/cloud, privacy, marketing and practical risk management. Eric is also a life-long techie, Internet junkie and an avid reader of science fiction, and dabbles in a littlevoice-over work. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

The Promise of, and Legal Issues and Challenges With, Blockchain and Distributed Ledger Technology

Posted on by

[Originally published in December 2016. Updated on April 7, 2018 to clarify the explanation of blockchain and distributed ledger technology and to add more information on the legal risks and challenges.]

Blockchain and distributed ledger technology is poised to revolutionize many aspects of the world around us. It may prove to be as disruptive and innovative of a force as augmented reality. Many people associate “blockchain” with “Bitcoin,” whose meteoric rise as a cryptocurrency has been well reported. However, they are not one and the same. Bitcoin is an application; blockchain and distributed ledger technology are the methods behind it.  But what is it? How might it change the world? And what legal and other risks does it bring?

What is Distributed Ledger Technology and Blockchain?

The Old – Centralized Ledgers

Centralized ledgers (a database, list, or other information record) have played an important role in commerce for millennia, recording information about things such as physical property, intangible property including financial holdings, and other assets. The most recent innovation in centralized ledgers has been the move from physical ledgers (paper, stone tablets, etc.) to digital ledgers stored electronically. A “centralized ledger” is a ledger maintained and administered in a single, central location (e.g., a computer database stored on a server) accessible by anyone without use of access controls (public) or through an access control layer by persons or organizations with valid login credentials (permissive). This is a “hub-and-spoke” system of data access and management. Centralized ledgers have historically had many benefits, such as minimized data redundancy, limited number of access points to the data for security purposes, centralized administration, and centralized end user access. However, there are also disadvantages, such as greater potential for loss or inaccessibility if the central location suffers a hardware failure or connectivity outage, inability to recover lost data elements, and a dependence on network connectivity to allow access to the ledger by its users.

The New – Distributed Ledgers

Distributed ledgers seek to address these disadvantages by distributing (mirroring) the ledger contents to a network of participants (aka “nodes”) through a software programso that each participant has a complete and identical copy of the ledger, and ensuring all nodes agree on changes to the distributed ledger. Nodes can be individuals, sites, companies/institutions, geographical areas, etc. There is no centralized administrator or “primary node” — if a change is made to one copy of the ledger, that change is automatically propagated to all copies of the ledger in the system based on the rules of the system (called a “consensus algorithm“) which ensures that each distributed copy of the ledger is identical. For example, in Bitcoin, each node uses an algorithm that gives a score to each version of the database, and if a node receives a higher scoring version of the ledger, it adopts the higher scoring version and automatically transmits it to other nodes. Since the distributed ledger software on each node validates each addition to the distributed ledger, it’s extremely difficult to introduce a fraudulent transaction (to put it another way, transactions are audited in real time). Essentially, each node builds an identical version of the distributed ledger using the information it receives from other nodes. The use of distributed models in computing goes back to the origins of the Internet itself — ARPANET, which evolved into what we know today as the Internet, used a distributed model instead of a linear model to manage the transfer of data packets between computer networks.

The software on each node uses cryptographic signatures to verify that it is authorized to view entries in, and make changes to, the distributed ledger. If a participant with rights to modify the ledger (e.g., a digital token giving the participant the right to record a transaction) makes an addition to the ledger using the participant’s secure keys (e.g., a record of a change in ownership of an asset or recording of a new asset), the addition to the ledger is validated by the consensus algorithm and propagated to all mirrored copies of the ledger, which helps to ensure that the distributed ledger is auditable and verifiable. A key difference between centralized and distributed ledgers is that a distributed ledger cannot be forked — if you make a copy of a centralized ledger and store it somewhere else, it will be out of sync with the original copy, whereas each copy of a distributed ledger is kept identical by the client software.

Thus, the five typical characteristics of a distributed ledger are:

  1. distributed copies among nodes via client software;
  2. cryptographic signatures, or “keys,” to allow nodes to view, or add to, the distributed ledger in an auditable and verifiable fashion;
  3. a digital token (better known as a cryptocurrency)used within many distributed ledger networks to allow participants to record ledger entries;
  4. a consensus algorithm to ensure distributed copies of the ledger match among participants without the need for a centralized administrator; and
  5. record permanency so that verified entry accepted to the ledger via the consensus algorithm becomes permanent (it can be corrected via a later addition to the ledger but never removed).

Blockchain

While most press reporting around blockchains equates blockchain with distributed ledgers, a “blockchain” is a specific type of distributed ledger. Each record of new value added to the ledger and each transaction affecting entries in the ledger (which we will collectively call a “block“) includes a timestamp and a cryptographic verification code based on a data signature or “hash” from the previous block which “chains” it to the previous block, forming a “chain of blocks,” or “blockchain,” within the nodes hosting the blockchain. Because each block is cryptographically tied to the previous block via one-way hash, the entire chain is secure – a client can verify that a block in the blockchain validates against the previous block, but it does not allow someone to trace the blockchain forward. If a block in the chain is altered, it changes the hash value and no longer matches the hash stored in later blocks, and the alteration will be rejected by the nodes on the blockchain network. In a blockchain, transactions entered into the system during a specified period of time are bundled together and added to the blockchain as a new block.

There are three primary types of blockchain networks – public, private, and permissioned.

  • Public blockchains allow anyone to participate, and therefore rely more heavily on a strong consensus algorithm to ensure the requisite level of trust between blockchain participants.
  • Private blockchainsare limited to a discrete and specified group of participants, are usually small, and may not require use of a cryptocurrency given the inherent level of trust amount private blockchain participants. Private blockchains often do not require a strong consensus algorithm.
  • Permissioned blockchainsfunction much like public blockchains, but require participants have permission to access, transact on, or create new blocks within a blockchain.

Tennessee’s recent state law on blockchain, Tn. Stat. § 47-10-201, contains a good summary definition.  It defines “blockchain technology” as “distributed ledger technology that uses a distributed, decentralized, shared and replicated ledger, which may be public or private, permissioned or permissionless, or driven by tokenized crypto currencies or tokenless.  The data on the ledger is protected with cryptography, is immutable and auditable, and provides an uncensored truth.”  Arizona’s statutory definition (which predates Tennessee’s) is almost identical, except that “crypto currencies” is replaced with “crypto economics.”

Bitcoin is an early, and famous, example of a public blockchain application. Nodes on the Bitcoin blockchain network earn new bitcoins as a reward for solving a cryptographic puzzle through computing power, or “mining.” Transactions for the purchase and sale of bitcoins are also recorded in a block in the Bitcoin blockchain – the blockchain is the public ledger of all Bitcoin transactions. In other blockchain applications, the cyrptocurrency is used as payment for blockchain transactions.

Blockchain and distributed ledger technology is not intended to fully replace existing centralized ledgers such as databases. If a number of parties using different systems need to track something electronically that changes or updates frequently, a distributed ledger may be a good solution. If those needs are not there, or if there is a continuing need to rely on paper transaction records, a centralized ledger continues to be the better choice. Companies need to ensure there is a compelling ROI and business case before implementing a blockchain development and implementation program.

Smart Contracts

An important concept in blockchain technology is the “smart contract.”  Tennessee’s blockchain law defines a smart contract as “an event-driven program, that runs on a distributed, decentralized, shared and replicated ledger and that can take custody over and instruct transfer of assets on that ledger.” Arizona’s definition is identical other than an additional reference to state.  In other words, a smart contract is a computer program encoded into a blockchain that digitally verifies, executes, and/or enforces a contract without the need for human intervention. Where a traditional contract involves risk that a party will fail to perform (e.g., a shipper delivers products but the recipient fails to make payment for the products), smart contracts are self-executing and self-verifying.  In a smart contract for the purchase of goods tracked via blockchain, the seller and buyer would program a smart contract into the blockchain.  Once the delivery record is added to the blockchain, the smart contract automatically validates the shipper’s performance, and automatically triggers payment from the buyer.  Since execution of a smart contract is part of the blockchain, it is permanent once completed. Blockchain protocols such as Ethereum have developed programming languages for smart contracts.

How Might Blockchain and Distributed Ledgers Change the World?

The impact of new technology presents at first as rapidly disruptive (positively and negatively), but often manifests organically and transparently to change the world over time.

Roy Amara, a former president of the Institute of the Future, said that people overestimate a technology’s effect in the short term and underestimate it in the long run, a statement known as “Amara’s Law.” However, I think a corollary is in order – the impact of new technology presents at first as rapidly disruptive (both positively and negatively), but often manifests organically and transparently to change the world over time at a proportional rate to the maturity of the commercially available applications, to consensus on technological standards, and to decreasing costs to implement (and increasing ROI from implementing) the technology in practical business and consumer situations. For example, RFID technology was touted early on as a “change the world” technology, and it has — but most prominently through integration of the technology organic and innovative improvements to supply chain and inventory management. Social networking is viewed by many as a “killer app” (a catalyst that accelerates the adoption of a new technology) which helped usher in the third Age of the Internet, and it has changed the world by changing how we connect with others. Both took years to become pervasive in society and industry.

Blockchain and distributed ledger networks have the potential to change the way many systems and business processes work across industries. Financial and currency transactions are a prominent emerging application of distributed ledger networks and blockchain technology. Since blockchain and distributed ledger networks are platform-agnostic, a distributed ledger could be stored in different hardware/software configurations across different nodes, reducing the need for expensive and time-consuming upgrades to support the distributed model. For example, a permissioned blockchain model could help an organization such as the US Veterans Administration better manage appointment scheduling across a large number of hospitals and clinics (in fact, a resolution was recently passed in the US House of Representatives promoting just that, “to ensure transparency and accountability.” Industry groups, such as the Blockchain in Transport Alliance (BiTA), have sprung up to help develop and promote industry-specific blockchain standards and applications.

The technology could also be used in applications such as better and more secure management of governmental records and other services; tracking tax collection and receipts; managing assets; identity verification; decentralized voting; managing and tracking inventory levels and B2B/B2C product fulfillment; tracking the “data supply chain” for the flow of data among systems; managing system access controls; protection of critical public and privacy infrastructure; tracking royalties due to artists for the use of their works; and use of smart contracts to digitally create, execute, and enforce agreements between parties via blockchain transactions. Distributed ledger networks have the advantage of being more secure as the consensus algorithm makes it considerably difficult for a cyber-attacker to successfully alter the distributed ledger. It could also allow for greater access transparency, a central tenet of many privacy principles, by allowing individuals to access records in the ledger relating to them or containing their information.

Blockchain and Distributed Ledger Legal Risks and Issues

As with any new technology, blockchain creates some interesting conflicts with existing laws and regulations and raises interesting and complex legal and compliance issues.  These include:

Data privacy issues. Distributed ledger technology such as blockchain is inherently designed to share information among every participant and node. If information in a ledger transaction or block contains private information, such as an account number or company confidential information, it will be visible to every user of every node. This is one of the reasons permissive and privacy distributed ledgers are a focus of many companies seeking to innovate in the space. Additionally, as nodes in a distributed ledger network can be geographically disparate, rules and requirements for the transfer of data between geographies may play a major role. It is also possible that at some point in the future decryption technology will evolve to the point where cryptographic signatures used in blockchain and distributed ledgers may no longer be considered safe.

EU personal data and the “Right to be Forgotten.”  In the EU, personal privacy is considered a fundamental human right under the Charter of Fundamental Rights of the European Union. The General Data Protection Regulation (GDPR) is Europe’s new comprehensive data protection framework that as of May 25, 2018 has the force of law in every EU member state.  Under Article 17 of the GDPR, EU data subjects have a “right to be forgotten” which requires companies to erase personal information about that data subject if certain conditions are met (e.g., the personal data is no longer necessary in relation to the purposes for which they were collected or otherwise processed). This right has cropped up in the United States as well, for example, in California for minors under 18 with respect to websites, social media sites, mobile apps, and other online services under Cal. Bus. & Prof. Code § 22580-81.  The “right to be forgotten” creates a direct conflict with the permanency of blockchain.  Companies should factor the “right to be forgotten” into their blockchain development planning, e.g., consider hashing technologies to pseudonymize personal data before encoding it into a blockchain, or other ways to avoid this conflict.  Developments in blockchain and distributed ledger technology may also arise to address this issue.

Jurisdictional issues.The nodes in a blockchain are often in multiple jurisdictions around the country and/or around the world.  As each is a perfect copy, this can create issues from a jurisdictional perspective.  Legal concepts such as title, contract law, regulatory requirements, etc. differ from jurisdiction to jurisdiction. Does a blockchain network need to comply with the laws of every jurisdiction in which a node is operated?  Cross-border enforcement may become an issue – will one jurisdiction seek to impose its laws on all other nodes of a blockchain network? Blockchain network operators should consider how to specify, in a binding manner, a single choice of law and venue to govern disputes arising from the blockchain network and provide specificity as to compliance requirements.  This jurisdictional issue will likely lead to races between jurisdictions to establish themselves as a “blockchain and distributed ledger friendly” jurisdiction, just as Delaware established itself as a “corporation-friendly” jurisdiction in which many corporations choose to incorporate.  Jurisdictional issues will also impact discovery of data within the digital ledger network, e.g., through subpoenas.  The rules regarding document discovery differ from state to state.  A company seeking to obtain blockchain data through judicial process may have the ability to engage in “forum shopping” to find the most convenient, and friendly, jurisdiction in which to file a document discovery request.

Record retention risks. One of the features of blockchain and distributed ledger networks is record permanency. This permanency may be incompatible with statutory requirements for data to be destroyed and deleted after a period of time, such as credit/debit card data under PCI rules and HR data under various regulatory requirements, and under privacy frameworks such as the GDPR.  It also likely conflicts with a company’s existing record retention policies.  Given these factors, companies looking to introduce blockchain technology should review their record retention policies and create a separate “permanent” category for data stored in blockchain applications.  At the same time, a blockchain is permanent so long as the blockchain itself still exists.

Service Level Agreements.  Many companies include a service level agreement (SLA) in their service agreements, which provides committed minimum service levels at which the service will perform, and often includes remedies for a breach of the SLA.  SLAs are relatively easy to offer when they are limited to a company’s own systems and infrastructure.  However, a blockchain (other than perhaps a small private blockchain) may by its very nature be distributed beyond a company’s own network.  SLAs often exclude from downtime issues outside of its control, e.g., downtime caused by a third party’s hardware or software.  Does a third-party node still fit within this? Many SLAs also address latency, i.e., the time it takes for a system to respond to an instruction. Companies will also need to think about what measure of latency (if any) should apply to transactions via blockchain and other distributed ledgers, and how to address blockchain in their SLAs.

Liability and Force Majeure issues. Companies routinely implement controls (processes and procedures) to manage their systems and operations, which controls may be audited by customers/partners or certified under standards such as SOC 2. But who is accountable for a database distributed across geographies and companies? Use of a distributed ledger system with nodes outside of a company’s systems means ceding some control to an automated process and to a decentralized group of participants in the distributed ledger/blockchain. An error in a record in a distributed ledger becomes permanent and can be corrected but never removed. Is an issue with a third-party node considered a force majeure event which excuses performance under an agreement? Is the type of network (public, private or permissioned) a factor?  Companies will need to think about how blockchain should tie into an agreement’s general force majeure provision, and how to allocate blockchain risk within a contract (through indemnities, limitation of liability, etc.).

Insurance issues.  Any new technology is quickly tested under insurance policies.  Companies will begin to tender claims under their electronic errors and omissions policies, commercial general liability policies, and possibly specialized cyber policies.  As insurance companies build up experience with blockchain claims, companies will likely see new endorsements and exclusions limiting insurance carriers’ liability under standard policies for blockchain-related losses.  This is often closely followed by the emergence of custom policy riders (for additional premium) to provide add-on insurance protection for blockchain-related losses.  Companies implementing blockchain technologies may want to discuss blockchain-related losses with their insurance carriers.

Intellectual property issues.As with any new technology, there has already been a flood of patent applications by companies “staking their claim” in the brave new frontier of blockchain and distributed ledger. While the core technology is open source, companies have created proprietary advancements in which they may assert patent or other intellectual property rights.  Dozens of companies have already obtained blockchain patents.  Technology and other financial companies have undoubtedly already filed large numbers of blockchain patents that are working their way through the Patent and Trademark Office.  As is often the case with new technologies, there will likely be a flurry of patent infringement lawsuits as new patent holders seek to enforce their exclusive rights to their inventions.  Adopters of blockchain using custom applications or non-standard implementations should be especially sensitive as to whether their application or implementation could potentially be infringing filed or issued blockchain patents.  Consulting external patent counsel knowledgeable in blockchain technology will become more and more important for these types of adopters.

Confidentiality issues. Information placed into a node of a public blockchain – even if that node is within a company’s own servers – is no different than putting code into GitHub. The result is that the information enters the public domain. Even with a private or permissioned blockchain, information encoded into the blockchain becomes visible to all participants with access rights.  A company’s use of a blockchain or distributed ledger to store confidential information, such as information subject to an NDA or the company’s own trade secrets, creates a risk of a breach of confidentiality obligations or loss of trade secret protection.  Companies should consider how to prevent confidential and other sensitive company information from being stored in blockchains in a manner that could result in a breach of confidentiality. Additionally, agreements routinely require the return or destruction of the discloser’s confidential information and other provided data and/or materials upon termination or expiration. An exception for data encoded onto a blockchain must be considered.

Discovery and Subpoenas.  Information encoded into a public blockchain may be considered in the public domain.  When litigation arises, will companies be able to push back on a discovery request encompassing data in a blockchain by stating that it is publicly available?  If a person can find the identity of other nodes in a blockchain network, we may see an increase in subpoenas directed to a node for blockchain data within the copy of the blockchain or digital ledger hosted at that node (possibly based on favorable jurisdiction as noted above). Since every node maintains their own copy of a distributed ledger, and no one node owns or controls the data, this may affect the ability of a company to keep information out of third party hands as they may not have the ability to quash a subpoena directed at an independent node.

Application of existing legal structures to blockchain, smart contracts, and distributed ledgers. As is often the case, one of the challenges for lawyers and others is determining how existing laws and regulations will likely be interpreted to fit new technologies such as blockchain and distributed ledger technology; what new laws and regulations may be coming and how permissive or restrictive they may be; and how enforcement and penalties in connection with the new technologies under both new and existing laws will play out. “Smart contracts” that rely on computer algorithms to establish the formation and performance of contracts may challenge the nature and application of traditional legal principles of contract law such as contract formation and termination, and the traditional focus of laws on the acts of persons (not automated technologies), making it difficult for courts to stretch traditional contract law principles to the new technology.

Emerging laws.  It is axiomatic that law lags technology. The companies that immediately benefit from a new disruptive business method such as blockchain are those which seek to innovate applications of the method to monetize it, obtain a first mover advantage, and ideally seize significant market share for as long as possible. Industry groups and trade associations form to seek to promote it, and legislators take notice (especially given the meteoric rise of bitcoin prices during 2017). Legislators often jump to regulate something they don’t fully understand and whose potential is not fully realized, which can impede development and proliferation of the new technology.  A handful of states (including Arizona, Nevada, Tennessee, Delaware, Illinois, Vermont, and Wyoming) have already adopted blockchain-specific legislation, and this number will likely grow substantially in the next couple of years. Fortunately, the legislation enacted to date appears to support, rather than inhibit, blockchain technology. Other states have introduced or enacted legislation to study blockchain technology.

Disruptive technologies such as blockchain and distributed ledger technology bring both benefits and potential risks. If the benefits outweigh the risks on the whole, the public interest is not served when the legal, regulatory and privacy pendulum swings too far in response. The spread of blockchain and other distributed ledger technologies and applications will be dependent on the creation and fostering of a legal, regulatory, and privacy landscape that fosters innovation in the space.

Eric Lambert is the Commercial Counsel for the Transportation and Logistics division of Trimble Inc., an integrated technology and software provider focused on transforming how work is done across multiple professions throughout the world’s largest industries. He is counsel for the Trimble Transportation Mobility (including PeopleNet, Innovative Software Engineering, and Trimble Oil and Gas Services) and Trimble Transportation Enterprise (including TMW and 10-4 Systems) business units, leading providers of software and SaaS fleet mobility, communications, and data management solutions for transportation and logistics companies. He is a corporate generalist and proactive problem-solver who specializes in transactional agreements, technology/software/cloud, privacy, marketing and practical risk management. Eric is also a life-long techie, Internet junkie and avid reader of science fiction, and dabbles in a little voice-over work. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

5 Proactive Steps For Employers and Businesses in a Post-Equifax World

Posted on by

Companies should proactively prepare for changes in consumer behavior and corporate responsibility.

By now, most people have heard about the massive data breach at Equifax, one of the four US credit bureaus along with Experian, TransUnion and Innovis, affecting 143 million people. Credit bureaus (also known as consumer reporting agencies) compile and keep a file containing a person’s credit history, including things like the types of credit, how long credit accounts have been open, how much available credit is utilized/available, whether bills are paid on time, late payments/collection notices/foreclosure notices, and public records such as liens and bankruptcies, as well as personal information such as Social Security Number (SSN), date of birth (DOB), and current and previous addresses. Credit bureaus make a report of a person’s credit history (their “credit report”) available to that person, and to employers and other businesses.

Employers and businesses often want to base decisions on whether to offer a person their products or services such as a loan/mortgage/credit offer, the interest rate to charge on that offer, a cell phone plan, an insurance policy, etc., or extend that person an offer of employment or a lease, on as much available relevant information as possible.  This often includes a review of that person’s credit history. Credit reporting agencies monetize accumulated credit history and associated personal information by making credit reports available to employers, insurers, service providers and other businesses for a fee, as permitted by applicable law. If an employer or business wants to obtain your credit report, they obtain your permission to access your report as required by law and ask you to provide certain sensitive personal information about you which they will use to request your report, and they pay a fee to one or more of the credit bureaus to receive a copy of your credit report.

Many employers and businesses rely on easy access to credit reports.  However, this may be one of the more likely casualties of the Equifax breach. As noted earlier, 143 million Americans may now be at risk for identity theft using their sensitive personal information from this one breach event alone. Unlike a credit card number, which can be changed in the event the data is compromised, SSNs and DOBs (which were compromised in the Equifax breach) can’t be changed. This is why the Equifax breach is so significant – unlike most previous breaches, the scale of this breach and the nature of information compromised mean that consumers will be at risk for, and must remain vigilant for, identity theft for the rest of their lives, which will likely drive changes in the way people monitor and manage their credit reports and sensitive personal information.

Most of the advice and guidance regarding the Equifax breach to date has been consumer-focused – what consumers can and should do to protect themselves in the post-Equifax world. This includes recommendations for more robust use of credit freezes currently offered by the credit bureaus and use of third party monitoring services which alert consumers to (or require the consumer’s approval for) changes in their credit report, representing a shift in the spectrum towards consumer identity protection and away from access to easy credit such as point-of-sale, “save 20% if you open an account today”-type offers requiring an instant check of your credit. It is also likely the earthquake caused by the Equifax breach will result in additional security and legal requirements not just for credit bureaus, but for all companies possessing sensitive personal information such as SSNs and DOBs, as well as industry-driven or legislatively-mandated enhanced best practices and/or new ways for consumers to help them control access to their credit reports in an effort to minimize identity theft, such as a tool to manage security freezes at all three credit bureaus simultaneously and make it easier to impose, and temporarily lift, such freezes. The Equifax breach is also likely to increase consumer acceptance of more complex login processes, such as multi-factor authentication.

Employers and businesses should start thinking about how they can and should adapt to the coming post-Equifax changes in consumer and credit bureau behavior, and increases in corporate responsibility with respect to security and collection/use of sensitive personal information. By taking proactive steps, companies can demonstrate to their employees and customers that they are sensitive to the importance of identity protection and security. Here are 5 proactive steps companies may want to consider:

1. Address consumer credit freeze/release approval in the new employee hiring process and other processes requiring a consumer credit check (such as point-of-sale credit offers).

While implementing a credit freeze will help protect a person from identity theft, it’s not without its drawbacks. As of today, these drawbacks include the need to separately implement or lift freezes on a per-credit bureau basis, and the fact that the freeze must be lifted (temporarily or permanently) before an employer or business can perform a credit check. Despite this drawback, more people will likely implement credit freezes in the post-Equifax world, which will impact companies’ ability to easily complete background checks or receive point-of-sale credit offers.

  • Employers and other businesses performing a consumer credit check should anticipate this and consider proactively modifying their credit check process by adding a question to their credit report authorization form asking whether a person has a credit freeze, or whether that person’s approval is required for the release of their credit report. If that person answers “yes,” the employer or business should have a standard exception process to work with that person to ensure the freeze is temporarily lifted, or approval for the credit check is given, so the employer or business can perform the credit check.
  • Retailers offering point-of-sale credit offers should consider ensuring their offer disclosures include a statement that people with credit freezes may not be eligible for the offer due to the inability to verify their credit history. For those businesses which use sales associates to offer point-of-sale promotions, consider requiring them to ask whether the consumer has a credit freeze in place, and if so notify them if the freeze renders them ineligible for the offer.

Employers and businesses should also know which credit bureau(s) they use for background checks, and be prepared to provide this information to make it as easy as possible for a prospective employee or customer to implement a temporary lift of the credit freeze. It may be worth having a short URL handy which can be provided to a prospective employee or customer who wants to temporarily lift their credit freeze to enable them to take advantage of the offer on the spot or at a later time.

2. Enable multi-factor authentication for access to online services and consumer portals.

Most businesses use a username and password as access credentials. Some, but not all, have moved to a more secure authentication mechanism known as multi-factor authentication. Multi-factor authentication requires a user to provide not only a username, but two or more of the following “authentication elements” to validate the user’s identity: (1) something you know (e.g., a password, the answer to a challenge question), (2) something you have (e.g., a one-time PIN or password or a code delivered specifically through the user’s mobile device), and/or (3) something you are (e.g., facial recognition or fingerprint). Each factor must be independent of the other so that knowing one factor does not reveal another. Other data, such as geolocation information or time-based access requirements, can be used as well. The most commonly-known type of multi-factor authentication is two-factor authentication, where two authentication elements (of which one is typically a password) are required. Multi-factor authentication helps reduce the chance a bad actor could successfully exploit a username and password obtained through a security breach, through phishing, or through other social engineering attack vectors. Companies can use multi-factor authentication to demonstrate to its users (and potential users) that it places a high value on security.

Some companies argue that the burden of providing additional verification does not outweigh the simplicity of a username/password, especially where the company is not collecting any sensitive personal information. However, multi-factor authentication is an industry standard in certain areas, such as under the current Payment Control Industry Data Security Standard (PCI-DSS) for companies that are required to be PCI compliant, and will likely continue to gain traction as an industry standard, or customer expectation, in other areas. The National Institute of Standards and Technology (NIST) recommends using multi-factor authentication wherever possible. For companies where multi-factor authentication is not an industry standard or legal requirement, consider offering multi-factor authentication anyway, or offering it as an enhanced security option to customers concerned about protecting access to their accounts.

3. Evaluate whether there is a true need to collect SSNs and DOBs from consumers, and/or other creative ways to validate SSN and DOB information.

Companies which collect Social Security Numbers or dates of birth from their users should consider whether the collection of this information is truly required. One of the core tenets of data privacy is the Collection Limitation principle, which advocates for limits on companies’ collection of personal data. HIPAA takes this a step further and applies a “minimum necessary standard” – companies should limit the use and disclosure of collected personal information to the minimum necessary to accomplish the intended purpose. Companies should consider following HIPAA’s “minimum necessary standard” even if they are not subject to HIPAA. With respect to sensitive personal information such as SSN and DOB, companies should look carefully at whether they truly need to collect this information, and for what purpose. If there is another way to accomplish the same goal without collecting the information, consider implementing that alternative approach. Here are two examples:

  • With respect to SSNs, instead of asking for a user’s SSN for validation purposes considering asking for the sum of the digits in their SSN,or the sum of the digits in their SSN plus the digits in their home street address.This provides a strong identity validation mechanism without the need to capture and store SSNs.
  • With respect to DOBs, if validating a user’s age (e.g., for COPPA purposes), consider whether the month and year is sufficient, and keep a flag indicating that the age information was verified instead of the month/year information itself.

4. Review and freshen (or implement) their incident response and incident communications plan(s).

To many, Equifax’s response has been a lesson in how not to manage communications regarding a security breach. Companies should take the opportunity to learn from Equifax’s missteps and review and freshen up their incident response and incident communication plan(s). For companies still without an incident response/incident communications plan, now is the time to ensure one is in place. A few things to consider:

  • According to press reports, the Equifax breach allegedly stemmed from the failure to timely implement a security update to the Apache Struts Web Framework. As part of incident response preparedness, work with IT to ensure that your company is actively monitoring for hardware/software security patches, and is applying them as quickly as possible following release.
  • There have been numerous reports regarding sales of Equifax stock valued at $1.8 million by three senior Equifax executives within days of Equifax’s discovery of the breach. While Equifax has stated that the executives were not aware of the breach, whether or not the executives (including the CFO and President of US Information Systems) had knowledge doesn’t really matter – the perception and optics of it are awful in the eyes of the public, the SEC, and state attorneys general. Consider ensuring that the entire senior team is notified immediately in the event of a security breach, and have your General Counsel or external breach counsel discuss with them the risks of continuing with any automated stock sale programs in light of the breach.

5. Consider offering credit monitoring as an employee benefit.

Finally, employers may want to consider adding credit monitoring as an employee benefit, by offering subsidized or free credit monitoring services to their employees through a partnership with a credit bureau or a third-party provider such as AllClear ID. While there are some questions as to the value of credit monitoring in protecting against identity theft, services that notify you and/or require your approval before a new account is opened can be very valuable in fighting identity theft. As the possibility of identity theft is becoming a fact of life in the 21st century, companies may find it beneficial to help their employees guard their identity. Among other benefits to companies, minimizing identity theft reduces the time employees need to take away from work, whether as PTO or lost productivity, to deal with the repercussions of having their identity stolen, and provides employees with increased peace of mind with respect to identity protection.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The What, Why and How of SLAs, aka Service Level Agreements (part 2)

Posted on by

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

In Part 1 of this post, I walked through uptime and issue resolution SLAs.  In this second part, I cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Other Types of Commitments in SLAs

Other common types of SLAs in technology agreements include latency SLAs and customer service SLAs.

Latency SLAs. “Latency” is the time it takes for a server to receive a server request, process it, and send a response. For example, when you load a webpage, a server request is sent to a web server to deliver the webpage, the server processes the request, and sends a response with the code to render the page in the user’s web browser. Latency can be affected by a number of factors, including the geographic location of servers, network/Internet capacity, and server optimization. For companies using a vendor to provide services as part of its client-facing systems (e.g., an address verification service), minimizing latency to ensure a high level of performance is critical. A latency SLA is a commitment to a maximum roundtrip response time for a vendor server request. Latency SLAs typically exclude the time it takes to get from the customer’s server to the boundary of the vendor’s network, and vice versa (as this is outside of the vendor’s control).

Customer Service SLAs. In some vendor relationships, ensuring the prompt provision of customer support is a critical component of the relationship. For example, if a vendor is providing support to a customer’s clients or employees, or is providing level 2 escalation support, customer support SLA commitments may be important to the customer to ensure a high level of service.  Customer support commitments often include commitments on time to first response (the time from the submission of a request to the time an agent opens the support ticket to begin working on it); time to resolution (total time needed to resolve the issue); average speed to answer (the percent of calls answered within a maximum time, e.g., 85% of calls within 30 minutes, or percent of emails answered within a maximum time, e.g., 90% of emails within 4 business hours); and/or abandonment rate(the maximum number of calls being abandoned in queue before a support agent picks up the call).

SLA Remedies

In order to ensure the service level commitments made by a vendor have teeth, the SLA should have remedies available to the customer in the event of a failure to meet one or more SLA commitments. The remedies are often the most heavily negotiated section of the SLA. There are a variety of remedies that can be applied in the event of a SLA failure.

Service Credits. One of the more common forms of remedy is a service credit, often a percentage of fees paid by the customer for the period in which the SLA failure occurred.  For example, if a vendor fails to meet a 99.9% monthly SLA, a service credit equal to a percentage of the monthly fees paid by the customer would be applied to the next monthly invoice.  A credit is often provided on a tiered basis, up to 100% of the fees for the relevant period based on the size of the SLA miss. Vendors may want to include language ensuring that if multiple credits are available for the same reporting period (e.g., a credit for failure to meet the uptime SLA as well as the issue resolution SLA), only the greater credit will apply.  The credit is usually applied to the next invoice, or if there will be no additional invoice, paid directly to the customer.  For a service credit related to an uptime SLA commitment, instead of a percentage of fees some vendors will offer a credit equal to the fees earned by the vendor during the period of time during which the Service was unavailable during the previous measurement period (or an average of the amount during previous measurement periods), under the theory that the credit is an accurate reflection of the actual fees that would have been earned by the vendor had the service been available in compliance with the SLA.  Customers should carefully consider what fees are used to calculate the credit – customers will want this to be as inclusive as possible.

Termination. In the event of a SLA failure, another remedy commonly offered by vendors is a right to terminate. Vendors typically put restrictions around the exercise of this right, e.g., termination is the sole and exclusive remedy available; termination is limited to the service subject to the SLA failure, not the entire service agreement; it is offered on a “use it or lose it” right which can only be exercised for a period of time following the measurement period in which the SLA failure giving rise to the termination right arose; or the right to terminate is only triggered by multiple failures, such as failure to meet its SLA commitments in three (3) consecutive months or any two (2) out of three (3) consecutive calendar quarters. Customers should carefully consider whether the limits on these rights are appropriate (e.g., ensure that “sole and exclusive remedy” applies only to a SLA failure, and would not preclude the customer enforcing its rights and remedies for any other breaches of the vendor agreement; ensure a right to terminate extends to the entire service agreement if the affected service component is a significant portion of the value of the relationship to the customer; etc.)

Other creative remedies.Vendors and customers should consider whether other creative remedies for a breach of the SLA, such as waiver of fee minimums, waiver or imposition of other contractual obligations, or provision of additional services (e.g., a certain number of free hours of professional services), may be an appropriate remedy for the customer and an appropriate motivator for the vendor to meet its SLA commitments.

Closing Thoughts – Things to Watch For

  • Remember that most vendors are trying to provide as close to 100% uptime as possible, and the best possible service they can to their clients. A SLA is intended to be a floor on performance, not a ceiling.
  • Some vendors do not include a SLA in their standard service agreement, instead letting customers ask for one. In my experience, less customers will ask for a SLA than you’d think.  It’s always a good idea to ask a vendor to ensure they include their SLA with the service agreement at the outset of the contract negotiation process.
  • If the vendor will not agree to include a SLA, ask them why.
    • In some cases, vendors will not provide a SLA with credits to all but their largest clients, relying on the fact that as a multi-tenant platform all clients receive the benefit of the SLAs provided to their largest clients. In this event, customers should consider whether to fight for a direct SLA or rely on their commitments to larger clients (which commitments may change over time).
    • If you can’t get a SLA from a vendor, customers should consider whether to push for a termination for convenience right (and refund of prepaid but unaccrued fees) in the event they are dissatisfied with the service levels they are receiving from the vendor.
    • Customers should also ask whether the service is truly a mission-critical service. If not, it may be worth considering how hard to fight for the SLA, or if the customer can offer to concede the SLA to win on another open negotiation point of greater importance.
  • Customers should watch for language in the vendor agreement that gives the vendor the right to unilaterally change terms of the agreement, instead of having changes mutually agreed upon. This unilateral right is often broad enough to allow a vendor to change the terms of the SLA as well. If so, customers may seek to limit the scope to exclude the SLA, or ensure that the agreement includes a termination right as described above.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The What, Why and How of SLAs, aka Service Level Agreements (part 1)

Posted on by

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

At a high level, a SLA does three things:

  1. Describes the types of minimum commitments the vendor will make with respect to levels of service provided by the vendor;
  2. Describes the metrics by which the service level commitments will be measured; and
  3. Describes the rights and remedies available to the customer if the vendor fails to meet their commitments.

In many cases, a SLA is presented as an exhibit or appendix to the vendor agreement (and not a separate agreement). In others, a SLA may be presented as a separate document available on a vendor’s website.  Think of the former as a customer-level SLA which is stated directly in (and quite often negotiated on a customer-by-customer basis as part of) the service agreement with that customer, and the latter as a service-level SLA which the vendor wants to apply equally to every user of its service.

In this two-part post, I’ll explain the contents of, reasons for, and important tips and tricks around technology SLAs.  Part 1 will cover uptime and issue resolution SLAs.  Part 2 will cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Common types of commitments in SLAs

The most common types of commitments found in technology SLAs are the uptime commitment and the issue resolution commitment.

Uptime SLA Commitment

An uptime commitment is generally provided in connection with online services, databases, and other systems or platforms (a “Service”). A technology vendor will commit to a minimum percentage of Service availability during specified measurement periods.  This percentage is typically made up of nines – e.g., 99% (“two nines”), 99.9% (“three nines”), 99.99% (“four nines”), 99.999% (“five nines”), etc.  Some SLAs will use “.5” instead of “.9”, for example, 99.5% or 99.95%”.   Uptime is typically calculated as follows:

(total minutes in the measurement period - minutes of Downtime in that period) / Total minutes in the measurement period

Definitions are key. The right definitions can make all the difference in the effectiveness of an uptime SLA commitment. Vendors may gravitate towards a narrower definition of “Downtime” (also called “Unavailability” in some SLAs) to ensure they are able to meet their uptime commitment, e.g., by excluding a slowdown that makes the Service hard (but not impossible) to use. Customers should look carefully at this definition to ensure it covers any situation in which they cannot receive substantially all of the value of the Service. For example, consider the difference between Unavailability/Downtime as a period of time during which the Service fails to respond or resolve, versus a period of time during which a material (or non-material) function of the service is unavailable. The SLA should define when the period of Unavailability/Downtime starts and ends, e.g., starting when the vendor first learns of the issue, and ending when the Service is substantially restored or a workaround is in place; customers should look at this carefully to ensure it can be objectively measured.

Mind the measurement period. Some vendors prefer a longer (e.g., quarterly) measurement period, as a longer measurement period reduces the chance a downtime event will cause a vendor to miss its uptime commitment. Customers generally want the period to be shorter, e.g., monthly.

Consider whether the uptime percentage makes sense in real numbers. Take the time to actually calculate how much downtime is allowed under the SLA – you may be surprised. For a month with 30 days:

  • 99% uptime = 432 minutes (7 hours, 12 minutes) of downtime that month
  • 99.5% uptime = 216 minutes (3 hours, 36 minutes) of downtime that month
  • 99.9% uptime = 43.2 minutes of downtime that month
  • 99.99% uptime = 4.32 minutes of downtime that month

One critical question customers should ask is whether a Service is mission-critical to its business.  If it’s not, a lower minimum uptime percentage may be acceptable for that service.

Some vendors may offer a lower uptime commitment outside of business hours, e.g., 99.9% from 6am to 10pm weekdays, and 99% all other times. Again, as long as this works for a customer’s business (e.g., the customer is not as concerned with downtime off-hours), this may be fine, but it can make it harder to calculate.

Ensure the Unavailability/Downtime exclusions are appropriate. Uptime SLAs generally exclude certain events from downtime even though the Service may not be available as a result of those events. These typically include unavailability due to a force majeure event or an event beyond the vendor’s reasonable control; unavailability due to the equipment, software, network or infrastructure of the customer or their end users; and scheduled maintenance.  Vendors will often seek to exclude a de minimisperiod of Unavailability/Downtime (e.g., less than 5/10/15 minutes), which is often tied to the internal monitoring tool used by the vendor to watch for Service unavailability/downtime. If a vendor wouldn’t know if a 4-minute outage between service pings even occurred, it would argue that the outage should not count towards the uptime commitment.

Customers should make sure there are appropriate limits to these exclusions (e.g., force majeure events are excluded provided the vendor has taken commercially reasonable steps to mitigate the effects of such events consistent with industry best practices; scheduled maintenance is excluded provided a reasonable amount of advance written notice is provided.  Customers should watch out for overbroad SLAs that try to exclude maintenance generally (including emergency maintenance).  Customers may also want to ensure uptime SLAs include a commitment to take reasonable industry-standard precautions to minimize the risk of downtime (e.g., use of no less than industry standard anti-virus and anti-malware software, firewalls, and backup power generation facilities; use of redundant infrastructure providers; etc.)

Don’t overlook SLA achievement reporting. One important thing customers should look for in a SLA is how the vendor reports on SLA achievement metrics, which can be critical to know when a remedy for a SLA failure may be available. Vendors may place the burden on the customer to provide notice of a suspected uptime SLA failure within a specified amount of time following the end of the measurement period, in which case the vendor will review uptime for that period and verify whether the failure occurred. However, without proactive metrics reporting, a customer may only have a suspicion of a SLA failure, not actual facts. Customers using a mission-critical system may want to consider asking for proactive reporting of SLA achievement within a certain amount of time following each calendar month.

Issue Resolution SLA Commitment

Of equal importance to an uptime commitment is ensuring that a Service issue (downtime or otherwise) will be resolved as quickly as possible.  Many technology SLAs include a service level commitment for resolution of Service issues, including the levels/classifications of issues that may occur, a commitment on acknowledging the issue, and a commitment on resolving the issue.  The intent of both parties should be to agree on a commitment gives customers assurances that the vendor is exerting reasonable and appropriate efforts to resolve Service issues.

Severity Levels. Issue resolution SLAs typically include from 3-5 “severity levels” of issues.  Consider the following issues:

Impact Example Classification
Critical The Service is Unavailable
High An issue causing one or more critical functions to be Unavailable or disrupting the Service, or an issue which is materially impacting performance or availability
Medium An issue causing some impact to the Service, but not materially impacting performance or availability
Low An issue causing minimal impact to the Service
Enhancement The Service is not designed to perform a desired function

Issue resolution SLAs typically use some combination of these to group issues into “severity levels.”  Some group critical and high impact issues into Severity Level 1; some do not include a severity level for enhancements, instead allowing them to be covered by a separate change order procedure (including it in the SLA may be the vendor’s way of referencing a change order procedure for enhancements). Vendors may include language giving them the right to reclassify an issue into a lower severity level with less stringent timeframes. Customers should consider ensuring whether they should have the ability to object to (and block) a reclassification if they disagree that the issue should be reclassified.

Acknowledgment Commitment. Issue resolution SLAs typically include a commitment to acknowledge the issue. As with the uptime SLA, the definition of the acknowledgment timeframe is important (when it starts and when it ends). A vendor will typically define this as the period from the time it is first notified of or becomes aware of the issue to the time the initial communication acknowledging the issue is provided to the customer.  Customers should look at the method of communication (e.g., a post to the vendor’s support page, tweet through their support Twitter account, an email, a phone call from the customer’s account representative required, etc.) and determine if a mass communication method versus a personal communication method is important.

For critical and high impact issues, vendors (especially those operating multi-tenant environments) will often not offer a specific acknowledgment commitment, instead offering something like “as soon as possible depending on the circumstances.”  The argument for this is that for a critical or high impact issue, a vendor wants all available internal resources triaging and working the problem, not reaching out to customers to tell them there is a problem. In many cases, this may be sufficient for a customer provided there is some general acknowledgment provided to a support page, support Twitter account, etc. to alert customers that there is an issue. In others, a customer may want to push for their account representative, or a vendor representative not involved in triaging the problem such as an account executive, to acknowledge the issue within a fixed amount of time, putting the burden on the vendor to ensure it has appropriate internal communication processes in place.

Resolution Commitment. Issue resolution SLAs also typically include a time commitment to resolve the issue. One important thing to focus on here is what “resolve” means.  Vendors may define it as the implementation of a permanent fix or a workaround that temporarily resolves the problem pending the permanent fix; in some cases, vendors may also define it as the commencement of a project to implement a fix.  Customers should ensure that a vendor promptly implement a permanent fix if a workaround is put in place, and that failure to do so is a failure under the SLA. Many vendors are reluctant to provide a firm issue resolution timeframe, as the time required to resolve or implement a workaround is dependent on the issue itself, and are often unwilling to negotiate the resolution commitment or commit to a fixed timeframe for resolution.  Customers should ensure the resolution commitment is reasonable and that the vendor is doing everything it can to correct issues.  For example, for critical and high impact issues, consider an issue resolution commitment of “as soon as possible using continuous diligent efforts” – as long as the vendor is working diligently and continuously to fix the issue, they’re in compliance with the SLA. For lower impact issues, consider a commitment to implement a fix or workaround in the ordinary course of business.

In part 2, I’ll cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

Key Security Provisions for Vendor/Partner Contracts

Posted on by

One of the most important lessons from the 2013 Target breach was that hackers will look for the weakest link in a company’s security chain when seeking a point of entry. Often, that weakest link is the vendors and partners which integrate with your IT infrastructure or have login credentials to your systems. Target’s HVAC vendor suffered a phishing attack that resulted in hackers obtaining access credentials to Target’s network which they used as their point of entry. Companies are increasingly doing security diligence on their vendors and partners to ensure that if they have access to the company’s network or systems, they will meet minimum security requirements.  It’s critical that your vendors and partners agree to minimum contractual security commitments as well. I often use a “security addendum” with controlling language to ensure that my standard provisions control over any conflicting provisions in the vendor/partner agreement, but will sometimes embed them directly into the contract.

Here are some of the provisions I like to include in vendor and partner agreements:

  • Definitions of Personal Information and Financial Account Information.  It’s important to define what “personal information” and “financial account information” mean.  In many cases, your vendor/partner’s definition of these terms may differ from yours. Ensuring you’re on the same page (e.g., you may consider IP addresses to be personal information, they do not) can be critical in the event there is an unauthorized release of information.  Be careful using a list of information types as the list may change over time; instead, consider a broad definition with examples.
  • Credentials. If you are providing credentials to your vendor/partner to access your network or systems, or that of a third party (e.g., a marketing service, a cloud hosting environment, etc.), ensure they will only use them as required by the contract.  Ensure they fall under the contractual definition of Confidential Information and will be treated as such.  Access to credentials should be limited to those with a “need to know.”
  • Safeguards. I like to include a requirement to implement and follow administrative, physical and technical safeguards (no less rigorous than industry standard) designed to protect information and credentials.  This can be a good catch-all that can be leveraged if the vendor/partner has a problem later on and did not use industry standard security safeguards.  I also like to call out the importance of installing security software patches immediately to reduce the risk of an exploitable security hole.  If the vendor/partner has obtained security certifications (e.g., SSAE16, ISO 27001, etc.) that you are relying on, ensure they provide evidence of current certification upon request and do not let certifications lapse during the term of the Agreement.
  • Anti-Phishing Training.  Over 90% of hacking attacks start with a “phishing” attack. Consider specifically requiring your vendors/partners to provide anti-phishing training to all employees.
  • Payment Account Information.  If the vendor/partner will not be handling payment account information, add an affirmative obligation that the vendor/partner will not access, use, store, or process payment account information. If you are afraid that information might be inadvertently provided to the vendor/partner, consider adding a provision stating that if any payment account information is inadvertently provided to the vendor/partner, as long as they destroy it immediately and notify your company the vendor/partner will not be in breach of the affirmative obligation not to use payment account information.  If your vendor/partner will handle payment account information, ensure you have appropriate language that covers both current and future PCI-DSS (Payment Card Industry Data Security Standard) versions.  If appropriate, add language making clear that payment account information will be stored in active memory only, and not stored or retained on the vendor/partner’s servers (e.g., where the payment information is “tokenized” and/or securely transmitted to your company’s own servers at the time the transaction is processed).
  • Information Security Questionnaire.  Include the right to have the vendor/partner complete a written security questionnaire once a year signed by a corporate officer. Requiring an annual questionnaire can help identify whether your vendors/partners are on top of emerging threats and risks. If you have limited resources to conduct audits, the responses to the questionnaires can help you identify which vendors/partners may be best to audit.  As part of the questionnaire, ask for copies of the vendor/partner’s disaster recovery plan and business continuity plan, and certificate of insurance for the vendor/partner’s cyber security policy if your company is named as an additional insured.
  • Audit Rights.  Include a right to do a security audit of a vendor/partner’s information technology and information security controls. This should include the right to conduct penetration testing of the vendor/partner’s network, ideally on an unannounced basis.  Make sure the vendor/partner is obligated to correct any security discrepancies found at their expense; if they don’t make corrections to your reasonable satisfaction, you should be able to exit the contract.  Ensure you can use internal and third party resources to conduct the training. In addition to a right to audit on a regular basis (e.g., once per year), allow the right to audit after a security breach so you can do your own analysis of how well the vendor/partner has bulletproofed their systems in light of a breach.
  • Security Breach.  Define what a “security breach” is (consider a broad definition that includes security incidents as well).  Ensure the vendor/partner promptly notifies your company in the event of a security breach, ideally by email to a “role” mailbox or to your CIO/CTO.  The vendor/partner should take any triage steps necessary to close the immediate security hole and then thoroughly review and bulletproof its systems and networks.  The vendor/partner should agree to work with your company and any government entities in any investigation of the breach.  Ensure that your company, not the vendor/partner, decides whether and how to communicate with affected individuals.  Ensure the vendor/partner bears the costs associated with a security breach.
  • Preservation Notices and E-Discovery.  If the records of the vendor/partner may be important if litigation is brought against your company, consider adding a clause ensuring that the vendor/partner will comply with any document preservation/litigation hold notice you provide, and that the vendor/partner will reasonably assist with electronic discovery requests.  A “friendly” clause like this can help avoid issues and strain on the partnership if litigation occurs.

Once you have these provisions in your agreement, don’t forget to tie them into your risk allocation provisions. If the vendor/partner carries insurance to protect against security breaches, ensure you are an additional insured and ask for a certificate of insurance annually. Ensure your indemnification section fully covers any breach of security obligations, and consider excluding these from your limitation of liability to the greatest extent possible.

FTC opens their nationwide tour to promote Start with Security

Posted on by

It’s not the latest group on tour with a band name and album name that needed a lot more thought.  Earlier this year, the FTC announced that they would be releasing guidance for businesses on data security.  In June, they did just that, releasing a guide called Start with Security: A Guide for Business.  It’s subtitled “Lessons Learned From FTC Cases” for a reason — it uses the 50+ FTC enforcement actions on data security to provide ten lessons companies should learn when approaching to security to avoid others’ missteps that led to enforcement actions, and practical guidance on reducing risks.  The lessons are:

  1. Start with security.  The FTC has long advocated the concept of “privacy by design,” meaning companies should bake an understanding of and sensitivity to privacy into every part of the business, making it part of the design process for new products and processes.  The FTC is advocating a similar concept of “security by design.” Guidance:  don’t collect personal information you don’t need (the RockYou enforcement action); don’t use personal information when it’s not necessary (Accretive and foru International); don’t hold on to information longer than you have a legitimate business need for it (BJ’s Wholesale Club).
  1. Control access to data sensibly.  Keep data in your possession secure by controlling access to it – limit access to those with a need to know for a legitimate business purpose (e.g., no shared user accounts, lock up physical files). Guidance: don’t let employees access personal information unless they need to access it as part of their job (Goal Financial); don’t give administrative access to anyone other than employees tasked administrative duties (Twitter).
  1. Require secure passwords and authentication.  Use strong password authentication and sensible password hygiene (e.g., suspend password after x unsuccessful attempts; prohibit common dictionary words; require at least 8 characters; require at least one upper case character, one lower case character, 1 numerical character, and 1 special character; prohibit more than 2 repeating characters; etc.)  Guidance: require complex and unique passwords (Twitter); store passwords securely (Guidance Software, Reed Elsevier, Twitter); guard against brute force attacks (Lookout Services, Twitter, Reed Elsevier); protect against authentication bypasssuch as predictable resource location (Lookout Services).
  1. Store sensitive personal information securely (“at rest”) and protect it during transmission (“in motion”). Use strong encryption when storing and transmitting data, and ensure the personnel implementing encryption understand how you use sensitive data and can determine the right approach on a situation-by-situation basis.  Guidance: Keep sensitive information secure throughout the data life-cycle (receipt, use, storage, transmission, disposal) (Superior Mortgage Corporation); use industry-tested and accepted methods (ValueClick); make sure encryption is properly configured (Fandango, Credit Karma).
  1. Segment your network and monitor who’s trying to get in and out.  Be sure to use firewalls to segment your network to minimize what an attacker can access.  Use intrusion detection and prevention tools to monitor for malicious activity.  Guidance: segment your network (DSW); monitor activity on your network (Dave & Buster’s, Cardsystem Solutions).
  1. Secure remote access to your network. Make sure you develop and implement a remote access policy, implement strong security measures for remote access, and put appropriate limits on remote access such as by IP address and revoking remote access promptly when no longer needed.  (The compromise of a vendor’s system via phishing, leading to remote network access, is how the Target breach started.)  Guidance: ensure remote computers have appropriate security measures in place, e.g., “endpoint security” (Premier Capital Lending, Settlement One, LifeLock); put sensible access limits in place (Dave & Buster’s).
  1. Apply sound security practices when developing new products. Use “security by design” to ensure data security is considered at all times during the product development life-cycle.  Guidance: Train engineers in secure coding (MTS, HTC America, TrendNet); follow platform guidelines for security (HTC America, Fandango, Credit Karma); verify that privacy and security features work (TRENDnet, Snapchat); test for common vulnerabilities (Guess?).
  1. Make sure your service providers implement reasonable security measures. Make sure you communicate your security expectations to your service providers and vendors, and put their feet to the fire through contractual commitments and auditing/penetration testing. Guidance: put it in writing (GMR Transcription); verify compliance (Upromise).
  1. Put procedures in place to keep your security current and address vulnerabilities that may arise.  Data security is a constant game of cat-and-mouse with hackers – make sure to keep your guard up.  Apply updates to your hardware and software as they are issued, and ensure you are spotting vulnerabilities in, and promptly patching, your own software. Have a mechanism to allow security warnings and issues to be reported to IT.  Guidance: update and patch third-party software (TJX Companies); heed credible security warnings and move quickly to fix them (HTC America, Fandango).
  1. Secure paper, physical media, and devices.  Lastly, while the focus these days seems to be on cybersecurity, don’t forget about physical security of papers and physical media.  Guidance: securely store sensitive files(Gregory Navone, Lifelock); protect devices that process personal information(Dollar Tree); keep safety standards in place when data is en route (Accretive, CBR Systems); dispose of sensitive data securely (Rite Aid,CVS Caremark,Goal Financial).

As this guidance is based on what companies did wrong or didn’t do that led to FTC enforcement actions, it will be interesting to see how the FTC treats a company that suffers a data breach but demonstrates that they used reasonable efforts to comply with the FTC’s guidance.  I suspect the FTC will take a company’s compliance with this guidance into consideration when determining penalties in an enforcement action. The guidance is very high-level, so companies must rely on their IT and Legal teams to determine what steps, processes and protocols need to be implemented in alignment with the FTC’s guidance.

In addition to publishing the guide, the FTC has embarked on a conference series aimed at SMBs (small and medium-sized businesses), start-up companies, and developers to provide information on “security by design,” common security vulnerabilities, secure development strategies, and vulnerability response.  The first conference took place September 9 in San Francisco, CA; the second will take place November 5 in Austin, TX.

The FTC also announced a new website at which they’ve gathered all of their data security guidance, publications, information and tools as a “one-stop shop”.  You can find it at http://www.ftc.gov/datasecurity.