[PsychoCoder]

I'm not sure if this belongs here, if it's in the wrong place please feel free to move it. Right now I am working towards making the company I work for SOX Compliant. Now I know a company has to be publicly traded before they have to worry about this, but I am starting now so I don't have to scramble when that day comes.

One of the steps for compliance is security when storing user financial information; credit card numbers, billing information, etc. I am required to store this information because some of our products require reoccurring billing so I need the credit card information on file for then the cycle is ran. I am running into blanks when coming up with a way to store this information where it is secure (encrypted) yet usable when the information is needed.

Now I know I can run a one way SHA encryption on the credit card number, but that doesn't help me too much because it cant be encrypted when I go to run the card come billing day. Anyone got any ideas I can explore for solving this quandary?

[1lacca]

AES?

[PsychoCoder]

Thanks 1lacca. I never thought about using AES for this action.

[Amadeus]

Good for you on looking at i ahead of time. I spent the better part of two years making internal modifications to systems and process to ensure our company's adherence to SOx compliancy regulations. Would have been much easier to deal with that up front!

Can you insert a process between the billing run? By which I mean do you have an opportunity to have the billing engine hit another piece of software for the information as opposed to the DB itself? that way you could encrypt on storage, have the software know the key, and decrypt on the way out. Of course, not all billing engines will support this...

[PsychoCoder]

I did it this way because my former employer didn't do it that way, and we were constantly scrambling when something was found. I figure if I get my ducks in a row now, and program the system to be compliant beforehand, it will prevent me massive headaches once we have to be compliant.

I never could figure out why developers don't develop this way. Granted it takes more time initially to get the process complete, but in the long run it saves many programming hours as I wont have to worry about it when the time comes to need it.

Since I'm in charge of the entire system, planning, programming, implementing, the works, I figure it is worth my time now to make it compliant so when the time comes to need it I can not worry about it and be able to continue what I was working on in the first place. I don't like playing catchup.

[PsychoCoder]

Well I am writing the billing engine per say, so I could feasibly make it do how I wanted it to do. I know for SOX the data has to be stored in an encrypted state, thats why I was looking for a secure 2 way encryption so I could encrypt, store, retrieve, decrypt then send off to the gateway.

I have a VeriSign SSL to work with so the sending is as secure as I can make it (short of sending it encrypted but Ill have to check with my gateway to see if thats even possible). The data will be encrypted until the actual sending of it, where it will be decrypted and sent via the secure socket.

From what Ive read so far, AES really seems like a viable option so I am now working on a class to do this work for me. Ill let you know what I come up with.

This post has been edited by PsychoCoder: 25 March 2008 - 12:24 PM

[1lacca]

Why don't you simply encrypt the hard drive?
I've read Sony did just that.
Mixed into some marketing bs

[PsychoCoder]

Well I went with the AES system, I like that I can actually specify the encryption algorithm I wish to use. I spent all night, and this morning creating a class library which I can upload the DLL and keep the source in a safe secure place. I went this route so the DLL would have to be decompiled before it could be determined how I was encrypting.

I am thinking of storing the salt, vector & pass phrase somewhere, but then Id not feel safe if I didn't encrypt that as well, which would lead to needing a separate salt, vector & pass phrase, which, eventually, will lead to an endless loop of encrypting.

Got any tips on how I can keep the salt, vector & pass phrase secure (each order will of course have a different salt, vector & pass phrase).

[PsychoCoder]

*Bump* Anyone?

[skaoth]

I don't know if this will help but I know that ASP.NET has a way to encrypt entries in its web.config file.

Could this mechanism be used? This would absolve you from having to decrypt the information your storing in the config file.

The downside is I don't know if this mechanism works in non ASP.NET environments

[Jayman]

Quote

Got any tips on how I can keep the salt, vector & pass phrase secure (each order will of course have a different salt, vector & pass phrase).

Secure as in transmission or storage of phrases?

[PsychoCoder]

Im looking for a secure way of storing them. They're going to be in the database, but if I want to encrypt them then Ill need a whole new set of items (vector, pass phrase, salt) and that will lead to an endless loop of encrypting. I guess I can just trust my ability to secure a database, and as long as they're stored separately from the data they're encrypting Ill be ok?

[Jayman]

I don't see any reason why you couldn't trust the security of the database.
But ultimately it is up to you.

Do you feel that you have given the user account, that the web app uses to access the database, the minimum amount of security required to do its job?

[PsychoCoder]

Yeah I'm sure of that, I just don't want to make a mistake now that could come and bite me in the ass later. The account I created for the site is very limited in what it can do

[no2pencil]

1lacca, on 25 Mar, 2008 - 02:02 PM, said:

Why don't you simply encrypt the hard drive?

A medical facility that I used to work at did exactly that. One of the owners got sick of trashing backups (good equipment) just to be compliant, so they got rock solid encryption & do their daily backups onto USB drives now. It actually saved their ass once while I was there, because they had the ability to go back 3 months & gather some data. Once everything was properly archived the USB drives are locked into a fireproof safe & the only one to leave the facility is the yearly backup & it goes home with the owner.

It was a pretty nice setup. Also formatting the new drives (for the new year) was pretty fun too.