Operating System - OpenVMS

Re: Field encryption

 
SOLVED
Go to solution
Wim Van den Wyngaert
Honored Contributor

Re: Field encryption

1. are all your users using encrypted transport (ssh, so not telnet) ? If not, a simple tcptrace could reveal the SSN.

2. Idem for printers, db links, etc (I can get even the Sybase sa password with tcptrace !).

3. I hope you are using httpS.

4. if you split the SSN in different parts (e.g. 1 filed containing the even positions and 1 field containing the uneven positions), then it's no longer a SSN and thus doesn't need to be encrypted (thus by pass the requirement of encryption).

5. I wonder what Volker could get out of memory of a process having the decrypted data in memory.

6. Do you print directly to a (secured) printer or do you keep the file on disk (oeps, unsecured) ? Idem cobol workfiles, sort files.

IMO a loss of time (just as most sox stuff)

fwiw

Wim
Wim
Hein van den Heuvel
Honored Contributor

Re: Field encryption

Wim is right in that at some point those SSN's or CC's or whatever secret info you have turn into real recognizable info and can be intercepted. Notably main memory and on the line. VMS makes it impossible for non-privved (non CMKRNL) users to glance at any memory other than your own, and standard encryption (SSH and friends) can protect the lines a long way.

I would recognize permanent disk storage as the greatest vulnerability in the whole cycle.
The data just sits there for years or decades, and over and over.
Those files get backed up, moved off site.
The disks may be retired and improperly disposed of. Well meaning consultants (myself) may snarf a copy to analyze (performance) patterns and while not interested in the data themselves, move it out of the careful into the careless realm.
Or maybe it is 'just' an RMS convert producing a CONVWORK in a spot you failed to protect (sys$scratch is often sys$login).

VMS tries to help with file protections, High-water marking, delete/erase, init/erase and such. But once a disk, tape or whole storage subsystem is outside of the running environment pretty much anything can be done to it by anyone.

All that suggests to me that encryption of sensitive data in the files is probably a desirable thing to do. Encrypting the whole (virtual) disk is probably the more transparent, easiest, way to accomplish this for the applications.

fwiw,
Hein.
LHicks
Occasional Advisor

Re: Field encryption

I can see this is going to be a lot more complicated than originally thought(isn't it always), and it's looking like there are more questions than answers depending on what the company is trying to accomplish given the limited timeframe. Thank you to all who responded! I appreciate your time and will definitely use this forum again.
Hoff
Honored Contributor

Re: Field encryption

Some folks have trumped the whole discussion of SSN and have switched to the use of an employee number or such; to less sensitive information. Various registries of motor vehicles finally figured this one out; not having the SSN on the driver's license was better than having it.

I am extremely skeptical of any site that requests the SSN. Even those organizations authorized to request it tend to botch it. (One open WiFi or WEP WiFi or weak WPA PSK can ruin your whole day.)

It's a particularly questionable human identifier value, too, given the folks running the SSN system have made multiple fundamental flaws in its design (eg: no check digit), and the address space is rather limited, and the set of folks that possess such identifiers might not be what you want it to be.

Organization-generated identifiers (company employee numbers, etc) can be a better solution, as can digital certificates and such. Both of these can be part of other security-related protocols, too. DCs are very handy, including for use with https and with VPNs.

And the SSN is a target regardless, and I'd rather not have a target painted on my applications. Which is why I seek to avoid having SSN or other data. Or to one-way hash the data. The less data and the less recoverable the data, the less that can be exposed in a breach.

GuentherF
Trusted Contributor

Re: Field encryption

Non-US viewers can skip this...
It is my naive understanding that my SSN is only needed by a 3rd party if they have to report some of my tax activities to the IRS. If this is the case here then yes, enhance the application and use some form of encryption.

Otherwise replace the SSN with an new ID. Again a change in the application but the right one in the long term.

Now how can I get my credit card number encrypted on my card so that no one else can read it...

/Guenther
LHicks
Occasional Advisor

Re: Field encryption

Yes, the SSN is for tax purposes.
Hoff
Honored Contributor

Re: Field encryption

> Yes, the SSN is for tax purposes

Ok; I'd then head toward public key encryption (PKE) here, and use the hashed values save for when I specifically needed to retrieve and view the cleartext.

The advantage with PKE is its asymmetry; there is a key to encrypt the data and a second and separate key to decrypt the data.

For most purposes here, only the encryption (public) key is "floating" around. For SSN comparisons and for anything else that doesn't need to retrieve the SSN can use the public key to encrypt the provided SSN and can compare the results against the saved SSN.

Only when the cleartext SSN is required does the private key come out to play.

(And use one of the provided PKE crypto libraries. Don't roll your own crypto.)