Using Event Mapping to perform field level data masking is an idea that I have toyed with since the release of Event Mapping in PeopleTools 8.55. Event Mapping is a desirable tool for field level data masking in PeopleSoft because it can allow for bolt on runtime application logic to determine if a user should have the ability to view a particular piece of data. I am unfortunately not here to say that Event Mapping can deliver us a (much needed) data masking framework for PeopleSoft applications. However, I have recently found that Event Mapping is capable of satisfying one particular field level data masking requirement that I threw at it. In this post, I will be sharing a proof of concept project that I’ve used to perform conditional data masking on a read only data field within a delivered Fluid page.
I’d like to share a demonstration of a field-level data masking solution that I’ve created for PeopleSoft. This project showcases a lot of the techniques that I have discussed throughout the year on this blog with respect to creating a secure PeopleSoft application with a good user experience. This bolt-on solution provides a user interface to configure what fields to mask, the conditional ability for end users to unmask data, and a way to track the sensitive data exposure throughout the system.
I previously demonstrated how servlet filters can be used to view and modify HTTP requests that the client sends to the web server. This post will demonstrate how servlet filters can view and modify the HTTP responses that the web server sends back to the client. The servlet filter that will be used in this demonstration is one to mask social security numbers (SSNs) that appear in the response messages. Using servlet filters to perform sensitive data masking does not change the actual value of the data in the database, but it still protects the true values from being exposed through the PIA.