June 12, 2012 at 11:57 pm
Comments posted to this topic are about the item We Need to Learn Encryption
June 13, 2012 at 6:21 am
"not just from hackers and criminals, but from the virtual vandals and bored teenagers that have more time than morals or sense. "
... not to mention governments with more resources than any of the above...
...
-- FORTRAN manual for Xerox Computers --
June 13, 2012 at 6:32 am
I'm one of two people at place of employment that has even the slightest knowledge of encryption, certificates and PKI. That's sad since it should be a elementry concept in IT, development and management. The barn door remains unlocked...
June 13, 2012 at 8:10 am
http://www.crockford.com/ec/dining.html
While not specifically about database, it's a good story about concurrency and security. It gives the reader a nice introduction into a capability-based access methodology. I wonder if more developers embraced this strategy how differently applications would be built from the ground up. We all agree that security must be built-in from start and not glued-on at the end, right?
June 13, 2012 at 8:22 am
SQL Server has finally got the ball started and rolling with TDE and CLE, but they still got a long way to go yet when it comes to encryption IMHO.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
June 13, 2012 at 10:04 am
Vormetric offers a very interesting and easy to manage product.
June 13, 2012 at 11:09 am
Carl Grant (6/13/2012)
Vormetric offers a very interesting and easy to manage product.
That is interesting. One more thing to look at.
June 14, 2012 at 6:11 am
From the Article
We can't change the way SQL Server, or other vendor technologies, work at a base level, but we can reduce the amount of damage that's done by not being the easy prey for attackers. In my mind, that means we should be securing our data as best we can, including encrypting communications and limiting access rights, as well as encrypting the actual data we store.
Ah... you've hit upon a topic near and dear to my heart.
One of the biggest problems I've found is just how high the priv levels are for application logins. Like it or not, applications shouldn't have more than PUBLIC privs, IMHO. This can be accomplished fairly easily through stored procedures by making it so the procedures have the privs and the users have EXECUTE privs on the procs. The user don't have privs to even read from a table. This has been made a whole lot easier using the "DB_Executor" role which has been made possible as of 2005 by being able to grant EXECUTE privs to a DB role (it seems that a lot of people have adopted the name "DB_Executor" for this role).
Ironically, the use of xp_CmdShell can be a good measure of whether or not your system is actually properly locked down or not. In a properly locked down system, individual users can't even see tables, never mind run xp_CmdShell yet the stored procedures called by the users can use it.
So far as I'm concerned, a system isn't properly secure unless the only people that have any privs other than PUBLIC are the DBAs. I'm not saying that you don't need encryption of things like SSNs because you still have to protect against possible internal threats but there's really no excuse for having the potential of external threats.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2012 at 8:50 am
Jeff Moden (6/14/2012)
One of the biggest problems I've found is just how high the priv levels are for application logins. Like it or not, applications shouldn't have more than PUBLIC privs, IMHO. This can be accomplished fairly easily through stored procedures by making it so the procedures have the privs and the users have EXECUTE privs on the procs. The user don't have privs to even read from a table. This has been made a whole lot easier using the "DB_Executor" role which has been made possible as of 2005 by being able to grant EXECUTE privs to a DB role (it seems that a lot of people have adopted the name "DB_Executor" for this role).Ironically, the use of xp_CmdShell can be a good measure of whether or not your system is actually properly locked down or not. In a properly locked down system, individual users can't even see tables, never mind run xp_CmdShell yet the stored procedures called by the users can use it.
So far as I'm concerned, a system isn't properly secure unless the only people that have any privs other than PUBLIC are the DBAs. I'm not saying that you don't need encryption of things like SSNs because you still have to protect against possible internal threats but there's really no excuse for having the potential of external threats.
Well stated Jeff.
As far as the comments that SQL server encryption has a long way to go, I would say it provides all the the basic tools you need to secure information in (and outside of) your database. What it doesn't have is a sophisticated key management mechanism, but there are third party key management systems out there.
Better yet, roll your own key management that meets your own proprietary standards.
The truth is out there.
The probability of survival is inversely proportional to the angle of arrival.
June 15, 2012 at 11:36 am
I would say it provides all the the basic tools you need to secure information in (and outside of) your database. What it doesn't have is a sophisticated key management mechanism, but there are third party key management systems out there.
Agreed, but my point was that secure database encryption is still in a transition process, and the jury is still out on whether it is the ideal solution at this point. For example this is an excerpt right from a MSDN Technical article on cryptography:
"It often seems that cryptography is employed to solve problems for which it is not really a solution. Even in circumstances appropriate to a cryptographic solution, it is not always the case that it should be deployed by means of the database engine.
When you tell your users that their data is cryptographically protected, you are implicitly assuring them that their data is protected against several kinds of threats. Cryptography is the world of the paranoid (see, for example, Bruce Schneier’s seminal book Applied Cryptography). If data really must be protected, build your systems while planning on a security audit by the most paranoid person you can imagine. It is rather easy to create an incomplete cryptographic solution. If you plan to keep your data “a little bit secure,” it is better to not represent to your users that their data is protected at all.
Just because you need to cryptographically protect your data does not necessarily mean that the database engine is the best place to do it, especially when scalability is a concern. Because cryptography is very CPU intensive, it may be wiser to limit the database to storing data and leave the cryptographic processing to upstream components—like the middle tier—as these are easier to scale." 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
June 15, 2012 at 3:29 pm
One-way encryption and comparison is pretty darned fast. Also, as a DBA, I take it as my job to ensure that the data is safe, encrypted or not. I can't do that in the so-called "middle tier" which frequently ends up being application code.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply