Could an outsider contact your security team without having insider knowledge?

Could an outsider contact your security team without having insider knowledge?

Imagine that you’ve just been handed information that could absolutely wreck one of your critical suppliers. Information that could be used to bankrupt them through misuse of their own systems, open their vital systems to criminal exploitation, destroy their professional reputation, or all of the above. You didn’t ask for this information … you don’t want it … but there it is. You have another company’s future in your hands and want to be rid of it before you’re implicated in any potential damage … and there’s no safe way to give it back. What would you do?

My mate Pablo – the fellow I introduced two weeks back – had this exact unnerving experience last week. He related the story to me over a pint, looking pale and sounding shaken throughout. I was incredulous, but he swears it’s all true … and he has witnesses.

As Pablo described it, he was working his inbox first thing in the morning when he found a new message sent by some sort of automated process. It was the equivalent of “support-system[at]” Pablo recognized the sender’s domain; he receives messages from reps of this company every day. Oddly, this was the first time he’d received a message from this company sent a service rather than a person, but … what the heck. It seemed trustworthy.

The email itself was strangely terse: just five words that didn’t communicate anything and an Excel spreadsheet. This, too, wasn’t peculiar for the sending company; their emails were almost always just wrapping paper for complex spreadsheets. Thinking little of it (and violating the rule of “context violations” from his phishing defence training), Pablo opened the spreadsheet and was confused: the first sheet in the workbook was nothing but tables describing the company’s internal business processes. This was content that Pablo’s company couldn’t do anything with (and probably shouldn’t be privy to). Un-useable and weird.

It was, I imagine, the same reaction that my old boss had the first time I showed him a magazine layout mock-up full of “lorem ipsum” placeholder text. The befuddled colonel asked why I’d written the entire magazine in Latin.

Confused, Pablo forwarded the message to his supervisor on the assumption that maybe they might have a better idea of what to do with it. Pablo moved on and put the bizarre message out of his mind … until a few hours later when he heard his supervisor swear from across the room.

“This … thing,” the supervisor sputtered, “is full of passwords!”

The entire office crowded around the boss’s desk and stared, mouths agape, as the supervisor slowly scrolled through a worksheet full of system credentials and the systems they would unlock. Row after row of entries, reading: “jsmith[at], PASSWORD123,”  [1]

Pablo and his colleagues were horrified. Their critical supplier has just suffered a catastrophic Data Loss Prevention incident. At the very least, every system appearing in the spreadsheet was now compromised. They’d all seen the credential sets and could enter those systems as the listed user and no one in either the supplier’s org or the hosting service would be the wiser. Some of the listed systems were internal to the supplier’s network; others were for suppliers of their own. Every single account needed to be locked down and its password reset immediately.

More importantly, the message had been sent unencrypted, meaning anyone along the message’s journey between sender and receiver might have intercepted and read the file. Every affected system owner needed to be warned of a credentials compromise so they could initiate their own investigations into possible system intrusions. This was a big deal … Pablo’s company was now responsible for safeguarding their supplier’s information and for helping to resolve the resulting security incident for multiple companies (many of which they didn’t have a relationship with).

Just learning the identities of a company’s obscure suppliers provides a would-be attacker with a treasure trove of actionable intelligence. Imagine how effective a phishing or social engineering attack could be if you pretended to be the victim’s caterer and referenced a real recent menu selection as your lure.

This is the part where I’d like to type “the team sprang into action” … but no, they didn’t. In reality, they all burst into manic laughter at the absurdity of the situation. None of them really knew what to do. They knew the situation was dire, but they’d never been trained for this.

Pablo gave it a quick think and decided to search the vendor’s page for a phone number to call. The supplier had a “fraud hotline,” but that didn’t seem right. Unsure of what to do next, Pablo tried replying to the original message. He typed, “Hey. This Excel file you just sent me contains a bunch of confidential and proprietary information that I don’t think we’re supposed to see. What can we do to help address this?” (or words to that effect). Pablo clocked the send button …

