Advice / options for protecting PII

[Former Member]

Hello HCM Experts!

Does anyone have best practices for how companies protect PII data in the HCM module (e.g. tax ID number, government ID, SSN) - especially with regards to "data at rest"?

One item that is being brought up in our environment relates to 'tokenization' in which the field in question is stored in an external system (e.g. SafeNet) and a token is the only data stored in HR.  Whenever the data needs to be accessed, a request is made to the external system.  High level example:

http://www.safenet-inc.com/data-encryption/data-center-security/tokenization-manager/

I've also heard of encrypting at the database (column) level - have not done too much research on that aspect.

Eric

[former_member202002 · Accepted solution]

Similar to the answer which Christopher has give, an option you may consider is using an external Tokenization solution.  In this approach, assuming the data in question is entered and stored in an SAP system, the sensitive data you wish to protect is sent to an external server or service provider where it is encrypted and a random "token" is assigned to it.  The token is returned to be stored in the SAP database in the same field where the data would have originally been stored.

By using tokenization, you can still access the data by sending the token to the external tokenization server/service and retrieving the original data.  However, because the original data does NOT reside in the SAP DB, should there be a data breach or a DBA downloads some SAP tables, only the token will be compromised.  In order to retrieve the original data the token must be sent to the server/service.  Thus, theft of the token provides little to no value to the thief.

[Former Member · Accepted solution]

Great point - I had the concern that a tokenization solution may have a hard time to integrate into whatever SAP programs/screens/reports that access the particular data.  I mean, has SAP actually provided "hooks" for this type of call-out so that 3rd parties could actually build to it?

Asked another way - are you aware of any solutions?!

[Former Member · Accepted solution]

I am familiar with these types of solutions, but because I'm most familiar with those that my company, Paymetric, provides I am trying hard not to seem like I'm only responding to promote my company's products. 

That said, your question about SAP providing the "hooks" is a great question.  As far as I've been able to determine in 20 years working with SAP's solutions, the only "hooks" I'm familiar with are the ones for encrypting credit card numbers.  Because that integration wasn't initially applicable to all instances of credit card related fields in all SAP database tables, we started adding a custom integration point through the use of Conversion Exits at the Domain level or in Search Helps at the Data Element level.

This approach allows you to integrate to an external tokenization service from essentially any specific field you wish.  And by integrating at the Domain or Data Element level the integration applied across all tables where that Domain or Data Element is referenced.

I'd love to find out if anyone is aware of a more elegant approach to integration, because we're seeing an increasingly large interest in tokenizing PII data and would prefer to use a standard SAP interface.  But I'm not aware of a standard interface, only this custom integration approach.

[ChrisSolomon]

Interesting. I haven't heard of any particular "best practice", but have heard of similar things (3rd party solutions) done. It is also interesting to understand the business reason/requirement for that additional level of protection/security given all that we have within SAP as it is. And also, there is a performance and landscape consideration to take into account once we add another "piece in the puzzle". So weighing those costs (license, maintenance, resources, etc) vs. benefit becomes another discussion as well.

[Former Member]

Agreed completely. 

I think the business reasons are coming from two areas:

1. Ability to restrict PII data on screens - i.e. masking the data.  My understanding is you cannot control this based on security.  For example, there could be HR personnel that need access to IT002 fields, but they don't actually have any reason/need for SSN.

2. The data stored in the database is 'in the clear' so anyone with admin access to the server (especially the database) could find their way to the tables.

[ChrisSolomon]

1. I have seen this handled with enhancements....such as have the displayed field actually "masked" with something like "****-**-XXXX". The new decoupled infotype framework classes "output conversion" handles this well.

2. That is why you have audit/access logs so you always can know who touched the data and when. Past that, you should have policies in place for who can see what and where and agreements/contracts in place to those people to accept responsibility for having that access. Lastly, if in the case you have something like a 3rd party solution you describe, a person with access in one places should not have access in the other (ie. I might be able to see your "token" for SSN over in SAP but I should not have ANY access to the 3rd party app where I can then locate that "token" and tie the two together).

At the end of the day, there will be someone (or several) who will have access to "see" this data....but they should have to accept that privilege with the understanding of great penalty if that power is abused in any way. I know MANY banks do this with customer information. I have friends in a bank here at home who have said they know at any time exactly what an employee is looking up/at. If for example they "see" an employee looking up a customer account they are not working on (for example, a call center call), then a "red flag" goes up immediately and can lead to that employee being terminated.