I have just received a requirement for data encryption of healthcare/medical data. I currently have minimal information per the users’ specific requirements, but I would like to get started in my research, and it seems that, in the ADABAS documentation, there is very little mentioned about how to make this work. A user-exit is mentioned, I assume A, B and/or 1, but I can’t find an example. I have never applied encryption to an ADABAS file, so my initial questions (there will probably be more) are:
What is the most effective way to accomplish the excryption that will ‘minimally’ affect the developers () if at all?
Where do we get this so-called ‘cipher code’? Do we make it up? What does it look like?
This request is for (rather large) existing files; I am assuming that, for the ciphering/encryption to work, the existing file(s) will have to be unloaded (ADAULD), then reloaded with the cipher code to encrypt the entire file.
Is existing Security-by-Value affected by encryption?
Encryption is part of Adabas Security. Only the Data is encrypted - the associator is not, so don’t index sensitive values. It should not affect your Security-by-Value. User exit is not required to use the built-in encryption feature.
You pick a cipher key value - 8 digits numeric. You supply it at compression, load and any other utility operation (I’m not aware of any option to apply a cipher code after the file is loaded). This value will have to be provided on every database access/update statement - see for example the FIND statement http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat823mf/sm/find.htm#CIPHER_Clause. It can be a variable (so obtain it at the start of a session and maintain it in a +global variable, for example).
If the users enter this value, be prepared to audit them periodically to make sure the value isn’t pasted to their workstations.
Most likely, I would have to implement UEX11 to avoid 1) the developers having to change scores (if not hundreds) of programs to include a cipher code, and 2) having to “publish” the cipher code to developers/users. So… Any chance anyone out there can share a working example of UEX11 (or UEX1), as opposed to the ‘skeleton’ that is supplied by SAG.
It seems there is no way to avoid unloading/reloading the file(s) with a cipher code so that all of the data will be encrypted. Correct?
Adabas SAF Security can apply cipher codes dynamically without the need to change any application programs at all. This approach allows you to apply security, encryption in this case, without impacting the application. This is absolutely flexible - and far better than having applications handling cipher codes. This means, for example, test systems can run without encryption but when the systems are deployed to production the encryption applies, for the files you wish to apply it to.
Of course, you have to get your system administrator to apply the permissions in RACF - but this is exactly where sensitive information (such as cipher codes) should be kept rathe rthan out there in the application area where auditors would be horrified if they only knew!
IMHO this enables the combination of DBA and Security administrator (one and the same person in some sites) to control security, rather than application programmers.
NOTE:
This approach measn cipher codes do not have to be transmitted from the application to the database - which can be viewed by anyone eavesdropping (live or even worse - in dumps and/or program code etc).
Michael raises an excellent point. By using Adabas SAF Security, fewer people will need to know the cipher code which makes it far less likely for this to be passed on to someone who wants to hack (either someone paying for the code or a disgruntled employee or one laid off) using a 3GL and bypassing Natural. The more centralized the security administration, the better security is overall.
It sounds also like you may want to look at the data masking product if you might get requests to copy production data to QA or development, regardless of whether you also cipher QA or development data, due to the sensitive nature of your data.