Data Breaches

What is a data breach?

Data exfiltration, also known as data theft or compromise, is the unauthorized transfer of data from a system or network to an external location controlled by an attacker.

Such data is often personal and confidential or could otherwise be sensitive, such as business planning and strategies, or financial information or access. The primary method of exfiltration is via the internet whereby the attacker gains unauthorized access to the systems holding the data and then transfers it to an attacker controlled system.

The data could also be compromised via a stolen laptop or phone that contains sensitive data or contains login credentials to sensitive systems.

How does the attacker gain access?

There are two main avenues that attackers use to gain access to protected systems and at least one more less-common method.

1. Exploit a technical vulnerability

All software has bugs in it. There's just no getting around that. Software today is violently complex as I like to say. Large corporate systems of all kinds have multiple millions of lines of code. No one, single programmer knows what all is in there. Even entire development teams can't easily keep all that in their collective heads. It's just too much. Once a piece of code is written and winds its way along to finally passing acceptance testing, it might never be examined again.

Yes, there are code management systems that help with that. But they don't reduce the complexity of the code itself.

Adding to that complexity is the common reliance on 3rd party dependencies* that are part of nearly all software development today.

* There exists a rich 3rd party ecosystem of open source code that performs specific tasks. No need to reinvent certain functions when you can incorporate them into your project. And that, too, introduces bugs and vulnerabilities. We call that a (type of) supply chain vulnerability.

As a result, software has bugs. There are different kinds of bugs, too, just like in real life. Mosquitoes can be deadly. Cicadas, not so much. Certain classes of security-related bugs can facilitate a compromise whereby bad actors can enter a protected system.

No one knows how many security bugs there are in the wild or where they live. But they are usually found in one of two ways:

One way is by ethical "white hat" hackers, often for a reward, called a "bug bounty". When a bug is found and reported, it is assigned a score based on the impact factor the bug has, and the hacker* that found it is rewarded.

The other way is by "black hat" hackers looking to exploit systems for their gain. Their tools and techniques are pretty much the same. But instead of working for honest reward money or to burnish their legitimate reputations, they have darker motives.

* About that word "hacker": Read my brief explainer on what a hacker is. It's not what you may think.

Interestingly, AI is proving itself quite adept at scanning source code and finding potential bugs. To the extent the source code is "closed" (not openly published) then companies that develop the code have a head start on finding bugs using AI bug detection agents.

That's a good thing. AI finds a bug, maybe suggests a fix, and a human programmer reviews it. Across codebases containing hundreds of millions of lines of code, agentic AI can scan code and identify potential bugs far faster than humans ever could. Even if AI doesn't fix it, just finding it in the first place is immensely valuable.

But that same technique can be used to scan public, open source code repositories as well. In this case, the bad guys could possibly find exploitable security bugs before the good guys can find and fix them.

2. Exploit a human vulnerability

Even the most securely designed systems can be compromised when the human vector is introduced. No software vulnerability need be found and exploited for this to work.

We call that Social Engineering. In short, that means tricking someone, an employee usually, who has legitimate access to a system into disclosing that access to an unauthorized party. They might be fooled into giving up usernames, passwords, and even two-factor codes that are meant to prevent that or performing an action, like clicking on a link, that could lead to compromise.

Hardening systems against socially engineered exploitation is top of mind today among companies large and small. But it is very, very difficult to secure against this class of threat because people can be easily fooled. You never know who might fall for what.

And it's not about user/victim intelligence, either. It's about threat actors understanding human psychology and taking advantage of it. It's the same principles that conmen* rely on to ensnare and fleece their marks, no matter how intelligent the mark may be.

* There's an excellent line from David Mamet's moody and noir 1987 film House of Games where the main character, Mike, a smooth-talking grifter, explains the heart of the con to our protagonist: "It's called a confidence game. Why? Because you give me your confidence? No. Because I give you mine." Conmen give you their trust. That's the hook! Being offered someone's trust is a powerful feeling of self worth and it's human nature to return it.

Mitigating measures include cyber awareness training, multi-factor authentication including code numbers, biometrics, physical security tokens, and the use of "code words", and other measures. The idea being, by stacking authentication mechanisms, you can reduce the likelihood of a social engineering attack from succeeding.

That sounds all well and good, but it also significantly increases the likelihood the employee cannot gain rightful access even without being socially engineered. It makes their job more difficult.

That's because authentication systems all have a tug-of-war tension between security vs. convenience. More of one generally means less of the other. The trick is finding the balance and using the right tools.

