Encryption Practices on DB2 z/OS

John SooHoo

Encryption Practices on DB2 z/OS

Dear Esteemed Listers,

I was approached by an application manager who wants to encrypt data on a new DB2 z/OS table. We have not done that before. As the DBA, I researched and found we need the Integrated Cryptographic Service Facility z/OS component. We were told we have that. My testing was not successful. I was then told we need some additional hardware, "crypto cards?" We will be having a meeting to discuss this requirement shortly.

More worrisome is that the same encryption functions that I am looking at on DB2 z/OS appear on UDB to be deprecated in favor of something called, "native encryption." I am not a UDB DBA and do not understand the distinction. I am concerned that I may wind up directing an application team to use encryption functions that might be deprecated in a future release of DB2 (not a way to win friends). If anyone knows what the future will be for these functions, I'd love to hear it.

Yes, I've heard of the encryption features on the latest model mainframes, but we don't have one of those.

Without a new mainframe and without, "native encryption," it seems we will have no choice but to use the existing encryption functions, assuming that we will be able to acquire the, "crypto cards." That still leaves me with a question (pardon me if it is a simplistic one).

If we went the route of using these encryption functions, it appears you have to provide the password/key along with the function call. How do we avoid hard coding and the password/key being known to everyone that looks at the code?

Thanks in advance for any assistance and guidance.

John Soohoo

Venkat Srinivasan

RE: Encryption Practices on DB2 z/OS
(in response to John SooHoo)

If you are planning to encrypt a column the current trend is to write fieldprocs. You can also write "clever" user defined functions.
If you are planning to encrypt the data traffic then you need to configure AT-TLS and secure port.
There are numerous suppliers that deliver tools to aid in data encryption for DB2 zOS. IBM's data
encryption is an example.
You will need to configure ICSF and full exploitation of ICSF requires crypto coprocessors.
From a Sysprog / DBA perspective, there is a minimal work with much of the heavy lifting to be done by MVS engineering and security administrators. For TLS, the heavy lifting is on the newtwork side.
DFSMS / zOS 2.3 provides support for "pervasive encryption" via dataset policies and DB2 has made
APARs available. There are hardware requirements documented in the pervasive encryption faq. That will satisfy encryption for data at-rest.

There are ICSF callable functions with which you can write a encryption / decryption program. ICSF is necessary to secure the key otherwise a dump of the address space will reveal the key.

Venkat

Roland Schock

RE: Encryption Practices on DB2 z/OS
(in response to John SooHoo)

Hi John,

imcan mainly speak,for the LUW side. Yes, the methods to have single encrypted columns is deprecated and works in a way, that you have to provide a password while accessing this column. The encryption/decryption is done in Db2 code and your application has to have this password stashed in the application code. Within Db2 LUW you can obfuscate the code of stored procedures and UDFs, so this could be a way to work around hiding the password somewhere else. But everyone who can call the function will also see the clear content.

Native Encryption is database-wise and will work on the datapage level. So if the Db2 engine will pull up a page from disk to the bufferpools, it will get decrypted... Or encrypted while paging out. The password is either provided by the sysadmin starting the database manager or is stored in a stashfile.

AFAIK there is a similar option on z/OS, where you need the encryption card to encrypt/decrypt datapages transferred between memory and disk. You don't want to have software encryption there, but only hardware supported encryption to make it fast.

BTW encrypting single columns is not really state of the art today anymore. ;-)

 

Cheers

Roland

Phil Smith III

Encryption Practices on DB2 z/OS
(in response to John SooHoo)
Roland Schock wrote:
>imcan mainly speak,for the LUW side. Yes, the methods to have single
>encrypted columns is deprecated and works in a way, that you have to
>provide a password while accessing this column. The
>encryption/decryption is done in Db2 code and your application has to
>have this password stashed in the application code. Within Db2 LUW you
>can obfuscate the code of stored procedures and UDFs, so this could be a
>way to work around hiding the password somewhere else. But everyone who
>can call the function will also see the clear content.

Having the password in the code makes this very weak from a security perspective. Most of our customers have rejected such approaches for that reason.

>Native Encryption is database-wise and will work on the datapage level.
>So if the Db2 engine will pull up a page from disk to the bufferpools,
>it will get decrypted... Or encrypted while paging out. The password is
>either provided by the sysadmin starting the database manager or is
>stored in a stashfile.

This is better, but still high-impact, as it means lots of encryption/decryption going on. This is suboptimal from both a performance perspective (adds overhead) and for security (lots of cleartext = lots of opportunity for attack).

>AFAIK there is a similar option on z/OS, where you need the encryption
>card to encrypt/decrypt datapages transferred between memory and disk.
>You don't want to have software encryption there, but only hardware
>supported encryption to make it fast.

Crypto Express (CEX) cards are for security, not performance. They are MUCH slower than doing the operation “on the box”. There is CPACF, which is the “crypto on the chip”, and is used by many facilities; that’s faster, but does not provide the key isolation that CEX does. Protected Key operation (Google it) is the hybrid that provides the best of both worlds.

>BTW encrypting single columns is not really state of the art today
>anymore. ;-)

I have to disagree with this. The IBM approach with keys in the application is not state-of-the-art. Whole database encryption is not state-of-the-art, for the reasons described above (overhead and attack surface). Protection at the application level, using a data-centric approach that preserves format and allows keeping the data in its protected state for most processing, is most certainly state-of-the-art.

To illustrate, consider a credit card number. Most of the time, you don’t care what that number is: you care that you have it, that it’s unique, that it’s consistent, and that it look like a credit card number. If you can protect it to a value that fits these criteria but is not the actual number, you can perform most processing on that value without ever decrypting it. You would need to decrypt it only when passing it outside for settlement, and perhaps in fraud analysis. If you need to validate a number provided, you protect the search term and look for the protected value.

This all means that most applications have zero impact from encryption: no changes, no added overhead. DB2 is unchanged: no hooks, no data expansion. The only database impact is possibly easing of partitioning requirements—if the whole credit card number is protected, then your values will no longer be clustered starting with 4 for Visa etc., but will instead be more evenly distributed (but for PCI DSS compliance, you only need to protect “middle 6”, so likely wouldn’t protect whole value, thus enabling even more processing in protected state—BIN/IIN management, for example—but it’s illustrative).

Yes, applications that ingest data or that need cleartext need updates, but that can be done via UDF if it’s too hard to add a single line of code at the point of use. And since most applications don’t need those changes, the impact is suddenly orders of magnitude less than traditional approaches.

I’d argue that the exercise of going through and figuring out what applications truly need cleartext is also important from a security perspective. Many customers find that databases are full of sensitive data that is not truly needed, and can be deleted, reducing impact and risk.

Format-preserving data protection also means that data that moves across the ASCII-EBCDIC divide can be moved in its protected state: if my SSN is 123-45-6789 and protects to 987-65-4321, then that protected value can be translated to the other encoding (ASCII/EBCDIC) and decrypted when needed. This reduces both overhead and attack surface: most encryption schemes that force cleartext are of limited value because they result in cleartext so much of the time.

As one might guess, I’m flogging our product, SecureData, here (lightly, I hope—I believe in this approach, whether it’s via SecureData or another product). Feel free to contact me off-list for information. I’m the product architect, not in sales, FWIW.

OK, this got long. Gonna stop now.
--
...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
Micro Focus (Voltage)

[login to unmask email]
T 703-476-4511
M 703-568-6662
Herndon, VA

Jørn Thyssen

RE: Encryption Practices on DB2 z/OS
(in response to John SooHoo)

Hi John,

What's is the business requirement?

You can encrypt data at several layers

  • First layer is self encrypting disk and tapes
  • The layer above self encrypting disks would be pervasive encryption, which adds some additional protection.
  • Above that you have encryption using built-in functions, user defined functions or fieldprocs (contact me if you need info about IBM's solution) which offers even more protection
  • The final layer is application encryption where you stored encrypted values in a binary column and any decryption is done by the application

The effort increases from the first (almost trivial and standard today) down to the last, which can be time consuming to implement. This generally means most customers only do what their auditor forces them to do :)

Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: www.rocketsoftware.com 

2018 IBM Champion.

Views are personal. 

Venkat Srinivasan

RE: Encryption Practices on DB2 z/OS
(in response to Roland Schock)

Roland,

I am quoting what has been stated and offer my perspective to those statements.

"BTW encrypting single columns is not really state of the art today anymore. ;-).....

Native Encryption is database-wise and will work on the datapage level. So if the Db2 engine will pull up a page from disk to the bufferpools, it will get decrypted... Or encrypted while paging out. The password is either provided by the sysadmin starting the database manager or is stored in a stashfile."

I think we may be missing the critical point.

