Don't worry, they won't be.

The key to understanding this is that this sort of contractual liability is part of a contract, and with free software -- or free anything -- there's no contract. Free software wouldn't fall under a liability regime because the writer and the user have no business relationship; they are not seller and buyer. I would hope the courts would realize this without any prompting, but we could always pass a Good Samaritan-like law that would protect people who distribute free software. (The opposite would be an Attractive Nuisance-like law -- that would be bad.)

There would be an industry of companies who provide liabilities for free software. If Red Hat, for example, sold free Linux, they would have to provide some liability protection. Yes, this would mean that they would charge more for Linux; that extra would go to the insurance premiums. That same sort of insurance protection would be available to companies who use other free software packages.

The insurance industry is key to making this work. Luckily, they're good at protecting people against liabilities. There's no reason to think they won't be able to do it here.

I've written more about liabilities and the insurance industry here.

Blogger: Randall Gamby

As briefly mentioned in a Burton Group IdPS blog and a ZDNet Australia published article on July 3, 2008, HR data from Google was stolen from one of their previous HR outsource partners.  It seems that the partner, Colt Express Outsource Partners, had equipment stolen that contained HR data from some of its clients, including Google.  The data was unencrypted and stored on systems that were apparently portable.

So what does this mean for all of us? 

First, it shows that even large SaaS companies like Google can be bitten by a lack of security at their partners, just like many of us can.  Burton Group has been warning clients for a long time about the dangers of sending confidential information to outsource partners without proper security and audit processes in place. Of course this should also be backed by strong contractual language. 

Second, be prepared to pay.  Even if Google had breach mitigation terms in their contract, Colt Express announced that it was in financial difficulty. So Google has had to pay for financial reporting and other compensation to its own employees, even though Google did nothing wrong. 

Third, a Google representative stated "We take the security of our employees very seriously and require outside vendors to meet appropriate security standards. We review and update these standards on an on-going basis.”  Does this mean that Google doesn’t require encryption of its confidential information since encryption of the data was not deployed at Colt Express?  When working with third parties, whether it’s financial data or confidential personal data, this information needs to be protected from unauthorized access. One of the simplest ways is encrypting the data while at rest, regardless of where it’s located. 

Final, the Colt Express breach brings to mind a question Burton Group is always asking: “What is your exit strategy if the contract is terminated with your outsourcing partner?”  A lot of effort is expended in creating an outsourcing agreement around use and protection of data, but what happens when the contract is ended?  Do you obtain and retain the information the outsource partner maintained?  Do you have the outsource partner destroy the information and any archives of it (and verify this was done)?  Do you create a custodial contract with the outsourcing partner for them to maintain the information and archives on your behalf (ensuring the data is properly protected)?  As was found in this incident, after their contract with Google was terminated the outsourcing partner apparently retained the employee data unencrypted on their servers. This was the fatal mistake that allowed the breach to occur.

So as you work with your outsourcing and SaaS vendors, you should not only consider how day-to-day operations should be secured to maintain the confidentiality of your data. You should also think about how that data is being maintained over time, and what are your procedures should the unthinkable happen if your partner allows your data to be compromised.

1. Thoroughly evaluate the information security practices of vendors before engaging in formal business agreements.
2. Information security language should be included in contractual agreements.
3. Conduct regular audits of vendors to ensure that they continue to abide by your information security policies, standards, guidelines and procedures.
4. If your company engages vendors on a regular basis, formalize the vendor security evaluation, approval and audit process.
   

To answer that question, let’s turn the question on its head. What did security spending look like when times were pretty good?  Say from early 2005 to 2007 for example - did we see an upturn in spending? Our research found that security spending was flat or declining as a proportion of overall IT spending during that period. So then why, when the economy goes south would we spend less on security?

The vast majority of organizations spend money to counter threats and incidents that they’re seeing, and to comply with governmental and contractual requirements. Neither of these two factors are hugely dependent on economic cycles.

OK, so there’ll be less cash floating around for the big banks to fill their labs with new product evaluations, but does that really affect the majority of us? I would say not. Yes, we’re going to have to show more business justification for our technology. Yes, we’re going to have to consolidate. Yes, we’re going to have to streamline process. But weren’t we doing that anyway?

We’ve come to learn that security is a necessary cost of doing business – not a luxury item where we can turn spending on and off at the behest of economic demand. Luckily for us, I reckon there’s fewer of us that are going to be on the streets looking for jobs than other disciplines.