The Day a Hiring Exercise Became an Information Security Incident

It was supposed to be a routine hiring exercise. A candidate receives a technical assignment, reviews the provided material, and prepares a solution. Then someone notices that the “anonymous” dataset isn’t anonymous at all. What follows is an uncomfortable discovery involving confidential business information, questions about data handling, and an unexpected conversation with legal.

In this episode of IT Horror Stories with Jack Smith, we discuss how good intentions, poorly sanitized data, and assumptions about anonymity can quickly transform a recruitment exercise into an information security incident. Along the way, we explore data governance, confidentiality, risk management, and what organizations should do when they discover they’ve shared information they never intended to expose.

Listen now on Apple Music, Spotify, Deezer, Youtube or where-ever you get your panic attacks.

The Ethics of IT: What Happens When Security Slips Through the Cracks?

In today’s episode, we’ll dive into an unexpected security issue we came across. This all began a few years ago during that time when staying indoors was the norm, and masks became our daily accessories. Drama seemed to be seeping into everything, and our IT group was no exception.

The Start of an Unforeseen Journey

During those long days, a few of us continued our professional interactions over platforms like Zoom, Teams, and Jitsi. One of our mates was in search of greener pastures and began interviewing with a new company. The excitement was palpable as he navigated the interview rounds, hoping for a better role.

Initial Signs of Trouble

Our friend was handed an exercise that came with supposedly anonymized data—an exercise pivotal for his job application. Eager to help, we agreed to review his work. However, it didn’t take long before we realized that the data he received was far from anonymized. Names, phone numbers, escalation paths—everything was laid bare, soon giving all of us the chills as we recognized the enormity of this security oversight.

A Closer Look at the Breach

The data we had access to wasn’t just any data. It originated from a large transportation hub bustling with thousands of daily commuters. We were staring at an open door into the company’s confidential corridors, able to identify network maps and escalation processes—with the unsettling potential to access even more through social engineering.

Uncomfortable Realizations

“With the info we got, I could have gone through their escalation path, had passwords changed, and gained entry into the entire system.”

Despite being professionals, the thought of the risk involved was unnerving, even beyond what we’d typically consider ethical ground for light-hearted probing.

The Risk of Social Engineering

What we were dealing with wasn’t simply a breach. It was an invitation for social engineering, the art of manipulating people into divulging confidential information. Armed with personal details, internal support tools, and network schematics, theoretically, all it would take was a convincing phone call to breach their defenses.

Discussing Our Options

Gathered in our meeting, the conversation flowed around the ethical and legal implications. “Were we suddenly white hat hackers? Should we alert someone, anyone, about this gigantic hole in their operations?”

It was compelling and worrisome. A serious leak was at hand, and it needed addressing.

Company Response

This is where things turned a bit strange. Attempting to reach the hiring manager, we found ourselves without any response. After some roundabout communication through an ex-colleague and a childhood friend who worked there, the company initially seemed keen on addressing the breach internally, though the urgency soon faded.

A Series of Unfortunate Events

Within no time, our friend received an official request to destroy the documents, followed by a threatening letter. They claimed our involvement in data theft. No legal grounds supported these claims, yet the situation was tense.

“It felt like they were shooting the messenger. We’ve done them a significant favor by alerting them to this breach.”

Final Thoughts

Finally, the dust began to settle. Despite the unsettling veer the situation took—role reversals from potential employees to suspected data thieves—we knew that securing the information and deleting it from our possession was the right step. We faced a peculiar ethical dilemma, crossing paths with security lapses and corporate oversight.

Lessons Learned

Reflecting on these events brings a sobering realization: even industry giants can miss the mark on security. Our actions, although taken lightly at first, had significant ethical implications. Ensuring that such situations don’t slip under the radar is a shared responsibility between employees and management.

Given the sheer size of bureaucratic inertia, many of these vulnerabilities likely lie dormant, awaiting companionship with ethical whistleblowers or the dreaded attackers with less noble intentions.


One response to “Episode 16 : GDPR Enters the Chat”

  1. Martin Kline Avatar
    Martin Kline

    I worked as an MVS systems programmer for a financial services company responsible for over $100 billion in assets. In addition to managing software and hardware on the systems, I helped with capacity planning and performance management.

    The online applications were designed to be accessible through the internet by account holders. The online systems were started about 6:00 A.M. daily. Transactions were accepted during the day, and were applied to the existing master file to create a new master file during the nightly cycle, when the online systems were brought down. Transaction files were subsequently backed up to tape, so they could be kept long-term.

    Transaction files contained only the information entered by the user. That would include the transaction ID, the user’s account, and what the user was doing, such as how much they were transferring, withdrawing, buying, selling, etc. The records also indicated which sub-organization the transaction applied to.

    Part of daily process involved one of our subsidiaries running batch jobs to summarize transactions for every sub-organization. Since these jobs were reading the backup tapes, they had to run one at a time. They also ran about 20 minutes each, often totaling over 12 hours. These jobs had to finish before the next nightly transaction cycle could begin.

    As part of my performance management objectives, I saw that the analysis jobs were eventually going to run too long, preventing the nightly cycle from beginning on time, and delaying the morning restart. So, I looked for a solution.

    I looked at all the analysis jobs, and saw that each one was reading the entire backup tape end-to-end looking for only one thing to accumulate. In addition, since they were written by typical programmers, they didn’t utilize any extra buffering to make reading the tapes faster. I had some suggestions for the subsidiary to make their jobs run faster, eventually reducing the total run time for all of them to under 10 minutes.

    While analyzing the jobs, I encountered a critical security flaw. Every transaction was recorded as it was received by the online system. This included the user’s input of ID and password. There they were. In plain text. On a file that anyone in the data center could read.

    Realizing that I was in possession of information that could be devastating to the company, I spoke briefly with my manager, telling him I needed to talk with someone higher up in the company about fixing a severe security issue that the subsidiary had. I ended up in a meeting with upper management to discuss the problem.

    The outcome for me was that I was told not to mention this to anyone, and I was essentially on probation. It’s been over 20 years now, and the company has since rewritten all their systems, even migrating off the mainframe.

Leave a Reply

Your email address will not be published. Required fields are marked *