CSO

Most businesses who handle highly sensitive information are now sensitized to ensure their vendor and business partner agreements have appropriate protections for confidentiality and security. In particular, given the lax privacy, security, and other laws in many jurisdictions abroad, businesses generally include contractual prohibitions on sending their most sensitive data outside the United States without their prior written authorization. This is to ensure they know where their data is at all times and, if appropriate, can conduct additional due diligence regarding the facilities and countries to which the data may be sent.

In these tough economic times, more and more businesses are turning to layoffs and using temporary workers to improve their bottom lines. The transition of workers both out of and into the workplace raises a number of security risks that should not be overlooked. One means of mitigating those risks is to create ingress and egress checklists. That is, checklists of specific steps that must be completed during the process of transitioning an employee out of the business and transitioning a temporary or new employee into the business. While most companies have these “steps” identified in various forms in various places, taking the time to bring them together into one omnibus checklist is well worth the effort. Doing so will greatly reduce the possibility of overlooking a key step.

If the latest statistics are correct, the use of pirated software remains high. This is of particular concern to businesses who likely have employees installing illegal software on their systems. The most obvious problem is the high potential for viruses and other harmful code to be propagated from pirated software to the business’ systems. Just recently, pirated copies of Microsoft’s new version of Office to be released later this year have been circulating on the Internet. There are also reports that some copies contain malicious code.

If you are in the business of securing Personal Health Information (“PHI”) for a healthcare provider, you have no doubt read in detail the Health Information Technology for Economic and Clinical Health Act (HITECH Act) within the American Recovery and Reinvestment Act of 2009 (the “Act”). As part of the Act, the Department of Health and Human Services (“HHS”) was tasked with defining the term “unsecured PHI” within 60 days of enactment of the HITECH Act. As result, on April 17, HHS recently issues the Guidance Specifying the Technologies that Render PHI Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (the “Guidance”).

The April issue of Technology Review magazine ran a fascinating story about the work of Marc Stevens, a PhD student at a school in the Netherlands. Using nothing more than a laptop and his PlayStation 3, Marc was able to force the MD5 (Message-Digest algorithm 5) digital fingerprint for an unrelated file to match that of a target file. He did this by appending junk data to the unrelated file. While this kind of “collision” is theoretically possible using almost any hash function, the possibility of intentionally forcing collision by such modest computing means is disturbing. Other flaws have been identified since MD5 was first released in 1991 by Ron Rivest, including the potential to fake SSL certificate validity. This points out the continuing (and expected) trend that as our knowledge of cryptography increases and computing power becomes less expensive, previously secure algorithms and technologies are being compromised at an ever more rapid rate.

Following on with our discussion of best contracting practices, this week we discuss the essential elements of non-disclosure agreements (NDAs). NDAs are used in several situations. Most notably, NDAs are used at the inception of a relationship to ensure confidential information disclosed in anticipation of a potential business relationship is adequately protected. If the parties decide to enter into a final contract, say a professional services agreement, following their initial discussions, the NDA would be replaced by the confidentiality provisions of the final agreement. In the foregoing example, an NDA is used as an interim agreement to ensure initial discussions are protected by written confidentiality obligations, but the NDA is not intended or designed to be used on an ongoing basis. Rather, the parties contemplate the NDA will "sunset" when they ultimately sign a final agreement to govern their relationship (e.g., a master license agreement, ASP agreement, professional services agreement, etc.).

In just the past week, two embarrassing data compromises were widely publicized. Those compromises resulted from a failure to adequately scrub old hardware (e.g., laptops, Blackberries, and USB drives) of residual data. Given the currency of this issue, I thought it appropriate to take a slight detour from my current series of postings on contract issues to present some sample contract language to address this problem.

Continuing our discussion of best contracting practices, today we discuss letters of intent (“LOIs”) and memoranda of understanding (“MOUs”). Businesses use these types of documents to summarize the terms of a proposed transaction to guide contract negotiations. The idea is to ensure both parties have alignment on the key business issues before moving forward with negotiation of a final agreement. The idea is a good one, but the execution is frequently flawed.

Let me wish you all a very happy and prosperous new year. In keeping with that theme, I thought it would be useful to start the new year with a series of postings about contracting best practices. Specifically, our focus will be on the basics of negotiating key terms in vendor agreements for technology-related goods and services. I have previously made a number of postings relating to the integration of information security into the contracting process. In these new postings, we will discuss other key contracting practices and terms.