A system managed encryption is only good to encrypt the data at rest scenario. It does not offer protection to sensitive data from unauthorized views of the data. If the user is a privileged user he can see what he is not supposed to see and an encryption scheme must be in place to address that scenario. Your statement implies the row / column level access security (separate from encryption) as deprecated items but in fact they are all there to stay to satisfy stringent mandates.

When encryption is done at the dataset (in zOS we call a file as a dataset) level using SMS policy, the DBMS started task user and anyone else who needs to operate standalone utilities on that dataset will need authorization to the key label to see the decrypted contents. Allocating a dataset does not require any authorization for the key label. This check is done at OPEN time only. However this poses a risk. Say your application relies on the above, claiming data is encrypted, by virtue of disk / dataset encryption scheme, it doesn't preclude anyone who has access to the table, see the decrypted data and col level encryption can prevent that possibility.

Both fieldproc and a customized user defined function can check who the invoker is and ask the security product if the invoker is authorized to see the decrypted data from the environment he identified to the database. What if SSN and LAST NAME is indexed for a hypothetical reason? What about a potential exposure through copies of data and log? Column level encryption using either fieldproc or function index may optionally prevent exposure in a wide variety of scenario, if implemented correctly.

Dataset encryption is only good for encrypting data at rest. Wherever the data goes, encryption must also follow. Does it meet compliance requirements if the objective is to prevent data theft?. Not 100%. 

Whole disk encryption is different and it doesn't necessarily provide dataset encryption. 

The disk / dataset encryptions occur at a fairly low level and by suitable buffering (read ahead etc), overhead is usually minimized or mitigated. Application processing / adhoc SQL workload has more overhead and this little overhead is simply absorbed in most cases. Whenever it comes to data security and compliance, there is really no point in pondering over "overhead".

“Yes, the methods to have single encrypted columns is deprecated and works in a way, that you have to provide a password while accessing this column.“

This is not true at all. Using the security product, co-processor and ICSF, the cipher key can be secured from the invoker. You almost certainly do not want crypto ops in any address space as a dump of the core might reveal the key. Program can be secured so it can only run in its intended environment. When we mention user defined function it is 100% user defined and not delivered by DB2 framework. IBM delivers certain built in functions within DB2 and sells enhanced offering as an encryption suite. There are wide differences between the two and what I consider in my mind is either a home grown encryption function or an encryption function from a vendor’s product line including that enhanced offering “IBM Data encryption for DB2 / IMS”.  Built in functions have to work in all environments hence they will be minimal in what they can deliver. There are numerous vendors that offer support in this area.

"The encryption/decryption is done in Db2 code and your application has to have this password stashed in the application code."

A function or fieldproc is an external program to which the database / application user / DBA need not be privy to the security label which makes it a highly reliable tamper proof medium.

"AFAIK there is a similar option on z/OS, where you need the encryption card to encrypt/decrypt datapages transferred between memory and disk. You don't want to have software encryption there, but only hardware supported encryption to make it fast."

Encryption as above or dataset encryption is relatively a new concept with recent enhancements (zOS 2.3, DB2 V11 / V12 etc, specific hardware models etc) and most sites are not yet (should add probably here as there may be a few sites) fully exploiting it in zOS although I must say VSAM has supported various forms of encryption for quite a long time. The integration with DB2 / SMS policy is fairly new. The machine instructions such as KM and KMC for cipher and chained cipher are rather too old in zArchitecture instruction set. We can do clear key encryption with ease. Their adoption is rather new.

We are automatically driven to think that h/w is the best choice in all cases. There have been reported cases where software based operation was cheaper than hardware operation. Fairly recently, DB2 performed de-compression in software as it was found to be cheaper than its on chip h/w implement. In certain other h/w platforms tcpip checksum was performed in software as it was cheaper than hardware. So just because something is done in hardware it may not always mean it is superior. There are opportunities there too. Not all hardware issues can be patched. Software can be patched. Compiler optimizations versus the perceived cpu stall during the co-processor engagement varies depending on the involved hardware. Similarly just because there is a machine instruction for cipher block chaining implement, that cannot be deemed faster as the ultra-complex instructions themselves can be implemented using millicode, a specialty subroutine technique to which only the cpu has access. These instructions may not be available in all countries due to regulatory requirements and usually a fallback is necessary when a product adopts it. The OS / DBMS / TOOL vendor knows what is best because only he has access to his proprietary implement and often they make the appropriate choice when it comes to hardware and software even when accelerating hardware is present.

Obfuscation of data is not encryption for if it were to be true compression in itself sufficiently obfuscates the data as decompression is not for “faint hearted”. Such a “not for faint hearted” logic will not convince even an entry level information auditor.    

I will stand corrected if my thought is no longer valid. I like a pervasive encryption which utilizes a dataset level encryption, a data traffic encryption using TLS and column level encryption for sensitive columns. Above all if storage system offers its own encryption, independent of a system managed encryption facility provided by the OS, I would do that in addition to the above.

The original question was for zOS but you take LUW as an analogy to put forth the argument. I assume DB2 LUW is similar and I expect whatever I say is equally valid for LUW knowing well that I lack insight into the internals of DB2 LUW.

Now, I rest my case in support of column level encryption scheme.

Venkat

Jørn Thyssen

RE: Encryption Practices on DB2 z/OS
(in response to Venkat Srinivasan)

Hi Venkat,

I agree that column level encryption offers better security, but if your auditor is satisfied with disk encryption, why go through the hard work to implement better protection?!

If you use pervasive encryption any user with SELECT authority can still see the data. However, since access now has to go through Db2 you are in a good position to control and audit access (through Db2 traces or vendor solutions).

The gold solution is application encryption where the application encrypts the value before sending to the database. The value is stored encrypted in a binary column. Now the value is encrypted everywhere (Db2 VSAM data sets, image copies, UNLOADs, data warehouses, dumps, thread memory, in all communication, etc etc.), but it is expensive to implement because it requires application changes.

With column level encryption the data is stored unencrypted in thread memory and sent unencrypted over the network (hopefully you are using SSL), so there are some exposures.It is also still difficult to avoid the need for DBAs to have access to data, e.g., if an application deployment requires DROP/CREATE so an UNLOAD/LOAD is needed.

Furthermore, the use of field or editprocs requires DROP/CREATE of the table whereas the use of encryption UDFs does not,  but instead requires application changes.

Which brings me back to the question I asked: What is the business requirement? That is, what level of protection is required by the business (read: auditors). 

Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: www.rocketsoftware.com 

2018 IBM Champion.

Views are personal. 

Venkat Srinivasan

RE: Encryption Practices on DB2 z/OS
(in response to Jørn Thyssen)

Thank you and I see your point about potential exposure and as long as the key is tamper proof it should be good. If someone considers encrypting data they must perform data transfer over wire. I am not aware of a ICSF type process in unix windows side to assist in this regard. If there is one i would like to know. 

Is the intent to protect data theft and secure the environment or satisfying some auditor. That almost touches fiduciary responsibility. I believe these days the ceo certifies  that everything is in order and I dont want to go there. 

In my view, once breach has been made audit loses value. Once my identity is compromised do i care who did it. FBI might but i dont have any interest in that. But both are important in reality. Few people realize that touching fire is not pleasant and few realize the truth only after a burn.

venkat

Michael Hannan

RE: Encryption Practices on DB2 z/OS
(in response to Jørn Thyssen)



In Reply to Jørn Thyssen:

The gold solution is application encryption where the application encrypts the value before sending to the database. The value is stored encrypted in a binary column. Now the value is encrypted everywhere (Db2 VSAM data sets, image copies, UNLOADs, data warehouses, dumps, thread memory, in all communication, etc etc.), but it is expensive to implement because it requires application changes.

I think column Encryption needs to be used very sparingly. How to apply range predicate searches against Binary encrypted columns. Maybe you use it only for columns that cannot be range searched, and range search was never a desirable thing. If Employee salary was encrypted, you would not be able to select employees with Salaries in a given range. If Name was encrypted, you could not do a LIKE Search. BINARY columns are also very hard to manipulate in SQL, with almost no functions to cast them to another datatype, but I guess manipulation was not desired.

If Encryption is done by DB2, then it may be possible to apply a range predicate to a column with Decrypt function applied to it, stage 2 processing but at least did not have to return all rows to the application before decrypt could be performed with filtering down to just the rows needed.

If you have application encryption, you would get "Stage 3" filtering outside of DB2. You only want to do that if you retrieved row(s) by unique key. So as a performance tuner, I feel like Application Encryption might be the Gold Standard Crap!, effectively disabling the DB2 Optimizer. If disable the Optimizer too much, then maybe DB2 is no longer the right solution.

