Security Failures Throughout History: Learning From the Past

“Those who cannot remember the past are condemned to repeat it.”
—George Santayana, The Life of Reason

History shows that successful attacks often exploit the weakest link. This was as true for ancient stone fortresses as it is for today’ s “data castles” in the cloud. The tactics behind some of the world’s most historic security breaches are still in play in today’s digital age. Even a quick look at the themes they represent can generate insights on how to help you protect yourself—and your data.

The Trojan Horse — c. 1190 BCE

As the apocryphal tale goes, after a fruitless 10-year siege at the walled city of Troy, Agamemnon’s Greek army devised a cunning plan to get inside. They retreated, leaving only a massive wooden horse behind. Taking it for a gift or tribute, the Trojans wheeled their prize into the city. When night fell, the Greek soldiers hidden inside the horse slipped out and opened the city gates, allowing their waiting comrades to rush in and wreak havoc.

SECURITY LESSON: Always validate your input — you never know what might be hiding in the horse.

The XML code below, which might be sent to an API, is a modern-day Trojan horse. Hidden inside it is a Denial of Service (DDoS) attack.

This code contains a bunch of entity statements—macros that expand. Older XML Parsers would identify the code snippet <lolz>&lol9;</lolz> as an entity that must be expanded. The parser will look for the definition above, see that it should be &lol8, and replace it below.

But these, too, are entities. The parser will look above, see the definition, and then replace it will a string of &lol7s, then &lol6s, then &lol5s, and so on. In other words, this 1KB piece of XML will expand to occupy almost 3GB—enough to crash almost any XML parser or application server.

Most modern parsers know to defend against this type of attack. But there are many other situations—SQL injection attacks, cross-site scripting, command line injection—in which failing to validate the input you’re accepting into applications can cause serious problems.

Thermopylae Pass — 480 BCE

In a battle popularized in the graphic novel and movie 300, after a long series of battles, the 7,000-strong Greek army faced more than 100,000 Persians soldiers. Even though they were vastly outnumbered, the Greeks were able to hold the Persians back in the narrow Thermopylae Pass. Unfortunately for the Greeks, however, the Persians eventually learned of a second secret path through the mountains, which they used to launch a sneak attack from the rear.

SECURITY LESSON: “Security through obscurity” isn’t good enough. Counting on attackers to not learn your secrets is not a winning security strategy.

Take routers, for example. Most have an administrative page protected by username and password. But in one puzzling case, one major router company created an obscure secret string that when sent to the router, opened a backdoor—no username or password required. As soon as one person discovered this secret, however, all owners of this router were at risk.

Equally ill-advised is hardcoding passwords into your code, or creating your own encryption algorithms. Both represent “security through obscurity,” and once an attacker sees your code and discovers your secrets, all bets are off.

Castle Galliard in Normandy, France — 1204 AD

When King Philip of France decided to win Normandy back from his English rival, his army attacked the key English defense of Castle Galliard. The castle fortifications were incredibly strong and withstood a six-month siege. However, at some point the French soldiers discovered a toilet chute in the castle’s inner wall and were able to climb up through it. Once inside, they flung open the castle gates—and the rest is history.

SECURITY LESSON: One weak link, no matter how small, can undermine all your strength. If your attackers can find it, they will exploit it.

For example, when Apple’s iCloud suffered a breach despite Brute Force Protection and 2-Factor Authentication, it was discovered that an overlooked back-up API had given the attackers a way in. 

Maginot Line, France — 1940

After World War I, the Treaty of Versailles called for 450 miles of France’s borders with Germany, Switzerland, and Luxembourg to be fortified. But in 1940, Hitler’s army mounted its devastating blitzkrieg attack on France via Belgium, avoiding the fortifications entirely. Advancing in armored tanks at never-before-seen speeds, the Germans rendered the Maginot Line meaningless.

SECURITY LESSON: Attackers are constantly evolving and improving; make sure you evolve with them.

Technology has its own versions of the Maginot Line: passwords, antivirus software, scanning and patching for vulnerabilities, firewalls. These are crucial security tools, but they become vulnerable when you operate them according to what attackers have tried in the past. You must focus instead on new kinds of attacks, and on developing more advanced security methods (such as multifactor authentication, behavioral monitoring, and self-defending applications) to defend against whatever your attackers might try next.

Venona Project, Virginia — 1946

After World War II, American relations with the Soviet Union were strained. Intercepting encoded transmissions between Soviet operatives, the U.S. suspected espionage, and set up the Venona Project to prove it. But the code was seemingly unbreakable—until the Soviets became careless in distributing the “one-time pads” they used to encrypt their missives. Soon enough, the code was cracked and the spies were rounded up.

SECURITY LESSON: Your encryption methods are only as strong as your implementation of them.

Rolling your own encryption and authentication is extremely risky — as Silk Road found in 2013. The Dark Web marketplace appeared impenetrable to authorities, until Silk Road’s own captcha system was exploited by the FBI. As a result, federal agents were able to locate servers and identify users, beginning the process of shutting Silk Road down.

9/11, New York City and The Pentagon — 2001

The terrorist attacks that felled the Twin Towers left everyone asking the same question: How did this happen? A bipartisan commission was set up to find the answers. “The most important failure,” the commission declared, “was one of imagination.” In other words, the warning signs were there. But we failed to understand the scale of the threat and failed to act.

SECURITY LESSON: Be proactive, not reactive. If you see evidence of a potential attack, take the necessary steps before it’s too late.

Enterprises face threats from a variety of attackers, from “script kiddies” looking for low-hanging fruit to organized criminals out to get a return on their investment. Meanwhile, politically motivated hacktivists are often happy to cause disruption of any kind. And the unlimited resources of nation states engaged in cyber-espionage makes them a formidable threat.

But significant attacks from any of these sources are usually preceded by subtle indications of what’s to come. Your job is to spot those indications—and act. 

Hawaii Cryptologic Center — 2013

Edward Snowden joined the NSA’s Hawaiian branch in 2012, as an “administrative contractor” or an “infrastructure analyst,” depending on whom you ask. Either way, the famous whistleblower had access to vast quantities of data — far more than he needed to do his job. What he did with that data made him a household name, not to mention a fugitive. The NSA’s reputation is still recovering.

SECURITY LESSON: No matter how much you trust your employees, limit their access to data. The golden rule: “no more and no less than you need to do your job.”

Even small companies with tight-knit, trusted teams are vulnerable to things like phishing and malware. In other words, even good guys can get hacked. And as your business grows, statistically speaking your chances of employing a “bad actor” increase.

Limit the access, limit the damage.