– By Justin Donohoe, May 5 2015
It was a seasonally cold winter morning, and I had been afforded a rare window to beat the morning rush and get into the office early. The only sounds in those early hours were the periodic clicking from the automated lighting systems and the persistent drone of a printer churning out copious pages of an overnight report. Due to the early hour, the smell of freshly percolating coffee had not yet begun to waft through the office.
Enjoying the opportunity to focus on a backlog of project needs, I eagerly dove in to get a head start on the day. But my enclave of focus would soon be interrupted:
“Do you know what is on these pages!” demanded a women standing in front of me with the stack of papers that had been accumulating on top of the printer.
Startled and bewildered, I took a brief moment to regard this very animated woman. She was close to retirement age and had a smart, almost prim appearance that stood out somewhat from the casual attire worn by the contract staff that comprised the majority of the work force in this section of the building. I recognized this person as full-time but could not put together enough information to determine the relationship she may have with my team managers. I had no idea what was on these reports or what group she represented, but I could tell immediately this was not going to be a pleasant encounter:
“Personal information for every single employee along with their salaries – that’s what!”
I had enough of a background with encrypting sensitive information to understand the import of this development. I could also sense that she had grown impatient with my lack of a response: “Did you hear me! Every single one! Names… Social Security numbers… addresses!”
I began to surmise that this woman was aware that I was the only consultant in at the time:
“DID YOU PRINT THIS?” she demanded sternly.
“No, I did not.” I responded firmly but calmly.
“WELL WHO DID?” she insisted.
Not unlike so many other security sanctuaries built to keep the miscreants of the cyber world out and keep sensitive information safe from prying eyes, this organization possessed what could be described as a formidable security fortress. To my knowledge, it has never been breached or hacked. Armed with vast technical resources and ample technology funding, these cyber vaults are very hard to breach – from the outside.
The truth is, however, that many information breaches do not come from the outside – at least not entirely. Within the sanctuary of trust, staff must be able to process and work with the protected information that has been collected. In other words, even within the most secure vaults the data needs to be ‘unlocked’ at some point so that people and/or automated programs can make assessments and determinations on the information. Nefarious internal resources or simply savvy opportunists may exploit this vulnerability as a way to get at sensitive information from the inside if organizations are not careful.
I never found out who printed the report or what the ultimate outcome was, but I have never forgotten this encounter. Whether this was an innocuous test run of a report or surreptitious attempt to steal thousands of valid identities for profit, had it not been for this woman, any one of the hundreds of people in that office could have easily taken this printout and created a significant and undetected security breach.
While her diligence is both admirable and commendable, the main lesson I took away from this event is that “she” may not always be there. To this day, I make it a point to design and architect technical solutions and processes so that organizations can meet their business needs while making sure sensitive data remains secure, including inside the sanctuary of trust.
In addition to designing secure software, however, there is an equally important facet to making the applications within an organization more secure. Project leads need to work with key system users to determine precisely which information is required to complete the tasks at hand. Note that the key here is the “Less-is-More” rule. Here are some basic questions to start with:
- Does the system need to pull and/or display any sensitive personal information?
- If so, can any of it be masked or obfuscated?
- If not, how frequently does the information need to be pulled?
- Is any sensitive information needed for reports?
- If so, which actors need to see these reports?
- How frequently will these reports be run?
In the early days of software application development, systems were designed to be at-the-ready to pull helpful information to be able to offer assistance to users in order to increase productivity. This paradigm has changed. Users today need to be part of the solution and assist designers in working to only pull the least amount of personal information required to get the job done. For example:
“I need to see any records related to S. Samson”
can be reworked in the front-end to…
“Return to me an integer representing the number of matches for S. Samson”
…then perhaps allow the user to inquire more deeply if necessary.
The goal needs to be ‘let’s think about what if this was my information’ and how can we design systems to allow for the least required access to sensitive personal information. This will help arm today’s system architects with the ability to further lock information away from cyber intruders as well is internal threats.