Database Encryption? Also - who should have access DB utilities?

Hello all-

I am wondering about encrypting data in a database. Basically, I am wondering if data in MS-SQL, Sybase, and Oracle should be encrypted within and if it should be encrypted there or when going across the network. Or both? When questioning our db people - they say it can be - but they take a performance hit with all the requests the systems get and having to decrypt/encrypt. So basically - they don't encrypt - anything. *Big breath*

Also - who in your opinion(s) should have access to the various DB utilities? I am thinkin the DBAs only - but our DB people also have some applications people that have access to various utilities - don't know which ones yet, as I am still investigating - and our front line help desk. That does not sound good to me - so thoughts on this as well.

I am going off to google and ask some more people here, but I just thought to stop here quick to ask the experts before I have a conniption about the encryption issues me'ah.

TIA.

Quote:

---

Originally posted here by KuiXing-2005

Also - who in your opinion(s) should have access to the various DB utilities? I am thinkin the DBAs only - but our DB people also have some applications people that have access to various utilities - don't know which ones yet, as I am still investigating - and our front line help desk. That does not sound good to me - so thoughts on this as well.

---

Usually data base utilities can run in "God Mode" to allow them to perform some action on databases. I cant see why a non-dba person should have access to them. In general, my answer is NO. But you should go in details about what kind of utility.

As for your point on encryption, the DBAs are correct, encrypting every field in the DB will cause a performance hit, relative to the size of the database and the size of the encrypted values. Normally, only sensitive fields would be encrypted or hashed; password fields, important numbers (social security/id number, credit card number, etc.)

As for weather the data should be encrypted when being sent over the network, that really has nothing whatsoever to do with databases; I know what your thinking, but really...the sniffer who is leaching sensitive data from your network couldn't give a crap if it comes from a database, a web server preprocessor, or your email applications. Data is data, and if it shouldn't be sent in the plain, then don't send it in the plain.

One of the key points I try to convey to students and coworkers is 'security is a method, a process, a state of mind.' It is irrelevant if your application is coded in the most ultrasecure language and method available...if it is on an unsecure host, or uses unsecure methods to transmit data, it's worthless. You have to evaluate your risk at all points of exposure, decide what is acceptable, and use that to guide your planning/deployment.

Does any of that make sense? (/me has had a shitty day dealing with PHB's and CL-users)

For security in the DB. It depends on what the DB is holding, I mean you wouldnt spend tons of money and recorces to protect a lunch menu or something. so it comes down to figuring out how valubale the data is. The DBAs seem to think that its not worth the recource hit, so they opt not to encrypt it.

For access to DB apps. I think it should be on a need only basis. If the person has no reason to use the DB they should be able to.

In talking with the DBS architect - they told me they do not have encryption for any of the data. We have databases that stores data about customers, sales, legal information, etc - but of course there is data we would not need to have encrypted. I have not nailed down how many db's data like that are in existence - which I am still investigating - so we will see. And I see that some are confirming what I was thinking - encrypt was is considered sensitive or confidential, and that classification should be established by IT/Corporate Security I believe.

In regards to utilities - anything that woudl allow the data or schema to be changed. I was also looking into how many people have the access to change database user passwords. That answer was scary - all of the DBAs - ok, the SAs of the physical servers - ok - maybe, the actual "owners" of the application the database is a part of - scary, the frontline support group and I am checking into a few others.

BTW - I'm not sure if this helps in terms of perspective, but I am auditing this whole DBS area -hence my questions and paranoia. I got some other mugs to check out before I go off the deep end - schee - meah!

Thanks for the information! It's helping!

Quote:

---

It is irrelevant if your application is coded in the most ultrasecure language and method available...if it is on an unsecure host, or uses unsecure methods to transmit data, it's worthless.

---

Variation on a theme:
“ a chain is only as strong as the weakest link “

So in other words, having an encrypted DB, accessing it only from locked-down win2k workstations using very secure passwords and authenticating each user, not only on the workstation but again on the DB, but using telnet via VT terminal for that access while some IT person down the hall on the same sub-net is running an unsecured bootleg IRC server is bad?

No, I've never seen that!

cough, cough ..

Quote:

---

Originally posted here by KuiXing-2005
...and that classification should be established by IT/Corporate Security I believe.

---

Don't forget to mention HR and Legal. While bringing all three groups into the same conversation will invariably increase the time it takes to make a decision by a factor of 10, they do have valid input into what is important and sensitive in their realms.

Quote:

---

Originally posted by IKnowNot
but using telnet via VT terminal for that access while some IT person down the hall on the same sub-net is running an unsecured bootleg IRC server is bad?

---

You forgot to mention the unsecured default settings wireless access point they are associated to.

;)

