Re: Use of Informix with Protegrity/Omnisecure Encryption

>From: Rajesh Nair <rajeshn@us.ibm.com> >Compare column and file encryption methods to understand which is a better >fit for your specific need , not for which is better. >If you worry about root and its ability to assume a particular user - then >your bigger concern should be how to monitor your critical systems to >reduce that threat. If your worry is less of that and something else, then >you focus on that. > > I realize that you were responding to Fernando, but since you are IBM and you *did* bring this up... You are correct that creating a "one size fits all" policy as to data retention and security does not work well. The original poster is being *forced* to make Informix work with Protegrity/Omnisecure Encryption. Without having worked with that specific tool, it sounds like that what they do is replace the standard IO library found in Unix with their own "modified" version. This could be as simple as a wrapper around the standard IO library and force the application to link to their version, or they could have rewritten their version of the IO library and then have the apps link to it, or the system admin, replace the standard io package with theirs and rebuild/re-link the kernel. In either event, in order for Informix to take advantage of the encryption, it would most likely have to be limited to cooked chunks and lose the use of KAIO. (Unless of course they wanted to rewrite KAIO as well.) The downside to using this encryption package is that it will kill performance. Now that could be mitigated by either using a hardware based encryption solution in conjunction with this package (provided that they wrote their solution with this option in mind) or you ramp up and buy killer hardware to make up the difference in performance. Or both. (Which I'm sure the IBM client Rep will love the maroon in IT management who made this policy... unless its an SO body... ;-) [This is an inside joke that only an IBMer would appreciate. ] In addition, using an encryption package buys you nothing in terms of additional security. Now its been a long time, so someone correct me if I'm wrong, but while Informix is up, it locks the chunks such that no one but the Informix process(es) can access them. So what's on the disk is inexcessible during operation. Also, anyone who has root access, or the user informix access has access to the database and hence access to everything that isn't using Informix's encryption. So if you're going to steal data, you're going to want to take it from a live system, or steal a back up before you even think of taking the engine completely down and trying to do a dd of the raw chunks. (MEANING THAT THERE IS AN EASIER WAY TO BEAT THE SYSTEM...) The net net is that you killed performance for no gain. Please note that the OP is talking about AIX and HP-UX servers that are in "secure" environments. We're not talking about laptops. My suggestion to the OP was that they talk with the company that produced the security product along with the sysadmins... Now getting back to IBM. Almost 10 years ago, I made a suggestion to Diane Fraiman and a couple of then execs. I told them that they should focus on adding more security to the database like encryption in the database. The then person in charge of the I.Sell stuff (I forget the maroons name) laughed it off. Saying that the majority of store thefts came from insiders so this wouldn't be of any value. With the way IDS is designed, you *could* add encryption data types as well as support for hardware based encryption solutions. Note what I'm talking about goes beyond simple field level encryption. You'd have to encrypt the indexes and be able to encrypt/decrypt everything on the fly. Even with a hardware based solution. You'll still see a hit in performance. But the nice thing is that you'll have a very secure engine. ;-) Back in 2001 I talked with a couple of people about this. Figured it would take a small team about 6 months to work out. But I guess IBM's priorities were somewhere else. Please don't get me wrong. You can do some killer things with the Field Level Encryption provided by IDS. But its just the first step in the right direction. The only other problem is that you can't index an encrypted field. But hey! What do I know? Its not like I've thought about this for any amount of time. I'm just paranoid by nature and those are real spiders crawling up my track-mark riddled arms. ;-) -G _________________________________________________________________ Invite your Hotmail contacts to join your friends list with Windows Live Spaces http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Ian Michael Gumby wrote: > > > >> From: Rajesh Nair <rajeshn@us.ibm.com> > >> Compare column and file encryption methods to understand which is a >> better >> fit for your specific need , not for which is better. >> If you worry about root and its ability to assume a particular user - >> then >> your bigger concern should be how to monitor your critical systems to >> reduce that threat. If your worry is less of that and something else, >> then >> you focus on that. >> >> > I realize that you were responding to Fernando, but since you are IBM > and you *did* bring this up... My news server is sooooo bad... I've lost that message... > > The downside to using this encryption package is that it will kill > performance. Now that could be mitigated by either using a hardware A quick note... Currently there are a lot of things that kill performance... If you have to be SOX compliant, many times performance won't be your first priority... > Now its been a long time, so someone correct me if I'm wrong, but while > Informix is up, it locks the chunks such that no one but the Informix > process(es) can access them. So what's on the disk is inexcessible > during operation. So... you never had the chance to try mixing chunks from two instances? Or see somebody create a fs on top of your raw devices? Lucky guy :) > Also, anyone who has root access, or the user informix access has access > to the database and hence access to everything that isn't using You can activate auditing for Informix user... This brings up other issues... In fact it's very difficult if not impossible to solve the "root" problem. > Almost 10 years ago, I made a suggestion to Diane Fraiman and a couple > of then execs. I told them that they should focus on adding more > security to the database like encryption in the database. The then > person in charge of the I.Sell stuff (I forget the maroons name) laughed > it off. Saying that the majority of store thefts came from insiders so > this wouldn't be of any value. Times changed... With all the "compliance wave" that is currently dictating some major concerns and priorities they would probably react differently. It's a completely different issue, but if you check about LBAC (possibly in Cheetah or future versions) you'll know what I mean. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