… and received an immediate automated reply advising him that the service account was not monitored. Crud.

Undeterred, Pablo reached out directly to his primary point of contact at the supplier and tried to convey the seriousness of the problem. Not long afterwards, he received a terse reply of two words: “please ignore.” Se previous, re: manic laughter.

Pablo, his boss, and his office mates were stunned. Please ignore? Did that mean they were to delete the message and pretend it never existed? What would that path do to their company’s potential legal liability? If the supplier was breached in the coming days and the criminals used content from the misdirected email, could they somehow be sued for not protecting the supplier’s confidential information? Could they be blamed for what they did (or didn’t do) with the supplier’s information? They had no idea.

Most American companies craft policy on how to protect their own sensitive information; very few (I’ve found) spell out how to protect other organisations’ sensitive information once it comes into their possession.

The only advice I offered Pablo was to contact the supplier’s security department directly. Let them know what had happened. Replying to the sender risked making an already bad situation worse, as the employee learning of their (or their team’s) catastrophic DLP foul up was strongly incentivized to cover up the event and not report it. Maybe, the shoulder devil whispers, the problem will just “go away” if no one talks about it. Best not to make a fuss … That’s wholly natural self-preservation instincts kicking in. Completely wrong, but understandable.

No, what needed to happen for everyone’s sake was to get the supplier’s security department alerted ASAP. The faster they investigated the extent of their exposure, they faster they could initiate corrective actions and make their mandatory disclosures. The longer Pablo’s team waited, the worse the potential danger grew for the supplier’s security team … and the greater the potential damages both organisations might suffer.

The trouble was, there was no way to reach the supplier’s security department from outside the company since their contact data was restricted. If their own worker didn’t do the right thing and properly report the incident, how could anyone outside the company report it? For their own protection, the supplier needed some sort of gateway for partners, customers, and vendors to reach them in the event of a suspected emergency. Maybe not a direct line to the SOC, but something. Some external security incident reporting entry point.

But they didn’t, and that probably doesn’t come as a surprise. Look at your own organisation’s public internet presence and consider what would have happened if that had been one of your people mistakenly emailing a document full of unencrypted system credentials across the internet … Could an outsider have contacted your security team without having secret insider knowledge?

If reporting a suspected security incident demands the same level of elite “hacker skills” as engineering a network breach, you’re working against your own enlightened self-interest.

DLP incidents are real and disturbingly common, and not just because people still insist on storing user credentials in spreadsheets. The lack of encryption capabilities, the prevalence of auto-fill “help“ in email apps, fatigue, distraction, multitasking, and typos will ensure that confidential records will ensure that every organisation everywhere has to deal with DLP problems until intelligent robots rule the earth (and even they will probably store their passwords in Excel files).

As much as we fight to prevent DLP screw-ups, we all need to be pragmatic about how we respond to them. Pablo’s experience illustrates how essential mitigation factor needs to be a fast and reliable method for hearing from outsiders who accidentally received your proprietary sensitive information and want to give it back … but can’t because we made it nearly impossible for them to reach us.

Take this as a cautionary tale and consider what you might do to get ahead of this problem. Maybe it’s a clause in your contracts with third-party suppliers. Maybe it’s a secure public-facing webform. Maybe it’s a trusted proxy that handles the reporting and exchange for both sides. Whatever you choose, choose something … before you really need it.

[1] And yes, some of the passwords Pablo read really were that awful.

Copyright Lyonsdown Limited 2021

Top Articles

Is your security in need of an update this Cybersecurity Awareness month?

Cyber security experts tell teiss about the evolving threat landscape and how organisations can bolster their cyber security defenses

A new case for end-to-end encryption

How a hacker group got hold of calling records and text messages deploying highly sophisticated tools that show signs of originating in China

Telcos in Europe put muscle behind firewalls as SMS grows

Messaging is set to be one of the biggest traffic sources for telcos worldwide prompting them to protect loss of revenue to Grey Route practices 

Related Articles

[s2Member-Login login_redirect=”” /]