3. An Inside Job

Although comparatively rare, there have been cases where an authorized person was bribed, coerced, or threatened, to permit access to unauthorized persons. Other times it's a disgruntled employee or an employee that sees an opportunity. These insider scenarios are actually pretty rare but it's not zero.

Firecracker vs. a nuclear bomb

One of the biggest downsides to today’s cloud-centric ecosphere, especially regarding major platforms like Canvas, QuickBooks, PeopleSoft, SalesForce, and many others, is the potential downstream damage from a single successful intrusion.

Security professionals refer to this as the blast radius. When thousands of organizations or "tenants" in SaaS* parlance, operate under a centralized cloud platform, then the compromise of highly privileged administrative credentials can potentially impact many customers at once. Possibly that provider's entire customer base all in one fell swoop.

* SaaS (Software as a Service) is the term that describes a class of software products are cloud server hosted and accessed over the internet using a browser, usually subscription-based, updated automatically, and have cloud-integration. Typically nothing resides locally.

In security terms, that creates concerns around concentrated trust and possible single points of failure (SPOFs). From the bad actors point of view, that's a hell of a payback for comparatively little work.

By contrast, fully isolated per-customer deployments or local-server solutions can reduce exposure because a breach affecting one institution could not move laterally across to others. Imagine if Canvas was truly isolated per-school rather than all schools simply being tenants in a much larger supervisory system. Had this been the case, the blast radius could have been firecracker-sized and not the nuke it turned out to be.

Let's draw an analogy. Me love analogies!

In a per-school isolated setup, each school is like a single family home in the Instructure neighborhood. A break-in at one house would generally stay confined to that house.

In a typical SaaS environment, schools are more like guest rooms in a large hotel with shared infrastructure. Guests (the schools) still have separate rooms and locks, but if the hotel building itself is compromised, there's a greater potential for problems to spread among all the guest rooms.

Not a perfect analogy, but that's the general idea. You can see why a criminal hacking group would prefer the latter over the former. They could harm thousands of schools with a single attack of the cloud system, instead of having to attack each school individually.

SaaS providers would do well to learn from this object lesson par excellence on things they might do differently. And if I were the CIO of a university, I'd demand such isolation as a condition of doing business. Not that they'd do that, lol. They'd just tell me to kick rocks.

ARPANET, the precursor to the Internet, was built for an era when openness and connectivity were prioritized over security. Shoot, back then, no one gave security a first thought, never mind a second one. When ARPANET transitioned to TCP/IP in 1983, the foundation for today’s Internet was established but it inherited that earlier idea of openness.

Most modern security measures were introduced over the following years, incrementally and reactively. The scale of today’s cyber threats suggests that approach is no longer sufficient.

This is why institutional isolation and quarantining with highly conditional access and gated segregation may become necessary. This is actually how things worked before the internet and cloud-based systems became enmeshed with internal systems over the last couple of decades. But that approach would be costly so no CIO or CFO is going to get on board.

The nature and especially the scale of today’s data breaches were not common until internal systems became broadly internet-connected starting in the mid-1990s. The move to SaaS in the early aughts accelerated that trend significantly. We just didn't see this scale of data breaches before that.

A menu of mayhem

When a threat actor gains unauthorized access to a system, there's several scenarios that can play out, depending on what the threat actor wants to do, how disruptive or not they wish to be, and other reasons known only to them.

Encryption Only

The earliest ransomware* gangs would only encrypt their victims data and offer the decryption keys when the ransom was paid. But if the victim had current backups then they'd usually perform their own recovery and be on their way. The bad actors wouldn't get paid and their hold over their victim was no more.

These early attempts often did not include exfiltration for a couple of reasons:

1. They didn't really understand the value of the data so didn't bother stealing it.
2. Upload speeds in the early days of ransomware could be pretty slow. It could takes weeks or longer to upload a huge dataset and that might be detected and stopped.

Ransomware groups have since wised-up and upload speeds also became way faster.

Exfiltration Only

That's stealing data, as we discussed above. If all they did was steal data, then the breached organization could probably still carry on their operations while ransom negotiations take place. That is, paying money so the bad guys don't publish the stolen data. That wouldn't be nearly as disruptive.

The threat actors may choose this approach when their victim is a critical provider, such as a hospital where shutting down their systems could quite likely lead to deaths. No need to cause death and suffering when monetary payment is main or only interest the bad guys have.

Both Exfiltration and Encryption

