two tales of security

From the “if I had a nickel every time..” category, a story from The Telegraph on the loss of sensitive information by the RAF:

The Ministry of Defence has admitted that files had been stolen, and more than 500 RAF staff have been warned of the possible consequences to them and their families after the unencrypted data – stored on three computer hard drives- went missing.

The extremely personal information had been given by servicemen for an in-depth vetting process to give them high security clearance.(emphasis added)

Now, I certainly can’t comment on the specific facts surrounding the loss of this data, but I did note, in particular that the data recorded was unencrypted. As most readers of this blog know, this is certainly not the first time an incident like this has occurred (i.e. a lost, misplaced, or inadvertently discarded data storage device that contained sensitive information). In fact, to be honest, it is somewhat mind-boggling that this still occurs. Not that things get lost. I understand that things like that may happen despite the physical security protocols that one may put into place. But not encrypting such data? Perhaps  a decade ago, something like that would be understandable. But it should not be today, particularly when there has been story after story about this sort of thing. In this case, not only has the RAF compromised the personal information of certain of its officers, it has also put the UK’s national security at risk. Completely inexcusable. And if I sound harsh, it’s because I intend to.

So, once again for anyone who cares to read this blog: If you are responsible for sensitive data and store it in digital format, you really, really, must ensure that you encrypt that information, particularly if it is on a storage device that may be transported, or is sitting anywhere other than a very secure vault. Otherwise, it’s only a matter of time that someone will come after you for negligence. Or worse.

On the other hand, there is a brief story in Wired about an interesting video on YouTube. It’s basically a faked video showing some “hackers” tapping into a building’s SCADA system. Interestingly, this appeared to set off alarm bells in some circles:

“Perhaps the first demo was just for fun, but the others will have less juvenile goals,” McAfee Avert Labs researcher Francois Paget blogged on Friday. “An attack can involve nationwide damage, a terrible effect on the public’s morale, and huge financial losses.”

To be fair, McAfee’s Paget acknowledged some doubts “about the technical aspects of these light-show ‘attacks’ on unprepared buildings.” But with the enthusiastic faith of cybarmageddonists everywhere, he boldly asserts that it doesn’t matter if the video is genuine.

“Fake or not, the video confirms that hackers and cybercriminals have got their eyes on SCADA networks.”

So, a question for anyone reading this – even if the video were real (and it’s not), why (other than what the article already notes) do you think Mr. Paget’s comments might be a bit off the mark, at least when it comes to the contents of the video itself?

asp issues

Will keep this short – I was reading an article (whose authors will go unnamed) describing some recent trends in software licensing and issues arising from those trends. One trend that was highlighted was the change from licensing of software to be installed and operated by a licensee (with maintenance and support from the licensor) to a vendor-hosted model (or “application service provider” or “ASP” for short), where the vendor instead sets up the software on its own machine and the vendor’s customers then make use of the software remotely – often through a browser, but sometimes through other “thin” clients.

What was the primary issue they identified? To make sure you get acceptance testing. Hmmm. Well, hate to disagree but I would think there might be a few others that might be at least (if not more) important. So, without further ado, some thoughts on what to keep an eye out for if you are thinking of signing up to an ASP service, in no particular order:

Your Data – Will your ASP be storing your data? Will it be your primary repository of your data? Is your data important? Does your data contain sensitive, confidential or personal information? If so, then you should make sure that your ASP is handling your data appropriately, including giving adequate assurances that it is only used for providing the service (and not anything else) and that appropriate security measures are taken to protect it, such as encrypted communications when sending/receiving as well as encrypted storage. We’ve all read the recent horror stories about certain large corporations who have misplaced, lost, or inadvertently disclosed sensitive data, such as credit card numbers. Make sure it isn’t your company making the headlines.

Service Levels and/or Easy Outs – Addresses the same issue as acceptance testing but in a different way. Typically one big advantage of ASPs is that there is no big upfront licensing fee and therefore no big upfront capital to invest, or risk regarding that capital investment in the event the software doesn’t do what it was expected to do. Thus, the concept of acceptance testing was invented to address this big upfront risk, with the thinking that you get to kick the tires extensively before you hand over the the truckload of cash. And if the testing doesn’t pan out, you don’t pay. OTOH, ASPs usually involve a periodic (typically monthly) payment which is much smaller. In effect, the monthly service fee can be thought of as a replacement for: (1) the amortized cost of the initial license fee; (2) maintenance and support; (3) investment in hardware and infrastructure; and (4) additional people costs on the vendor side, to keep (3) up and running. Very often this is a win-win situation, since vendors can often achieve economies of scale by running a large number of instances centrally at one dedicated data centre (and ironically to some extent harkening back to the days of mainframes + terminals – but I digress) and offer very attactive savings over what it would otherwise cost a customer to maintain the application in-house.

Anyway, the point being that there is less upfront risk with an ASP solution, provided of course, you’re: (a) not locked in to a 50 year contract; or (b) you have really good assurances that the software will be up and running as needed when you need it. Its good to have both, but at the same time it can also be thought of, to some extent, as an either-or proposition – if you can arrange for a month to month contract, then if the ASP stinks, just terminate and go elsewhere. Alternatively, if you get ironclad service levels (including significant credits and termination rights) then you might be willing to commit longer. Of course, you’ll also need to ensure that you have the ability, in the case of a month to month agreement or termination rights, to move to another service easily, and to get your data back, etc. But I’ll leave that for another time.

Anyway, not necessarily saying that acceptance testing isn’t important (and in fact if you need to spend a ton of money to have the vendor customize a solution for you it may still be very important) but just a couple of other issues to keep in mind.