Actually I was using a real life scenario and wireless was not prevalent at the time, but that does kinda bring it up a notch now doesn’t it?

Quote:

---

Don't forget to mention HR and Legal. While bringing all three groups into the same conversation will invariably increase the time it takes to make a decision by a factor of 10, they do have valid input into what is important and sensitive in their realms.

---

Yep - already contacted Legal. HR would not pertain in this case, but it's important to remember that. I will also be contacting IT and Corporate Security on this and a few other issues.

I was impressed with this group I am currently auditing - as they have proactively created a general and OS specific security plans, ran them by IT Security for issues and have published those plans on the intranet. AND they are actually working to get their databases in line with those plans - I know, I'm amazed too.

Of course I broke up my own elation by firing off a few questions about their plans - like are they going to be reviewed? When - (hinting about a year after they have been published)? Who was going to be doing the review? Etc.

Now - and -warning- this is going off on a tangent here - but when asking about their DRP/BCP they started wincing and twitching. So more investigation needed there.

Thanks for all the great information!

Hello all-

Quick update - in reviewing their security plans - it actually states "...there is no need for encryption behind the firewall." Ok - here is the whole text - minus any company names:

Question: "When should encryption be used (client/server)?"
Answer: "Encryption is not needed inside the firewalls. SSL is not used between the database and application servers. The port number that is chosen to run SQL server should be blocked from the outside and is not open to the firewall."

[soapbox] :mad: So - they are basing a lot on the firewall. Now maybe I have some misguided paranoia - but what about internal threats? Meaning - I don't care if they are behind the firewall - based on the information I know that is going across the wire and air - they (we) need encryption! If nothing else - please forgive this next part - they should evaluate encryption as a possible solution with a Six Sigma project. [/soapbox]

I have to strike my comment about the watered down policy - just got the full news and found out that the policy needed to be more generalized for easier consumption - that and it included too much technical information - thereby rendering it a standard in our corporate policy maker's eyes. I found out what I was looking for in the form of an encryption standard. While I cannot share that specific information, it basically states that all information traveling over the network that has not been deemed public or for external release, must be encrypted to prevent it's exosure or misuse; if not encrypted - there has to be written deviations in place to explain why - BTW those are not fun.

So I will make a written comment and suggest the action stated above whilst I was on my soapbox - but it will be more professional and no spittle or blood on the report.

Encrypting internal databases is frequently just not practical or even feasible.

How many different individuals, groups, and departments can access the same data? Different data? Different crossovers? In your situation all data may be at a 1:1 ratio, lucky you push for encryption, this however is highly unlikely. Database encryption is most useful when used in web applications, to prevent a compromise of the database from disclosing client information in an unacceptable manner.

Although it is true that you could develop an DB interface application which contains all the keys and uses different passphrases to grant different types of access... this new application had better be developed really well or it will be a huge hole granting even more access than most flavors of DB compromise.

To answer your second question... only users that require access to specific DB utilities in order to do their job should be granted access to those utilities. Additionally users with greater privileges should receive more secure computing education.

cheers,

catch

catch - great thanks for the information!

also -

Quote:

---

To answer your second question... only users that require access to specific DB utilities in order to do their job should be granted access to those utilities. Additionally users with greater privileges should receive more secure computing education.

---

Ok - that sounds logical - have you run into any good tools to test the databases in general? So far - I have not found anything worthwhile - but then again - I am new to auditing DBs. Also - is there a tool that would work against various DB platforms (e.g., Sybase, Oracle, MS-SQL, etc.)? Or would any testing be more process driven; like what I have been thus far?

all - after reading your responses, it seems that I should not 'ding' DBS for not encrypting their data - I however may make a written observation that will include the wisdom I have gleaned here. Additionally - I need to follow up with Legal to find out about any local legislation this area needs to comply with - so far nothing.

thanks again everyone!

If your running MS-SQL, i can safely assume your running an Active Directory Environment, in that case, implement IPSEC, its cross platform and provides encryption (kerberos can be used) and authentication (well, Active Directory atleast)....

This method will stop hackers from packet sniffing the information, however, as stated before, this is only protecting against another revenue of attack, more layers maybe needed....