Some minor corrections.
It's turning out to be a slow day, so I've found time to correct a couple of minor errors on the Internet. They took a while to find. First, SQL Server Magazine encourages readers to google Massachusets 201 cmr 17, and then writes:
If I didn't know better, I'd think SQL Server Magazine was a SQL Server sales executive, because what 201 CMR 17 actually calls for is:
Here's the thing. Encrypting your database files "at rest" is not a bad idea. It's helpful for all those times you lose your server's un-purged hard drive. But the Massachusetts law defines a breach as (paraphrasing): the unauthorized acquisition or unauthorized use of data that creates a substantial risk of identity theft or fraud against a resident of the commonwealth. It also defines personal information as a name combined with a state or government-issued identifier (SSN, etc.) or a financial account number. The thing to watch out for, SQL Server Magazine, isn't storing a name unencrypted in your database; it's mishandling your customers' data. Encrypting your SQL Server instance will give you relief if that mishandling comes in the shape of a lost hard drive. It won't if it comes in the shape of a SQL injection attack, network sniffing, or a lapse in judgement by a privileged employee, as the MSDN article on the subject is wise to point out. Before I would recommend a DBMS encryption investment to my CIO, I would take a long look at other methods of preventing that scenario from happening (i.e. an onsite data destruction program) and evaluate the ROI on either approach.
The other error I spotted wasn't so much a factual error, as in the case above, but an error of attribution. Andy, IT Guy, posted a passionate response to news coverage of the decision by the City of Los Angeles to replace their Groupwise collaboration system with Google's GovCloud offer. His article is titled, "Doesn't Anyone Care About Potential Consequences?" What I've found fascinating about this particular case (and others like it) is in the insight that we're able to glean about the risk management decisions taking place behind closed doors. The City of Los Angeles memo (warning, it's loooong) gives us a rare glimpse. Did COLA care about potential consequences? What were their risk acceptance criteria? Well, to start, it tells us:
Andy speculates on the validity of the potential cost savings, and the city's memo spells it out in great detail:
The city memo also goes on to say that the current GroupWise system needed to be upgraded in order to track product end-of-life cycles (legacy systems: the gift that keeps on giving), and that the city would have had to spend $2.34M over five years to provide disaster recovery service levels comparable to Google's.
Andy had especially strong words for the proposed productivity gains:
Here's what the City of LA spelled out in its recommendation:
Andy concludes by saying "government documents are are [sic] increased risk of being breached." That, unfortunately, is not something that any of us can prove or disprove, since risk is such a squishy calculation in information security. It's true that nowhere in the COLA memos does it detail the current state of security within their IT systems and whether their security posture or capabilities exceeded Google's. We do have a couple items, however, that might clue us in to the answer of whether COLA cares about the potential consequences:
The last bullet is perhaps the most enlightening: unlimited liability is rare in this day and age, and what it says about this particular deal is that COLA was able to transfer a lot of risk to Google. Only time will tell if other municipalities or private enterprises are able to do the same with their outsourced IT providers. You and I certainly don't get that from AWS today.
I have no direct insight into what exactly happened in the board rooms of the City of Los Angeles when their CIO and CISO had a heart-to-heart discussion on whether this deal should go through. Andy, IT guy, if you're reading, I think it's a fair guess to project that several people in that room cared about potential consequences.
There. The Internet is correct now. I feel better.
Storing the name of a customer in SQL Server without the data being encrypted? No way, Jose. You’ll get a fine of $5,000 per breach or lost record. If you have a database that contains 1,000 names of Massachusetts residents and lose it without the data being encrypted that’s $5,000,000.
[...]
If I didn’t know better, I’d think the security czar of Massachusetts (or whatever the title is of the person who wrote this law) was a SQL Server sales executive because the law could sell a heck of a lot of SQL Server 2008 Enterprise Edition upgrades to get Transparent Data Encryption and other useful Enterprise Edition–only features in the OS and database stack.
If I didn't know better, I'd think SQL Server Magazine was a SQL Server sales executive, because what 201 CMR 17 actually calls for is:
Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly [... and ...] Encryption of all personal information stored on laptops or other portable devices;
Here's the thing. Encrypting your database files "at rest" is not a bad idea. It's helpful for all those times you lose your server's un-purged hard drive. But the Massachusetts law defines a breach as (paraphrasing): the unauthorized acquisition or unauthorized use of data that creates a substantial risk of identity theft or fraud against a resident of the commonwealth. It also defines personal information as a name combined with a state or government-issued identifier (SSN, etc.) or a financial account number. The thing to watch out for, SQL Server Magazine, isn't storing a name unencrypted in your database; it's mishandling your customers' data. Encrypting your SQL Server instance will give you relief if that mishandling comes in the shape of a lost hard drive. It won't if it comes in the shape of a SQL injection attack, network sniffing, or a lapse in judgement by a privileged employee, as the MSDN article on the subject is wise to point out. Before I would recommend a DBMS encryption investment to my CIO, I would take a long look at other methods of preventing that scenario from happening (i.e. an onsite data destruction program) and evaluate the ROI on either approach.
The other error I spotted wasn't so much a factual error, as in the case above, but an error of attribution. Andy, IT Guy, posted a passionate response to news coverage of the decision by the City of Los Angeles to replace their Groupwise collaboration system with Google's GovCloud offer. His article is titled, "Doesn't Anyone Care About Potential Consequences?" What I've found fascinating about this particular case (and others like it) is in the insight that we're able to glean about the risk management decisions taking place behind closed doors. The City of Los Angeles memo (warning, it's loooong) gives us a rare glimpse. Did COLA care about potential consequences? What were their risk acceptance criteria? Well, to start, it tells us:
Have the security issues raised in the prior CAO report and discussed in the Committee meeting been resolved? Since the prior Committee meeting, Google has announced a new proposal for protecting sensitive government data that is consistent with the approach preferred by the Police Department and the California Department of Justice. The Police Department is satisfied that these measures will adequately address its security concerns. Formal approval from the Department of Justice, however, can only be gained through its review of the actual functioning of the new system during the pilot period
Andy speculates on the validity of the potential cost savings, and the city's memo spells it out in great detail:
The total budgetary impact of implementing the Google system in 2009-10 would be $5,976,205. Of this amount, $1,951,260 is for additional expenditures not included in the 2009-10 Budget, including $1,754,760 for Google implementation and e-mail subscriptions, and $196,500 for infrastructure upgrades. These unbudgeted expenditures will be a General Fund obligation. ITA has identified $1,687,209 that could be used for this project, comprised of savings totaling $180,000 from its 2009-10 Budget and additional funding of $1,507,209 from a 2006 class action antitrust settlement agreement between the City and Microsoft. CSC agreee to advance the City $250,000 in future rebates to cover the majority of the remaining 2009-10 balance of $264,051. The recommendations in this report are in compliance with the City's financial policies.
The city memo also goes on to say that the current GroupWise system needed to be upgraded in order to track product end-of-life cycles (legacy systems: the gift that keeps on giving), and that the city would have had to spend $2.34M over five years to provide disaster recovery service levels comparable to Google's.
Andy had especially strong words for the proposed productivity gains:
They they say that they expect to get another $15,000,000 dollars in increased productivity. ARE YOU KIDDING ME! Do they honestly think that the ability to work on documents at the same time will provide that kind of added value.
Here's what the City of LA spelled out in its recommendation:
The initial CAO report identified potential productivity gains from the collaboration tools, and noted that the service availability of Google was likely to be superior to our current system. We also identified short-term productivity losses from transitioning to a new system and from incompatibility issues between Microsoft Office and Google's applications. It is not possible to accurately predict the magnitude of productivity changes. ITA, however, has estimated that the average productivity gain per City employee would be 10 minutes per week with the transition to Google's system. Using an average annual salary of $71,200 for City employees, ITA has valued that time at $44,509,500 over five years. While increased productivity is a benefit to the City, 10 minutes per week per employee would not lead to hard dollar budgetary savings.
Andy concludes by saying "government documents are are [sic] increased risk of being breached." That, unfortunately, is not something that any of us can prove or disprove, since risk is such a squishy calculation in information security. It's true that nowhere in the COLA memos does it detail the current state of security within their IT systems and whether their security posture or capabilities exceeded Google's. We do have a couple items, however, that might clue us in to the answer of whether COLA cares about the potential consequences:
- per section 11 of the attached SOW, COLA will be getting an annual review of Google's implementation of GovCloud
- Kevin Crawford, assistant general manager of IT, is quoted as saying "We're going to have a more secure system then we have today"
- COLA got Google to agree to unlimited damages in the event of a data breach
The last bullet is perhaps the most enlightening: unlimited liability is rare in this day and age, and what it says about this particular deal is that COLA was able to transfer a lot of risk to Google. Only time will tell if other municipalities or private enterprises are able to do the same with their outsourced IT providers. You and I certainly don't get that from AWS today.
I have no direct insight into what exactly happened in the board rooms of the City of Los Angeles when their CIO and CISO had a heart-to-heart discussion on whether this deal should go through. Andy, IT guy, if you're reading, I think it's a fair guess to project that several people in that room cared about potential consequences.
There. The Internet is correct now. I feel better.