This is a double-whammy where the bad guys both steal data and shutdown systems by encrypting everything. Now the victim is dead in the water and thus more likely to negotiate a ransom. An organization with a well-run I.T. department might be able to recover from a backup fairly quickly, but the threat of publishing the stolen data could still compel them to the ransom negotiating table.

Banning ransom payments?

The cybersecurity world is split on the position of making ransom payments illegal.

One the one hand, it may slow ransomware schemes since getting payment could become more difficult. But unless cryptocurrency itself is outlawed, which is a topic that I'll write about someday, then making ransom payments illegal would not necessarily stop them from being paid. It would simply drive the payments underground.

On the other hand, critical organizations such as hospitals and utilities, could face a crippling outage or even extinction if the payments could not be made.

You might say, too bad they should have had backups in place and should have had better security practices. That's true enough, but it's not always their fault. These customer institutions aren't always the vulnerable point of intrusion (the Canvas hack demonstrated that), but rather the Big Tech cloud-provider on which their systems run. There's little or nothing the customer could have done!

And regardless, allowing them to die (as punishment?) is no answer, either. The collateral damage from their death could hurt far more people through no fault of their own.

What needs to happen is strong effective regulation regarding security practices depending on the particulars and nature of the organization. We actually have some of that today. HIPAA is one you've probably heard of that covers healthcare. Other industries like insurance, finance, etc. have their regulatory bodies as well. Unfortunately they don't encompass everything they need to and thus aren't particularly effective.

Data breaches, where we are today

The sad fact is most of us have already had our personal data breached numerous times. Regarding our data privacy, that ship has sailed and sank in the Mariana Trench as I like to joke.

Over the last 20-ish years when the internet and online systems truly became the way business and government operated, our data has been stored on dozens or even hundreds of databases belonging to as many organizations.

Many of those orgs had no business holding our data in the first place. But, as is usually the case, lawmakers are woefully behind the pace of technology, so protective laws and regulations simply don't happen in a timely manner or, hell, at all.

A lot of those orgs were and continue to be sloppy with their security posture. Cutting costs (and maximizing profit if not a gov't org) is paramount to all of them. Security is expensive and unsexy. And it's invisible, unless a breach happens. So no C-suite suit wants to expend any more time, effort, or money than they can get away with.

The US still doesn't have an EU-like GDPR (General Data Protection Regulation). Not that the GDPR is perfect, mind you. It has flaws. But at least it's something. We can't even manage that little bit over here.

And we, the plebs that occupy this land, are the hapless victims of that sloppiness. It's a human rights crime!

Some things not to do

Don't use services that promise to find and delete your data from the "dark web". They prey on fear and are useless. They might find your data and report where they found it, but so what? Having that knowledge isn't useful. They cannot delete your data held by bad actors so what difference does it make?

You don't need to pay for credit monitoring or Lifelock, either. Lifelock, especially, is an expensive service that doesn't provide meaningful security. Some of the things it advertises are things you can do yourself for free, such as freezing your credit files.

A New Focus

Since most of our private, personal data is already out in the wild, out of our control, then it necessitates a new focus, a new mindset. That means assuming a post-theft security posture and taking steps to make your already-stolen data harder for criminals to monetize. Make it "less actionable".

What does that mean?

That means locking down sensitive aspects of our online lives, such as:

• Use unique 15+ character passwords for every site, no exceptions! Use a password manager like 1Password.
• Compartmentalization: Use separate email accounts for all important sites. This is way easier than you think if you have a Gmail account.
• Freeze your credit with all four, yes four, credit bureaus.
• Add two-factor authentication (2FA) to all your important accounts, preferably using offline methods like an authenticator app, not SMS/text messages.
• Add an IP PIN to your IRS tax file. This is really important. You will use ID.me or Login.gov to do this.
• Add secondary account recovery mechanisms (mobile phone, alternate email address) to your online accounts and delete old, outdated recovery methods.
• Where possible, adding a "customer statement" to an account profile, like your bank, that advises certain verifications. You may have to visit in person.
• Adding a PIN to your mobile carrier account so that no changes can be made, like a number port out or assignment to a new SIM, without that PIN.
• For older people in your life that may have cognitive issues, help them with all the above.

Not gonna lie, some of these steps are a PITA and require a bit of technical savvy to do correctly. I can help you establish a security posture that offers increased resistance to compromise and teach you how to update and maintain that posture going forward. Teach a man to fish. See my home page for contact info.

Please see my relevant articles here:

Security 101

Password Hygiene

Old People and Computers