Cybersecurity requires ongoing focus, dedication, and a willingness to revise our behaviours regularly, based on good science rather than merely on popular anecdotes.
Don’t copy everything that everyone else is doing in the hope that some of it will work for you, because there are plenty of security “precautions” out there that simply don’t provide the protection they promise.
Cybersecurity is hard.
Not because the crooks are smarter than us (often they are not), and not because all software is awash in uncontrollable bugs (some of it is not).
And not even because many of today’s security products and services have become bigger and twitchier than ever (there are notable human-centric exceptions to this trend, of course!), with terrible signal-to-noise ratios that make them harder and harder to use, not easier.
Cybersecurity is hard because it requires ongoing focus, dedication, and a willingness to revise our behaviours regularly, based on good science rather than merely on popular anecdotes.
Indeed, one notable problem faced by cybersecurity teachers is that quick fixes and accidental security tricks sometimes get written into our collective cybersecurity wisdom as though they provide reliable long-term protection.
Undoing our inadvertent commitment to what I like to describe as security by accident can sometimes be the hardest part of all.
It’s vital to be able to identify security by design, where we adopt cybersecurity precautions on the basis that they can be shown to work reliably.
And it’s equally vital to recognise security by accident, lest we end up with little more than a collection of talismanic protections that don’t deliver the results we’re hoping for.
Even security measures that apparently do no harm can work to our disadvantage if we fail to see their limitations, if only because they use up time and effort that would be better spent doing things that actually worked.
With this in mind, you probably won’t be surprised to find that lots of cybersecurity “precautions” that arise by accident become popular because they sound good, and are easier, quicker and cheaper than doing things properly.
And in a world where some cybersecurity companies are happy to flood us with new product variations that they insist we need to keep buying, learning, deploying, and maintaining along with the ones we’ve already got, apparently to make up for the deficiencies in the products they sold us last time with promises such as “set-and-forget” and “now with future-proof AI automation”…
…you can see why security by accident often feels like, well, a happy accident for confused customers.
In case you’re wondering, the reason I’m writing about this topic right now is that last week I just happened to mention the problem of accidental security in passing, in the context of home routers and their default way of managing your network connection.
In response to that article, someone asked me, “Can you write more about this? I’d love to see some examples of how and why we got sucked into relying on accidental security that turned out to be nothing more than words,” which is a great way of describing the problem.
The answer to that question is, “Yes, I can!”
So, let’s start by briefly revisiting my security-by-accident example from last week, which I introduced as a way of explaining why criminals typically target your web server differently from how they set about attacking your laptop, which is probably immune to inbound network probes even if you didn’t knowingly set out to protect it from them.
Back in the late 1990s and early 2000s, lots of online users still dialed up using a dedicated modem that hooked up their computer, and only their computer, to the internet.
Sharing your connection was rare, because modems were barely quick enough for one computer at a time, given that a fast dialup connection might run at just 56 kilobits bits per second if it hadn’t rained recently, which is about 1000 times slower than a typical entry-level internet connection today.
Because of the direct-to-the-network connection, however, modem users often ended up with a public-facing network address that could be reached, probed and attacked by ne’er-do-wells out there, without any sort of router in the way.
When the infamous SQL Slammer network worm hit in early 2003, many home users were amazed to find themselves part of the infection cycle, despite the name of the worm suggesting that this was a server-only problem.
Those users discovered rather too late that that their computers were not only capable of accepting incoming network connections, just like a server, whenever they were dialed up, but also had a Microsoft SQL server listening out for TCP connections on port 1433, making them infectable by the Slammer malware.
(Home users didn’t really have a full-blown Microsoft SQL instance fired up, of course, but anyone who had installed software that included the freely redistributable Microsoft Server Desktop Engine, or MSDE, unknowingly had a stripped-down version of SQL running that just happened to be compatible with the worm.)
In contrast, homes and businesses that had moved beyond dialup were usually hooked up to the internet via a single cable plugged into a router that shared that single connection between all the users and devices in their local network.
To this day, most home routers automatically suppress all inbound connection requests simply because they have no idea which computer inside your network would be the right one to deal with the connection.
If it’s someone trying to send you an email or browse to a web page, for example, the router doesn’t know whether you even have a mail server or a website, let alone which computer it would be running on.
This traffic management trick is known as NAT, short for network address translation, because all your outbound requests are rewritten as if they originated from your router, and the happy outcome of NAT is that incoming connections go nowhere by default, which just happens to have some security benefits.
For example, even though users with home routers were often affected by SQL Slammer because of the disruptive volume of traffic it generated, the infectious network packets generally bounced off their router and stayed away from any at-risk computers inside the household, with the result that they weren’t infected, unlike their less fortunate friends still using dialup.
Some of those users understandably assumed that they had stayed safe because of their prescience in switching from dialup to an always-on connection, as though they had made an informed cybersecurity choice, when in fact they had just wanted a faster connection.
This is a great example of security by accident, rather than security by design, because NAT was really conjured up to make network addresses go further, and to sidestep the need to give every internet-connected device its own network number, not to keep viruses out.
So-called IPv4 network addresses, still the most widely-used form of network numbering today, are encoded as 32-bit numbers, so they can’t uniquely identify more than 232 devices, because there are only that many different combinations of binary digits possible in 32 bits, in the same way that four decimal digits can’t go past 9999 without wrapping around back to 0000.
(IPv6 aims to solve this problem by using 128-bit numbers to encode its network addresses, but current statistics suggest that close to 60% of the computers on the internet are still using the old-school IPv4 system with its 32-bit network addresses.)
NAT was really just a handy solution to stop IPv4 numbers running out.
Nevertheless, for many years we heard people describing NAT as “acting as a firewall all on its own”, as though it shielded you by design from network malware and therefore meant that you didn’t need to take any other precautions to go along with it.
The solution that cybercriminals almost immediately found to this NAT connection roadblock was to switch to so-called bots, also known as zombie malware, malevolent code that works by actively connecting outwards and downloading rogue commands, instead of waiting passively for those commands to be sent inwards.
Given that home routers with NAT made it very much easier for entire households to get online at the same time, you could say that from a security by design viewpoint, NAT actually made our collective resilience to cybercriminals worse.
Home routers exposed more people to cybercriminality on a permanent basis than had ever been possible in the dialup world, and even though many routers today include basic firewall technology that really is supposed to protect you, the story that “NAT will save you from the net” was simply not true.
Another fascinating example of security by accident, or perhaps security by one-off good fortune, arose when mass-mailing email viruses first showed up and spammed themselves around the world, causing internet outages and email blockages because of their network traffic alone, even before any deliberately programmed damage was taken into account.
Infamous and long-remembered virus outbreaks from this era include Melissa, which spread in Microsoft Word files, and the Love Bug or ILOVEYOU virus, which travelled in the form of harmless-looking email attachments that were actually Visual Basic Script (VBS) malware in disguise.
Most of these viruses were shoddily programmed, not least because the malware authors weren’t planning on providing technical support, and only needed code that would work more often than it failed in order to achieve the notoriety they seemed to crave.
Some script viruses cut coding corners by taking no account at all of any errors that might trip up the software at run time and would therefore crash entirely at the first sign of anything unusual.
After all, a mass-mailing worm that loops through your address book sending itself to innocent victims but gets only partway through the list each time is more than dangerous enough to create a fast-spreading virus outbreak.
Some malware authors, it turned out, were perfectly content with that.
Word therefore quickly spread (no pun intended) that deliberately adding an invalid email address right at the alphabetical start of your address book, belonging to a made-up user such as 00AARDVARK
, would protect you from mass-mailing viruses because it would trick the malware into crashing before it had sent a single malicious message.
This suggestion was dangerous in many ways, even though it just happened to provide a modest amount of protection against a modest number of the mass-mailing viruses that flooded the internet at the time.
It didn’t protect you from any damage the malicious code might do before it started emailing; it didn’t do anything to stop viruses that copied themselves around your network as well as emailing themselves to the outside; it didn’t stop you directly mailing out infected files to your friends and colleagues by mistake; and any malware coded with error handling even of the most basic sort (again, no pun intended) would be undeterred by this sort of “security precaution”.
Even just adding the script command On Error Resume Next
, which caused both Office macros and VBS scripts to sidestep run-time errors and to keep on going no matter what, was often enough to convert a tame malware sample that could be fooled by your imaginary friend 00AARDVARK
into a virulent worm that would not.
This address book manipulation was therefore security by accident that worked for occasional malware infections, but distracted users from taking more purposeful overall precautions against the real cybersecurity risks they faced.
Yet I can recall seeing this “advice” still being trotted out as a genuine precaution more than ten years after it had first been roundly and widely debunked.
Simply put, workarounds based on emergency or temporary advice that might just help against an individual cyberattack are almost always security by accident, and very rarely turn into security by design.
One-off cybersecurity tricks are fine in an emergency, provided that you keep in mind that they’re one-offs and therefore prevent them from working their way onto your long-term list of must-take precautions.
Why not choose a managed service that will choose and run the tools you need so that you don’t have to, that will act promptly on the alerts that actually matter, and that will interpret those alerts into actionable advice that works for your business and your staff?
Why not use a trusted service provider with the experience to pick out the tell-tale signs that really matter?
Why not work with a cybersecurity partner that understands the human side of security and will teach you how to do security by design so that you can change your business workflow and IT behaviours to protect yourself properly.
Don’t copy everything that everyone else is doing in the hope that some of it will work for you, because it may just work against you instead.
Cybersecurity is hard, but it’s not impossible, especially if you join forces with someone who specialises in it.
Free yourself up to focus on what makes your business special, which probably isn’t turning your company into a 24/7 cybersecurity response team!
PS. If there are any knotty topics you’re keen to see us cover, from malware analysis and exploit explanation all the way to cryptographic correctness and secure coding, please let us know. DM us on social media, or email the writing team directly at amos@solcyber.com.
More About Duck
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!