>From: Fernando Nunes <spam@domus.online.pt> > >My news server is sooooo bad... I've lost that message... > > > > The downside to using this encryption package is that it will kill > > performance. Now that could be mitigated by either using a hardware > >A quick note... Currently there are a lot of things that kill >performance... >If you have to be SOX compliant, many times performance won't be your first >priority... > Well so will writing piss poor queries. The point is that you kill performance yet you do not increase security. >So... you never had the chance to try mixing chunks from two instances? Or >see somebody create a fs on top of your raw devices? >Lucky guy :) > Well, thats because when I do my work, I document everything and I try to work in tandem with the sysadmins so that they know which raw partitions are mine. ;-) Also leave a set of laminated system documents so that there is no excuse for writing on a chunk and also get the client's DBAs and SysAdmins to agree upon proper policy and procedure so that "accidents" like you mention don't happen and if they did, someone would be shot. ;-) >In fact it's very difficult if not impossible to solve the "root" problem. > Sigh. Typical IBMer. You've missed the point. Look, once someone has gained root access to any UNIX/LINUX machine there isn't a lot that anyone can do to stop him/her from screwing things up. The Original Poster said that they are implementing a solution that encrypts/decrypts the io as it is written to the disk. If you think about this, if someone were to steal the data in the database, encrypting the physical disk does nothing for security. If you have a compromised machine and that person knows the root password they can then su - to anyone and gain access to the Informix database. Bypassing the encryption entirely. Thus you degrade performance for zero gain! If you want to encrypt something within the database, you have to use the features of the database. > > Almost 10 years ago, I made a suggestion to Diane Fraiman and a couple > > of then execs. I told them that they should focus on adding more > > security to the database like encryption in the database. The then > > person in charge of the I.Sell stuff (I forget the maroons name) laughed > > it off. Saying that the majority of store thefts came from insiders so > > this wouldn't be of any value. > >Times changed... With all the "compliance wave" that is currently dictating >some major concerns and priorities they would probably react differently. >It's a completely different issue, but if you check about LBAC (possibly in >Cheetah or future versions) you'll know what I mean. > LOL... You can lead a horse to water but you can't make them drink. Part of running a business is being able to spot trends and to have products in place before your competition and to be proactive with your customers. The funny thing was that I told them that there would be problems with security and websites. They said let the application handle it. And that there wasn't a need to put encryption within the engine. Now there was a certain PhD working for Informix who was involved in the NAG datablade. Terry told a story about one of his projects which again reflected the need for encryption within the database. This was around 2001. Why IBM didn't do it remains a "mystery". Ok not a mystery. Just something we can't talk about in polite company. ;-) The bottom line is that whomever made the decision to shackle the DBAs to this Protegrity product didn't think things through. It does nothing to secure your database data. _________________________________________________________________ Search for grocery stores. Find gratitude. Turn a simple search into something more. http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_gratitude&FORM=WLMTAG