Do we really not trust our employees? Why exactly do we need an additional API call in the data mask?
The team began to question the need for this as we progressed through our first application migration from the WebSphere platform to an AWS environment. I was arguing about hiding sensitive data before it reaches the database layer. We had a need to keep a note. We had no requirement to store sensitive identifiers within it. A user working on a claim or policy change writes a note, and in that note they might type an SSN, a driver’s license number, or a credit card number — and those identifiers are already held in the organization’s systems of record. Note the new information. The identifiers are not, and the second copy of them sitting in the notes database is useless.
The identifiers that the user types in the note are not their own. They are for consumers. The question was not about necessity. It was about the integrity that the organization promised to its customers, as well as compliance and compliance.
It’s about debt prevention
It’s not that we don’t trust our employees. No one is judging anyone’s work or questioning the integrity of how they work within their role and work. Masking is not an insult. We ensure that we do not display sensitive customer information to every user of the app that is able to open it. It’s not insulting — it’s about crime prevention.
When we integrated our UI and API in a test environment, we entered an SSN-shaped value into the free form text – generated by the way we created it – and received the same value, encrypted. It raised a question. I went to our product owner, who had spent fifteen years testing applications on this site. He couldn’t test ours yet, because it was still under development. But he pulled out his archived test artifacts from a different application in the portfolio, and showed me what the same identifier class looks like after masking.
Humans are trained, but they still mess up, and there is no limit to user action on the UI screen. We’ve found that the best fix is to add an API call that buffers sensitive data before it hits the database.
In the real world, no one wants to see their personal or sensitive information repeatedly on a UI screen. For example, we don’t see our own bank account number every time we log into a bank website. It comes hidden, showing the last four digits. So why does anyone need to see, read, or print that information every time they open a customer ticket or claim? We were also providing a print feature, so we don’t even stay on the screen — we can end up on paper. And seeing sensitive information over and over again can cause someone to memorize it without explaining it. We will not reveal it to anyone on purpose, we are honest people. But why do we see it over and over when we don’t need to?
A warning symbol with a red font label on the UI screen sends a strong warning signal to the brain that helps the user to be careful while entering any information in the text field of the free form. The signal not only increases awareness, but also slows down the reflex action, giving the user a moment to pause while entering information into the field.
Writing an internal encryption algorithm
As discussed in the group, some argue that since we provide training, the user will notice, while others argue that we provide a warning label — why wouldn’t the user read it? Others came up with this: why do we need an extra API call to hide it, let’s use an internal hiding algorithm?
It took a day and a half to build a POC for the internal algorithm. On the second afternoon we brought it down to the group: enter any value, find the hidden value. We asked them to break it. In about forty minutes, by feeding various inputs and learning the outputs, they had a pattern. They understood the challenge themselves, and agreed that an internal algorithm would not work – go with an enterprise service.
During those arguments, I took a coffee break and thought about it differently. If a developer writes logger.info and prints the values we enter, that sensitive information is now in the logging stream. And once it’s stored in the database as it is, it’s exposed to all the downstream systems that read it – analytical reports, marketing quotes, and any audit trail we end up not seeing.
Data classification should be of equal importance as design in any application. We took it as a trivial task that could happen in parallel with development, and that was wrong. We need to understand our data like we need to understand our architecture.
