CSO

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.

Medco Health Solutions is the latest company in a growing list of businesses to suffer harm from the malicious acts of an employee. In this case, a former systems administrator inserted harmful code into Medco's systems that could have disabled a network containing patient prescription drug information. The former employee pleaded guilty in a plea bargain in which he would likely serve three years in prison. Fearing he would lose his job in anticipated layoffs, the employee apparently came up with the idea to use the malicious code to disrupt Medco's systems. Fortunately, another administrator discovered the code before it caused any significant harm. Medco, however, still incurred tens of thousands of dollars in costs to remediate the problem.

Given the season, I thought a set of New Year's information security resolutions would be in order. I'm sure you have your own items, but here is my list:

While headlines featuring data breaches are almost a weekly occurrence, the recent breach of security relating to more than 5,000 customers of ABN Amro Mortgage Group is worthy of specific note. Preliminary investigation of the breach has identified a Florida computer on which the BearShare peer-to-peer software was installed.

While this is not a "real" current threat, the experiment conducted during the International Symposium of Electronic Arts in San Jose last year raises some chilling issues. During the Symposium, a network of Bluetooth sensors were deployed throughout the city (see loca.24hourprojects.org for more information). Once established, the network tracked cell phone users who had their Bluetooth set to "discoverable." The network was able to track and record the movements of these users around the city.