Don't hear much about mainframes getting hacked! Only about users authorised to see the data, misusing it, or someone guessed his password, or found the list of passwords in the rubbish bin. I can't misuse data simply because I am not authorised to access it, unless I would somehow misuse HIGH2KEY and LOW2KEY (hardly meaningful), or FREQVAL Stats. Multi column COLGROUP Value Stats could be considered dangerous if very sensitive column groups were populated. LOL.   COLGROUP Stats are most useful for a full equals match on the column group with Literals (or REOPT) or Dynamic, so unlikely that it is useful to populate COLGROUPs with sensitive column combinations, as full equal match for search will not occur.  Single column Freq Value Stats are generally more useful and less sensitive. 

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ May 31, 2018 - 09:55 AM (Europe/Berlin)

Jørn Thyssen

RE: Encryption Practices on DB2 z/OS
(in response to Michael Hannan)

Hi Michael,

There is some research going into order-preserving encryption so you would be able to do some stage 1 processing on the encrypted data. You certainly don't want to do application encryption for every column in your database. Hopefully you only have very sensitive data in a few tables (although I have seen customers using sensitive data as PK/FK...), so you could choose a mixed strategy of pervasive encryption, column level encryption and application encryption.

Mainframes do get hacked occasionally, and I think as other platforms is hardening up you will start to see more (successful) attacks on z/OS.

Anyway, for many customers there will be other things they need to do to secure the platform before they venture into application encryption, like going to MFA instead of 8-character case insensitive RACF passwords.


In Reply to Michael Hannan:



In Reply to Jørn Thyssen:

The gold solution is application encryption where the application encrypts the value before sending to the database. The value is stored encrypted in a binary column. Now the value is encrypted everywhere (Db2 VSAM data sets, image copies, UNLOADs, data warehouses, dumps, thread memory, in all communication, etc etc.), but it is expensive to implement because it requires application changes.

I think column Encryption needs to be used very sparingly. How to apply range predicate searches against Binary encrypted columns. Maybe you use it only for columns that cannot be range searched, and range search was never a desirable thing. If Employee salary was encrypted, you would not be able to select employees with Salaries in a given range. If Name was encrypted, you could not do a LIKE Search. BINARY columns are also very hard to manipulate in SQL, with almost no functions to cast them to another datatype, but I guess manipulation was not desired.

If Encryption is done by DB2, then it may be possible to apply a range predicate to a column with Decrypt function applied to it, stage 2 processing but at least did not have to return all rows to the application before decrypt could be performed with filtering down to just the rows needed.

If you have application encryption, you would get "Stage 3" filtering outside of DB2. You only want to do that if you retrieved row(s) by unique key. So as a performance tuner, I feel like Application Encryption might be the Gold Standard Crap!, effectively disabling the DB2 Optimizer.

Don't hear much about mainframes getting hacked! Only about users authorised to see the data, misusing it, or someone guessed his password, or found the list of passwords in the rubbish bin. I can't misuse data simply because I am not authorised to access it, unless I would somehow misuse HIGH2KEY and LOW2KEY (hardly meaningful), or FREQVAL Stats. Multi column COLGROUP Value Stats could be considered dangerous if very sensitive column groups were populated. LOL.   COLGROUP Stats are most useful for a full equals match on the column group with Literals (or REOPT) or Dynamic, so unlikely that it is useful to populate COLGROUPs with sensitive column combinations, as full equal match for search will not occur.  Single column Freq Value Stats are generally more useful and less sensitive.
 

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd



 

Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: www.rocketsoftware.com 

2018 IBM Champion.

Views are personal. 

Phil Grainger

Encryption Practices on DB2 z/OS
(in response to Michael Hannan)
“Don't hear much about mainframes getting hacked!”

There was a very interesting session at UK GSE last year that posited that to do something like WannCry on the mainframe, all you would need is someone with access to an APF authorised library and some system programming skills. The risk here is not from an external actor but from an unhappy internal one. Mainframes are much less at risk from external events, that IS true

You’d be amazed at how fast a mainframe could encrypt data

And even if the data were encrypted already, encrypting the encrypted data is still going to leave people in a bad place

________________________________

Phil Grainger

Enablement Manager

