Go Green and Secure – Don’t Print

Isn’t it ironic? For hundreds of years the only practical way to make information available was to print it. And now so much of our information is in digital form from its inception, “in the cloud” as they say. Yet what do many people do when they get access to it? Yup, they turn it into paper again! Personal printers and email are everywhere. Just click “Print” to contribute to the 115 billion sheets of paper used annually by personal computers.

The obsession with creating hardcopies is an issue of waste. Do we really need to print that much paper? It’s also an issue of control and security. So much personal information available, so fast and so easy to put it on a piece of paper – oftentimes without the OK of the owner.

That’s where Fortressware comes in – giving the owner the means to maintain control over the content, allowing or disallowing the recipient’s right to print the information on paper. Most of the time, people disallow printing because there really is no necessity to do otherwise; content can be viewed electronically anyway – it’s
the right thing to do for so many reasons!

So go green and be secure with Fortressware! Try it!

Preventing Database Leaks

Even in the heart of Silicon Valley it seems no firm – however technology saavy – is immune from a serious data leak. On this occasion it was Meteora Technologies Group, a Web services provider utilized by Kleiner Perkins Caufield & Byers (KPCB). Here’s what Techcrunch reported:

Firms applying to KPCB’s investment fund for developing iPhone applications completed an online form. The form included questions that required the disclosure of intellectual property and financial information. Unfortunately, the aggregated data of close to 600 firms that had applied was dumped into a SQL file which Meteora inadvertently made available on the Web. The file’s contents were indexed quickly by Google.

This event illustrates once again the failings of a piecemeal approach to data security. Let’s focus on two.

1) Keeping data secure at 3rd party sites – One hopes that KPCB negotiated a service level agreement (SLA) with Meteora that included terms relating to security; something setting expectations for the collection, storage, and transfer of confidential information. Regardless, paper agreements are notoriously deficient in enforcement mechanisms. So if there were no teeth, Meteora was on its own to define how and when it would protect KPCB’s data.

2) Defining protection incrementally rather than comprehensively – Meteora may have had some great policies for securing data, e.g., proper authorization and authentication of everyone coming into contact with it, always encrypting laptops used offsite. But what about when data was stored to a server, a USB drive, or emailed, to name a few more potential points of failure? Each is addressable individually, but not without adding cost and complexity.

A much better approach is to always focus on the common denominator – the data, and keep it under continuous protection, no matter where it goes. And that’s where Fortressware comes into play. It’s a sufficiently “light” application to be quickly deployable across multiple sites. Had Meteora been using it, the MySQL database would have been accessible only within Fortressware’s secure virtual environment. The application would have run as usual with no modifications. But its contents, including .sql file dumps, would have been blocked from leaking all of the time – stored at Meteora, transferred to KPCB, and accessed at KPCB. With a Fortressware solution, the burden would have been lifted from the unfortunate employee who published the file. The solution would have prevented any file from being placed in an open directory on the Internet, accessible to Web users or search engines. And the same constraint would have applied to email, USB drives, CDs, or any other means for data to escape, thereby eliminating the embarrassment and damage to both companies.