Insane in the Tech and Cybersecurity Industries

If the definition of insanity is doing the same thing over and over again and expecting a different outcome, then we need to admit that a lot of technology development and a lot of cybersecurity work is absolutely insane.

Before you tell me I'm insane - and let's face it, there's a non-zero chance that I may well be - let me give you just three examples of the kind of insanity I'm talking about. After all, the first step in fixing a problem is admitting there is one in the first place.

Make It Work First, Secure It Second - Wireless Edition

Garage Door Opener Remote Controls

Let's start with garage door openers. Within my lifetime we started with very basic options: generate a tone on the correct frequency and the opener will open. From there we migrated to "fixed code" openers, where not just a tone was sent, but an actual message was sent. Unfortunately this fixed code was highly susceptible to what we now call "replay attacks," effectively recording and replaying the code by a 3rd party solution. (You could also guess the dip-switch settings if you were good...) From there we finally got to "rolling codes," and in some cases encryption as well. Clearly we went from "hey it works!" to "hey, we should probably secure this" over the course of several decades. This, by the way, is a great example of this problem in the "IOT" space, especially now as we are connecting our garage door openers to our networks and the Internet.

WiFi "Security"

But we can also talk about this in terms of WiFi. The first WiFi security protocol was called Wired Equivalent Privacy (WEP), and it was a fairly appropriate name, but not in a good way. If you considered the "air" the physical layer (equivalent to the wire in an Ethernet system) you'd recognize that anybody who had access to that physical layer had access to sniff (and possibly interject) traffic on that system. The actual encryption used was based on a preshared key combined with a weak as all hell cypher: the RC4 cypher, which could be brute forced by a potato, Even worse, there was no concept of a temporal key - or using the preshared key to create a rolling set of keys to use for a short period of time before then changing the key again. Nope, everything was simply encrypted using the PSK and the RC4 cypher. (Like I said, a potato could crack it)

From there we migrated to WiFi Protected Access (WPA). This helped, but it still allowed anyone allowed on the network to see everything on the network, like everyone being in the same broadcast domain and every packet being broadcast, instead of any sort of traffic privacy. Additionally, network authentication could be configured based on RADIUS + 802.1X individual access. That was a huge step forward, but still wasn't great. WPA2 fixed several of those issues, but by this time WiFi had existed for nearly a decade. IT got rid of RC4, and fixed many of the other issues with WPA. By this time it was downright criminal to be running WEP, but that didn't stop legacy systems from doing so. Finally almost 20 years after WiFi was introduced, WPA3 was released to fix the issues with WPA2, including individual encryption for each device on the network, preventing authorized devices from sniffing the traffic due for other devices. However we still allow extremely insecure options, such as hiding the SSID of the network, which actually transfers the authentication issues to the endpoint instead of the infrastructure, which is absolutely bass-ackwards.

I could go on. Wireless phones. Cellular phones. Bluetooth. Car remotes. Each has a history of being deployed with little to no practical security to getting slightly better over time. You might think we could have learned from these things. Bluetooth could have learned from WiFi's mistakes. Car remotes could have learned from garage door opener mistakes.

There Are No New Vulnerabilities Under the Sun

2025 saw a record number of CVEs reported. According to analysis by DeepStrike, here are the top vulnerability types from 2025:

Cross-Site Scripting has been around since 2002: 24 years. SQL Injection attacks first came to the forefront in about 1998: 28 years. The top two vulnerability types are both old enough to drink in this country. These two account for hundreds (thousands?) of the CVEs published in 2025. We know how each of these works. We know how to prevent them. But instead of focusing on repairing old code or preventing these attacks going forward we focus on software functionality and features in new releases, only addressing them after a vulnerability is reported.

Make It Work First, Secure It Second - The Internet in General Edition

HTTP has been around for decades, and only recently has it been effectively forced to HTTPS - the "S" stands for encrypted. I know, in the acronym it means "secure," but really it just means encrypted. OK, it also indicates that the server side is authenticated as being legitimate, but that's only most of the time.

Telnet still exists, per Shodan there are around 280,000 open Telnet servers accessible from the Internet. SSH has been the accepted replacement for it for over a decade, but still the clear-text version exists.

FTP went through several less than terribly secure iterations, including finally fixing the inbound server-to-endpoint connection that was just a nightmare to begin with.

We're still struggling with how to meaningfully secure DNS.

SMTP, the backbone of email, was built assuming people wouldn't pretend to send mail on behalf of anybody else - clearly that was wishful thinking - and efforts to slap security onto it have been less than stellar. We also assumed that "postcard equivalent security" was good enough for email - any system in the path between your mailbox and your recipient's mailbox can read your email as the only encryption in the protocol is at the network level - every server in the chain has plain-text access to the email unless you're using PGP or some other encryption on the message itself.

Yes, the Internet itself was built on the assumption that everyone on it would behave themselves, and only after hard-knocks lessons have we realized our folly.

Then there's the three letter acronym that strikes fear into Blue Teamers everywhere: RDP. Around since 1998, Remote Desktop Protocol has always been a bad idea to expose directly to the Internet, yet a quick Shodan search shows over 2 million RDP servers directly accessible from the Internet - no VPN, no meaningful protection beyond username and password, possibly with MFA.

We Can Do Better!

It has been said that a wise person learns from their mistakes, and that a brilliant person learns from the mistakes of others. If so we're a whole bunch of dunderheads, as we can't seem to learn from any mistakes until we make them over and over again, as I hope you've recognized from the preceding diatribe. So let's break out of this "Pete and Repeat" cycle by putting these simple ideas into our design and production processes:

1. Assume your system will have users on it who have ill intent. They won't ALL be trustworthy saints, they'll be petty humans who do petty human things. Worse, they may be AI agents who are there to do nothing but sow chaos and take data. Design to mitigate those behaviors.
2. If it is worth doing it is worth doing securely from the start. The attitude that we'll "bolt on security" later isn't acceptable any longer. We're still trying to bolt on security to systems that are older than I am, and often the only option is to scrap it and start over, which costs more in the long run - even the short run sometimes.
3. Just because the capabilities to interfere with your system are costly now doesn't mean they'll remain costly. Thinking back to garage door openers: if tools like software defined radios and the Flipper Zero existed in the 1970's remote control garage door openers might have not seen widespread adoption for years, until rolling codes and other security capabilities were rolled out.
4. Test thoroughly! Don't just test "did it work," use-cases, test "did it resist being misused" use cases!

I know, that makes it seem like development time will be longer, and perhaps it will. But when you stop to consider the cost of trying to fix all those security issues later, including the cost of straight-up replacement of hardware, this seems like an easy calculation, doesn't it?