what is "secure"?
By basd on Jan 25, 2009 | In cloud computing
I've just about completed my system to create and store documents via Xinha. Now I have to think about security issues.
...
I'm not a computer security person. But, it seems to me, the best assumption is that "nothing is secure." Give time, resources and motivation any file is hackable.
Putting a file out on the internet is a bit like storing stuff in a strong-box and burying it somewhere. Sooner or later, someone will find it and break it open.
The same is true for what we commit to paper in our offices, I suppose. The same is true for the contents of our personal computers.
So, what we have is a trade-off between convenience and exposure. There are a lot of things we put on paper for which privacy makes little or no difference. Things we put in a web blog are specifically intended to be publicly visible. One might wonder, in retrospect, whether it might have been a better idea to NOT put some of one's ideas and ramblings "out there." Most people don't.
We can restrict access, but that is not the same as "secure." We can password protect the directory where the relevant php files are located. We can password protect the mysql database. We can even put the data in a storage location that is not web-accessible (but then we are losing the ability to use web browser access without additional software.)
At this point, we are at the mercy of the quality of security on the server -- and at the mercy of the server company's employees. In all likelihood, the server company has a number of employees who have sufficient access to retrieve our data.
For instance, the data in the mysql database is not encrypted. At one point, I was using a commercial server that allowed a backup download. The only problem was that it didn't work correctly. In attempting to download a mirror of my own database, I ended up with someone else's business data.
It's possible to encrypt the data in selected MySQL fields so that it is not readily viewed by someone with access to the computer on which it is stored. We can also connect via https secure connection. But, since the encryption is taking place on the server computer, it can be intercepted by someone with programming access to that computer. There will also be a footprint in ram and possibly in temporary files.
Is this risk more, or less, significant if using commercial cloud computing solutions such as offered by Google and Microsoft? These may be less at risk for certain kinds of attacks (as the result of good business security practices); but more at risk for other kinds of attacks, such as industrial espionage and governmental intrusion. Since the systems are standardized and centralized, they are more easily subjected to broad attack -- in much the way that Windows is under much greater siege by virus and trojan attacks compared with Linux.
There are "social engineering" hacking risks -- a person can simply call the server company and convince them that they are an authorized user with an access problem. This does not require any hacking skills at all, but has proven to be a significant vulnerability.
We can limit some of this by running our own server, but now we have lost some of the convenience factor. If I'm 2,000 miles from my server and it goes down -- but I'm relying on access to the data -- what do I do?
And, one point of putting my data on the web is to avoid carrying it with me. If I carry my computer or my data on a flash drive, it can be lost or otherwise compromised. This risk may be as significant or greater than the risks associated with online storage.
Most people have relatively insecure storage solutions. Vast amounts of information are exchanged in non-secure email.
What are the appropriate trade-offs? What are "good business practices?" This is going to require considerable dialog and study, especially as "cloud computing" becomes more prevalent.
Trackback address for this post
Trackback URL (right click and copy shortcut/link location)
No feedback yet
| « eternal frustrations of the bluetooth kind | Seigo, Linus and KDE 4.2 » |