cigarettes save lives

Well, not quite technology, not quite law. But in a tech publication so close enough. The Register reported on a story of a woman whose life was saved by cigarettes – or rather one cigarette:

Brenda Comer, of Rock Hill, had just finished washing the dishes at around 11am when she popped out for a gasper. At that moment, The Seattle Times dramatically recalls, “an 80-foot-tall oak tree, felled by winds gusting up to 40mph, crashed through the roof”.

Of course, that doesn’t quite make up for the hundreds of millions of other deaths caused by smoking. But at least its something positive.

multitasking

This one isn’t quite law related or quite technology rated, though it sort of touches on both. Just wanted to share something quite remarkable I saw this evening.

I was riding home in a cab with my wife and young son, going down Bay St. at about 8 pm this evening. While stopped at the lights, I casually noticed a gentleman, sitting in the car beside us, obviously very preoccupied with something, looking at his Blackberry  with some degree of concentration and furiously typing away with his thumbs It was quite easy to see given the backlight of his BB was very bright.

After a few seconds the light changed, he sped onwards, and so did we. And he continued to type, with some degree of vigour, apparently fully preoccupied with his urgent e-mail.

So, you ask, what is so remarkable about this, you ask? Surely this isn’t the first time I’ve seen someone tapping away on a BB in a cab, right? And the answer to that would be no. Definitely see it all the time. In fact, do it myself sometime. Great time saver.

So what’s the big deal? He was the one driving! Certainly understand perhaps taking a quick peek at your BB when stopped at the lights. But amazingly, this fellow that I saw simply continued to tap away busily while pressing the accelerator and speeding away. Neither of his hands were on the wheel, and it was quite clear to me that his vision was focused on his BB and not the road (though admittedly he did see the light turn green). I couldn’t tell if he perhaps was guiding the wheel with his elbows.

The stretch of Bay St. we were on is fairly straight, so I imagine someone could just take their hands off the wheel for a stretch and continue relatively unscathed. But do so, and at the same time also try to write an e-mail to someone? What sort of e-mail could possibly be so important to worth risking your life (and the lives of those around you)? Moreover, what kind of person would be so pressed for time that the could not let the e-mail wait a few minutes until they pulled over somewhere to compose it? I can’t imagine that he did a very good job at either.

While nothing much happened this time (he managed to make his left a bit later – too out of range to see what happened to his BB (but obviously with at least one hand off of it) I do wish him the best that karma may have in store for him.

robert goddard, the fraud

Don’t remember how I ran across this – I think this past week  it was Robert Goddard’s birthday or anniversary since he first invented the rocket. In any event, I ran across the article in the TIME 100 about him. I had no idea that, at the time he published his first paper on rocket technology, most of his colleagues did not believe it to be viable technology. Even worse, the New York Times, in a 1920 article, stated:

As anyone knew, the paper explained with an editorial eye roll, space travel was impossible, since without atmosphere to push against, a rocket could not move so much as an inch. Professor Goddard, it was clear, lacked “the knowledge ladled out daily in high schools.”

Needless to say, they were just a bit, shall we say, off the mark.

To me, the story serves as an interesting reminder to think carefully when you hear about someone’s “crazy” ideas. It reminds me of some of the harsh criticisms I’ve heard doled out by VCs against fledgeling companies. It reminds me of a story I heard about a very, very good lawyer turning down a couple of entrepreneurs as clients as they were kind of scruffy and had ideas that were a bit out there (only to see them sell their company for hundreds of millions just a couple of years later). It reminds me that in Canada, growth of fledgeling companies – real innovators and risk takers – just doesn’t seem to happen at the same level it does down in the US – not nearly the same. It reminds me that very few companies who start in Canada (assuming their founders don’t decide just to move to the US) stay to grow in Canada.

Don’t get me wrong – I’m not saying that there aren’t any silly, stupid and just plain crazy entrepreneurs out there who’s ideas aren’t worth a plug nickel and whose plans are doomed to failure. But even then, it makes me wonder whether here, in Canada, we have perhaps gotten too conservative, too critical and too quick to dismiss things that might, just might, work out very well. I wonder sometimes if Canada has become the New York Times circa 1920.

The Virtues and Evils of Open Source – Part II

Found the article that triggered my previous post – was a piece written by Suzanne Dingwall Williams in her blog. The nub:

If you want to sell your own proprietary software, make sure you have a strictly enforced policy against using open source. Here’s why: even if you agree that open source has crossed the chasm in the lifecycle that is technology adoption, your investors have not. Even the inclusion of an inconsequential open source tool can cause headaches, or stop a deal altogether.

Here are the concerns often raised about open source at the due diligence stage:
– there is no meaningful warranty or indemnity for this portion of the product
– how do we know the open source license is enforceable?
– do the terms for this piece of open source contaminate the rest of your product?
– if this was inadvertently incorporated into the product, what else was?

I should emphasize that I don’t necessarily disagree with the concerns she notes. They are concerns. Particularly in the specific instance she notes – i.e. selling proprietary software (as opposed to using an open source business model). That being said whether or not the benefits will outweigh the risks will depend on many things, including the business model of the startup (even if one chooses to go the route of developing proprietary software), the license governing the open source code and of course how its used. I don’t necessarily think that companies (including startups) should just have a flat policy not to use open source. But I’ve already rambled on about this in my previous post.

But then again, I’m not a VC. And Suzie apparently used to be one. It would be interesting to know what VCs generally think. Are you a VC? If so it would be great if you could go to the poll at the bottom of the left column. Nothing super scientific, admittedly, but I’d be interested in seeing what the general sentiment is.