CSO

You can draft the best, most protective contract in the world, but if the statement of work (SOW) fails to adequately describe the deliverables and the services to be rendered, the project can fail, cost overruns can result, and project schedules not achieved. It is amazing how much time and effort goes into drafting an appropriate agreement for an engagement, but so little time spent on the key business documents, particularly the SOW.

When businesses entrust highly sensitive information (e.g., non-public information of a consumer or valuable trade secret information) to their consultants, a best practice is to preclude the consultant from storing any of the information on its laptop computers. The risk is simply too great a compromise of the laptop will lead to the business being featured in yet another front page story involving data loss.

Sadly this is not the title of new spring break video. Rather it reflects the continuing growth industry that is lost and stolen laptops. As the number of laptops going missing grows at an ever alarming rate, many businesses have adopted policies regarding laptop security, tried to better educate their users regarding the security risks associated with this problem, and implemented stronger user authentication and even encryption on laptops containing sensitive information. Proactive businesses are now taking a further step in deploying "phone home" software in their laptops or installing applications that can be triggered remotely to irretrievably erase or encrypt data on a missing laptop. Clearly, these are all steps in the right direction. There are, however, some risks associated with implementing remote erasure software that should be addressed in your contract with the vendor.

Following up on my comments last week on the need for service level agreements (SLAs) to ensure data availability in hosted environments (e.g., ASPs, SAAS, cloud environments, and other online services). This week some further suggestions and considerations for SLA:

With all the talk these days about cloud computing, SAAS, and ASPs, we see much focus on ensuring data entrusted to these vendors is adequately secured. This usually covers the first two letters in the well-known CIA acronym (i.e., Confidentiality, Integrity, and Availability), but the service levels for these vendors - the all important availability, response time, and other performance requirements - are frequently very thin. Given the recent, highly publicized downtime at several of the most well known vendors in this space, I thought it might be useful to highlight some of the key elements to be considered in drafting effective service levels agreements (SLAs):

Most larger businesses and many smaller organizations have now implemented specific policies and procedures setting forth the steps to be followed in the event of a security breach (e.g., composition of the response team, documentation requirements, procedures to be followed in making statements to the press, decision trees for issuing notices to consumers, etc.). One area, however, that is frequently overlooked is plain English instructions for rank-and-file employees to understand what a potential security breach looks like and how to report it. In recent experiences, we have found businesses well prepared to address a breach once it becomes aware of the problem, but the problem frequently takes too long to come to the attention of the right people within the organization. This has led companies to develop brief supplementary policies or guidances to educate employees concerning these issues.

When a man tried to cross the U.S.-Canadian border recently, he placed himself at the center of one of the most important legal issues confronting consumers and lawmakers: protecting privacy in the digital age. The man was suspected of having child pornography on his laptop. While the facts are sketchy, it appears the border guards initially found certain incriminating files. But when the guards went back to review them, they found the files were encrypted and inaccessible. Prosecutors have sought to compel the man to reveal the encryption key, but the man has refused on the grounds that doing so would violate his Fifth Amendment right against self-incrimination. So far, the court involved in the case has sided with the Fifth Amendment, refusing to compel the man to reveal the encryption key. While it will likely be some time before a final decision is rendered in this case, it highlights the problem businesses face when employees use encryption in the workplace.

These days it seems we are inundated with e-mail and statistics. Like e-mail, though, I believe many of the statistics we receive are just as reliable as those offers of riches from dying uncles in Nigeria. Perhaps it's my background in mathematics, in which I learned that with the right sample one could literally prove almost anything (e.g., see the headlines of any issue of the National Enquirer), but I definitely take most surveys and the conclusions drawn from them with a grain of salt. In particular, it seems common sense is frequently wanting in the interpretation of survey results. An example will illustrate the problem.

This entry was prompted by a recent study by CareerBuilder.com which showed, among other things, 63 percent of employers who reviewed applicants' social networking profiles decided not to hire them based on what was discovered in those profiles. Reading this, it occurred to me to take a random walk through some of the social networking sites, including personal blogs, to get a feel for the type of information available. In taking that walk, I used several new search engines that focus on just these types of sites: Pipl.com, Peekyou.com, Wink.com, and Spock.com. The point of my research was to see what, if any, information was available through these sites that would be of use to, say, a social engineer. What I found greatly surprised me.