[login to unmask email]

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[cid:[login to unmask email]






From: Michael Hannan [mailto:[login to unmask email]
Sent: 31 May 2018 08:51
To: [login to unmask email]
Subject: [DB2-L] - RE: Encryption Practices on DB2 z/OS



In Reply to Jørn Thyssen:

The gold solution is application encryption where the application encrypts the value before sending to the database. The value is stored encrypted in a binary column. Now the value is encrypted everywhere (Db2 VSAM data sets, image copies, UNLOADs, data warehouses, dumps, thread memory, in all communication, etc etc.), but it is expensive to implement because it requires application changes.

I think column Encryption needs to be used very sparingly. How to apply range predicate searches against Binary encrypted columns. Maybe you use it only for columns that cannot be range searched, and range search was never a desirable thing. If Employee salary was encrypted, you would not be able to select employees with Salaries in a given range. If Name was encrypted, you could not do a LIKE Search. BINARY columns are also very hard to manipulate in SQL, with almost no functions to cast them to another datatype, but I guess manipulation was not desired.

If Encryption is done by DB2, then it may be possible to apply a range predicate to a column with Decrypt function applied to it, stage 2 processing but at least did not have to return all rows to the application before decrypt could be performed with filtering down to just the rows needed.

If you have application encryption, you would get "Stage 3" filtering outside of DB2. You only want to do that if you retrieved row(s) by unique key. So as a performance tuner, I feel like Application Encryption might be the Gold Standard Crap!, effectively disabling the DB2 Optimizer.

Don't hear much about mainframes getting hacked! Only about users authorised to see the data, misusing it, or someone guessed his password, or found the list of passwords in the rubbish bin. I can't misuse data simply because I am not authorised to access it, unless I would somehow misuse HIGH2KEY and LOW2KEY (hardly meaningful), or FREQVAL Stats. Multi column COLGROUP Value Stats could be considered dangerous if very sensitive column groups were populated. LOL. COLGROUP Stats are most useful for a full equals match on the column group with Literals (or REOPT) or Dynamic, so unlikely that it is useful to populate COLGROUPs with sensitive column combinations, as full equal match for search will not occur. Single column Freq Value Stats are generally more useful and less sensitive.


Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image001.jpg (8k)
  • image002.png (5.9k)

Venkat Srinivasan

RE: Encryption Practices on DB2 z/OS
(in response to Michael Hannan)

For tax payer id, financial account and drivers license  in US, some states have legal mandate to "safeguard public display of data" and "data transfer over internet should be encrypted". The term encryption is actually prescriptive when data moves over internet it is not prescriptive otherwise. I am surprised they don't say all network.

Some states prohibit usage of SSN for private use. Being a breach victim is not a crime but data breach notification is a federal mandate. We as public often times find out some of the egregious samples of exemplary human stupidity in these revelations.

Financial account, SSN and Drivers license number are commonly encrypted. SSN removal effort is also fairly common.

Legal statutes are unequivocally ambiguous presumably because those who write it think they are the smart ones. The average board room member is not interested in performance.

If indeed, SELECT * FROM MY_DATA_LAKE where SSN between 000000000 and 999999999 is so important to running the business, then you spend some time thinking about how to safeguard the data in a reasonably secure way. At worse the corporate will pay a fine and get away. In some case it may take the C* executive a trip to Washington where the smart ones who write ambiguous law will haze for an hour and the worst will be over by the time return flight takes off. But if a person is an identity theft victim it haunts for the rest of the life.

I have never seen any one encrypting last name and salary but there may be few paranoid situations where it is done.

Specific to DB2 zOS row level or column level access controls and masks can be put in place so use of prohibited information is only limited to those that need to see to perform their job. Encrypting in a manner to hit functionality is not the goal.

Health privacy does not mean you encrypt all health data for the individual and put it in a BLOB and make search impossible and meaningless. With data sharing, member subsetting etc, you can harden access at LPAR level so authorized secure operations occur only in hardened LPARs protecting the data at all times.

Hacking is different from breach. Approved encryption scheme only minimizes impact of what was stolen assuming key was not compromised. There is no guarantee that it wont ever be decrypted. 100% security does not exist in reality. When you give a password for someone, you trust him and implicitly trust everyone he trusts. That is the reality.

Vendors around mainframe do not usually disclose vulnerabilities and you wont see them mentioned in APARs and PTFs. Vulnerability score and short brief can be found if you know where to look. The belief that mainframe can't be penetrated should stop. TCP/IP, VTAM, Java and USS are vulnerable zones.

Life is so unfair these days and we cant talk performance at all times. You do the right thing to the best of what you can do. If I were to protect something for my own use, "what I would do" is what I usually suggest in my engagements as if my very inheritance is at stake. To listen or not not to listen is left for the team to decide and ultimately it is the team's collective thought that wins.

When it comes to data security if you assume that eventually penetration will happen, you will devise appropriate counter measures and that will always safeguard the data. In this game, the counter measure in place today will be obsolete tomorrow.

Venkat