Profiles In Scourge: Decisive Moments In Cyber Security

Anonymous Anecdotes from Cyber Security Leaders

Add bookmark

Seth Adler
09/08/2020

As defined by the Cambridge Dictionary, a scourge is something or someone that causes great suffering or a lot of trouble.

The cyber security community does battle with scourge every day. There are times of course, that scourge wins. But way more often than not, cyber security executives who incidentally, have gained a more proactive stance over the past few years, defeat scourge.

No matter how many threats have been thwarted, there are always lessons to be learned from use cases. And so, a few of our friends in the community have been kind enough to anonymously share anecdotes from the front lines.

SCOURGE AS FOG OF WAR

We see indicators of the attempts to steal intellectual property, and if you've read any of the good spy books yeah- I get to see some of that firsthand and we kind of laugh about it, but it's like, "Yeah, it's not paranoid, it's not the conspiracy theory." I go back to a military reference- the fog of war. The fog of war sets in when it all becomes confusing and somewhat overwhelming with all the smoke and the fires raging on the battlefield. That’s what it’s like. You have to really work with your team. You have to help them prioritize. You have to give them time off, because when you really start monitoring your network logs, your port scans and data exfiltration attempts, it turns into the fog of war. And that's an everyday thing for every cyber security team out there. If there's a cyber security team out there saying they don't see it, this cause they're not looking.

SCOURGE AS WHALING ATTACK

As defined by NIST, whaling is a specific kind of phishing that targets high-ranking members of organizations.

An email account of a contact of one of our past CEOs got breached. His contact details were exposed. The bad actors discovered that he was the CEO of our organization, so they orchestrated his email to send a malware attachment. It was very well crafted; it was an update to the board strategy. All of the board members were clicking on these links. And I think one of our former board members data on his personal machine got wiped out. As it happens, he was actually pretty technically savvy. He had done his backups- it turns out, the night before. So ultimately no harm was done. Nothing happened to our organization, because we were protected. But this was more a reputational thing with those individuals. About 200 odd organizations spread out across Perth, Australia had been affected. So, I had to go a little bit ‘cap in hand,’ to some of the organizations that had received the email, and just say, "Oh, look, his email account got overtaken. And just be wary if you receive any emails." I even made some personal visits to individuals to help them through it. But as it turned out, antivirus kicked in from all of those organizations. So no one actually lost anything.

SCOURGE AS DATA EXFILTRATION

As defined by NIST, data exfiltration is the unauthorized transfer of information from an information system.

I have many memories of interns and students who worked for companies that I worked at, who felt no problem emailing bundles of zip files and documents out to their personal Gmail account, or Yahoo at the time- because they thought it was their information. They would have had no issue with violating company acceptable use policies, to send this stuff out, because they thought they owned it and they were going to use it for the next job. it wasn't necessarily nefarious. They thought, from their mindset as an intern, as a college kid, "I put the work in here.” And maybe it's a spreadsheet that has some market formulas that are actually proprietary. They didn't think that. They figured they worked on it, they own it- it's theirs; they can take it on to their next job. So detecting that was fun, and then getting HR involved was even more fun. And I tell you; it didn't end well for some of those interns. What made it worse was that I trained all of these interns in their first week on the job. I remember giving them InfoSec training 10. And one of the things I mentioned was, "This is proprietary information. You don't use personal emails." While it was an affront to me then, I’ve taken those learnings forward.

SCOURGE AS SUPPLY CHAIN ATTACK

As defined by NIST, attacks that allow the adversary to utilize implants or other vulnerabilities inserted prior to installation in order to infiltrate data, or manipulate information technology hardware, software, operating systems, peripherals (information technology products) or services at any point during the life cycle.

Things are connected into your environment, but they're not really an IT-managed resource. They're not running your patching. They're not running the security agents on them. The vendor is supposed to maintain them, "supposed to" being the operative phrase. Over time, things don't get actively managed. It's an afterthought that you just assume things are happening. Nobody's really looking. You don't know what you don't know.

SCOURGE AS INSIDER THREAT

As defined by NIST, an insider threat is the threat that an insider will use her/his authorized access, wittingly or unwittingly, to do harm to the security of the United States. This threat can include damage to the United States through espionage, terrorism, unauthorized disclosure, or through the loss or degradation of departmental resources or capabilities.

We've had a bad actor or two before. We were very fortunate in that we have the right tools in place that we were able to capture that incident before any data was lost. The short of it is, that person is no longer employed with us. They came in on the weekend, went into the system, collected a bunch of data and information, emailed the information to themselves and then deleted the information off the server. That set off an alarm for unusual activity for this person because of the time of day, the amount of files and the fact that then the files were being deleted off the server. So we started investigating and we were able to go back, find out exactly what was removed. We were able to recover all that data. It was one of those things where you were kind of glad it happened- but you wish it hadn't. The reason I say you were glad that it happened is that security is somewhat of a myth for executives, for boards. Until they actually see it or experience, it doesn't really exist. It doesn't impact them.

SCOURGE AS NO CONTROLS

As defined by NIST controls are the means of managing risk, including policies, procedures, guidelines, practices, or organizational structures, which can be of an administrative, technical, management, or legal nature. An attribute assigned to an asset t hat reflects its relative importance or necessity in acheiving or contributing to the achievement of stated goals.

I'm thinking of a client who had had a security event, but they weren't able to disclose what the security event was. One of the questions that I had after I arrived on site is if they could show me who had access to their systems.

They said, "Well, we don't really track who accesses our systems."

"Okay. Well, how do you know who logs in?"

"Well, everyone logs in as the username Root."

Now, if you're not a Unix person, Root is the administrative control user. This was a global trading firm, and the way it works is, you would be a trader, doing stock trades. You would log in to your trading workstation at the beginning of the day as Root. The problem that they had had was somebody had walked into one of their trading floors- done a couple of million dollars in trades and walked out. There was no proof of who it was, because again, they had logged in as Root.

The only reason that I got involved is somebody pulled that same stunt again in another country- again because they had no concept of a least privilege access model and no concept of user access controls. From a technical perspective, this was very scary because whoever gained access could do source code exfiltration, ransomware- the whole thing. They could take all the code and run. And what’s more is, this company didn't even have badges for their employees. Anybody could just walk in, literally off the street.

It’s companies like that which don't have policies, controls or procedures and the only way cyber security comes to light is through a negative event.