Sensitive Data Masking in PeopleSoft

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.

 

10 thoughts on “Sensitive Data Masking in PeopleSoft

  1. Daniel says:

    Hi Colton,

    That’s really great. Did you have to embed the bolt-on code in all pages and components that require data masking? Are you using Tools 8.55 by configuring the customization at Component postbuild or prebuild?

    Thanks,
    Daniel

    • Colton Fischer says:

      Hi Daniel,

      Thanks for reaching out. The functionality that you are seeing in this video is achieved with the use of servlet filters. This does not make use of the 8.55 event mapping. All of the code that does the data masking resides on the web server. Servlet filters are nice because they provide the ability to achieve custom functionality without the need to customize the application. Please let me know if you have any more questions.

      Thanks,
      Colton

  2. Erik Volkman says:

    Does the sensitive data still exist in the DOM before it is exposed or is there a round trip to the Web/App Server to retrieve this information when the user requests it?

    • Colton Fischer says:

      Hi Erik,

      The sensitive data is not exposed in the DOM. The sensitive HTML element is replaced entirely by an injected img element. This img element has an onclick event that calls the app server to retrieve the data. The app server logs the transaction to the database and conditionally responds to the client’s request… Sorry if this is confusing. Please let me know if you would like more clarification or if you have any other questions.

  3. Harsha says:

    Hello Colton – This tool is amazing. I have a similar requirement for my client, but then some changes need to be done. can you share more technical details on this or are you selling this bolt-on?

    Thanks,
    Harsha

    • Colton Fischer says:

      Hi Harsha, thanks for the kind words. I’d be interested in better understanding the needs of your client and how this tool can potentially be a solution. I do not mind sharing technical details of this project. Most of the major technical aspects of this project have been discussed in granular detail in other posts on this blog. If you would like for me to go into detail on a particular aspect of this project, then just let me know what it is that you are interested in understanding. I can try my best to explain it here or I can make future blog post if needed.

  4. Brennan Folmer says:

    Hi Colton –

    Great job on the approach and the write-up. Very elegant solution.

    I did have a question about the call-back approach when a user clicks on the lock icon. I’m assuming your servlet is replacing the real data with some javascript to handle the click and make a request to both verify/enforce 2FA as well as retrieve the masked data. But, I’m unsure how you are retrieving the proper data that was originally masked. Are you calling back to an iScript that first handles the 2FA work and then somehow pulling the masked data for the specific transaction? If so, how is the correct data pulled for that particular transaction?

    • Colton Fischer says:

      Hello Brennan. All of your assumptions are absolutely correct. The servlet filter replaces the original element that contains the sensitive data with an image element that calls an IScript on the “onclick” event. When the filter injects this image element, it also injects an encrypted token that contains the level 0 keys, component name, record field name, row number, as well as the original data itself. This is what gets sent to the IScript so that it is capable of returning the decrypted/unmasked data if needed. This is also what allows the IScript to log the key information (Who, What, When, and Where) of the transaction.

      After looking back on my response to Eric’s comment above, I realize what I said may be mis-leading and not explained thoroughly. The sensitive data does not exist in the DOM, but an encrypted version of the data does exist in the DOM.

      Please let me know if I explained this well enough as well as if you have any other questions.

Leave a Reply

Your email address will not be published.