The War You're Not Hearing About

Putin's war is getting plenty of attention, but cyber-war, or the cyber-battle within the bigger war, is not. It is hidden from most of us, but it is heating up. It is a battle Putin might win. If you are a coder or if you employ coders, there are patriotic things you can do.

Changing your passwords, the standard advice, is akin to ducking when shot at - undeniably sensible, but probably too late, and insufficient as combat training. Comprehensive security training for every coder would be better, but unrealistic. Perhaps a few dozen mathematicians truly understand modern cryptography. Perhaps tens of thousands of others can assist, mostly because they know their own limits. But there are millions of coders who know enough to get us in trouble, but can't get us out.

I cannot say I truly understand, but I can recognize those who know even less than I do. Password strength meters, for instance, scream incompetence. Yes, they have some basis in over-simplified math, but are worse than useless when they give "P@ssw0rd" a passing grade. Hackers aren't that stupid. Can't say the same for all the coders I've met.

A good password has to be random, something humans are bad at creating and can't remember. Humans need help from a password vault app or a third-party authenticator, such as Google's. Apps or centralized services are good, and coders should ditch the strength meter and use them, but in times of war, they become obvious targets. I trust Google has done a good job, but the cost of a mistake is huge.

To use Google's good work, coders need to understand the difference between authentication and authorization. In the recent past, almost everyone did both as if they were the same thing. It doesn't help that many software libraries abbreviate both to "auth".

Think of authentication as your nation's passport office, which takes pains and plenty of time to ensure that you are who you say you are. Authorization is a different job done relatively quickly by others - the border agents in countries you try to enter. A passport does not allow you to go where you want. Agents are expected to judge your behavior, independently check your story, and can send you back or throw you in jail. Google can issue a digital passport - but individual coders have a duty to program more than just a glance at it.

But your website is just selling simple inexpensive widgets, so surely you can do well enough. Before you sleep soundly though, consider the following scenario.

In downtown Calgary there are numerous head offices of energy companies, and energy is critical in the war. Those skyscrapers look imposing to me, and I probably can't break in. I trust the same is true of their information system. Rather than trying to break in, I would rather go golfing.

Specifically, I would create or hack into a golf tee time site. Many executives play golf, and I can count on some of them using the same password for the golf site and their workplace. That's enough for a hack. To fight back, the executives need security training, and their workplace system can always use a security review, but the golf site needs proper security too.

That may not be a realistic scenario. I bet no one is trying to break into a Calgary golf site. Rather, they are trying to break into every Calgary site. Furthermore, they aren't people, they are machines that don't waste time choosing worthwhile targets - everything is a target. Even if there are no passwords or sensitive information on a small site, the processing power of the server it is running on might be useful as part of a coordinated attack on another site.

Today's most concerning hacks take a similar convoluted path to their target, and coders and executives need to hear about them.

Coders have always used existing code when they can. Why re-invent the wheel? Nowadays, coders routinely browse enormous libraries of free and for-sale code - Github, npm, and WordPress plugins, for example. I recently grabbed a "color picker" for my app - it took about 30 seconds to achieve what would otherwise take a week, it was free, and it looks great. A color picker has nothing to do with security, and I am competing with other coders for business, so it's a no-brainer. I did not look at the color picker's code.

But "log4j" gives me pause. This is a very popular Java component which logs anything a coder might want to record - to ensure the code is operating properly, to track usage, or to record hacking attempts, for example. It seems innocuous, super handy, and priced right. Until a bug was found that could be exploited to take complete control of the program it is a small part of. Reaction was swift - patches were issued and applied to programs around the world. I bet there are many sites that have not been patched - golf sites for example.

The log4j exploit bug was probably accidental, but similar examples are showing up that look deliberate. No particular site is targeted, rather, every site and system is a target.

Coders can fight back, but need training and time they can dedicate to non-flashy security issues. Executives in organizations large and small need to take security seriously. Cyber-war needs to be reported as one battle in the current war. Battle tactics are changing, and coders and their bosses need to know the latest news.

Securing systems big and small needs to be seen as a patriotic duty.