Before we Start with why

I wanted to start with the most important question you should ask yourself. But then within about 12 hours of my announcement to start this series, a (sponsored) news-article hit my news-stream with a familiar "Credentials are the #1 attack vector in 2024". A statement that I'ld fully agree with. So let's start off with two simple, but incredibly effective security controls. All the fancy IPS, SAST, DAST, Endpoint protection, Zero-trust and advanced AI-powered magic security solutions will come later.

Oh, also the article used a healthy dose of FUD (fear, uncertainty and doubt) to try and scare you into their product presentation: "drained bank accounts, stolen identities, company's reputation in tatters". I really hate using FUD in security. It's too easy and not effective. But they did list a convenient truth: "stolen passwords, not exotic malware or zero-day exploits, are the most common way hackers breach systems" I'll surely address FUD (and panic) in a later post, but for now let's first address these easy security controls.

Strong authentication

What do I mean with strong authentication? We'll skip the server-side for now, that's a whole other rather technical story I could tell (feel free to ask about it). Let's just concentrate on what users can do. This includes both private and business users of software like Windows, Max OSX, Office 365, Google, Facebook, Twitter / X, Gitlab / Github, Slack, VPN etc.

When you login to a system, you identify yourself with a username, claiming to be a specific person or system. Then you authenticate or prove your identity, most often with a password. The system then authorises you, giving you access to specific data and functionality. Most systems allow users, even anonymous users, to see other user's usernames. So all you need to figure out to successfully be that person is its password, so you can prove your (false) identity.

That's where all the proven attacks come in: credential stuffing and spraying, brute-force attacks using common words, phrases and commonly used or leaked passwords. With ever-increasing compute power comes faster (offline) password cracking. And with easy access to data-dumps come heaps of leaked user-pass combinations ready to buy and try for pennies. And the fun thing: L.U.R.P. (not L.A.R.P. ) beats all of them. Long, unique, random passwords still are incredibly effective against all of those attacks. Trust me, I did the math .

Want more protection? Go for MFA. In fact: go for MFA whenever you have the option. Preferably go for hardware keys if you have one, choose a smart-phone MFA app for almost the same super-secure MFA. Do make sure you have a backup MFA method available if you lose access to your primary MFA. And if only SMS is available, by all means, use SMS if you have to.

Update software

A bug is just a bug, until it's abused. Security bugs or vulnerabilities are not really special. They're issues in software code that cause unintended behaviour. They should be reviewed, prioritised and fixed accordingly. Software users see these whenever a patch or update is released for their operating system, applications, devices or appliances. It's pretty important to install updates as soon as possible, because attackers also review them, try to reverse them and figure out what issues they resolve. If they do, they can figure out how to exploit those bugs on unpatched machines. That's why Microsoft has a scheduled patch Tuesday. But sometimes emergency patches are released out-of-schedule. This most often occurs when a vulnerability is actively exploited in the wild. Darknet Diaries episode 57 called MS08-067 dives deep into bug and patch lifecycles. It also emphasises the importance of installing patches as soon as possible, because a lot of attacks occur with already patched vulnerabilities. Here are two examples:

Apache Struts / Equifax

CVE-2017-5638 with the maximum CVSS score of 10.0 was discovered on March 6th of 2017 and fixed within a day. However Equifax, a large creditcard company failed to update their systems with the patch and was attacked more than two months after the patch was released.

EternalBlue / WannaCry

NSA discovered CVE-2017-0144 and reported it to Microsoft after it was actively exploited in the wild in early 2017. Microsoft released an out-of-schedule patch for supported Windows versions on March 14 and about 2 months after, the WannaCry attack spread worldwide. This forced Microsoft to release patches for many unsupported Windows versions as well a day after. But adoption was slow, with still millions of unpatched systems in december 2018, about 800k systems in 2019 and still even 600k unpatched in 2020.

Opensource

A number of high-profile vulnerabilities have come from widely used opensource projects. From OpenSSL's Heartbleed to Log4Shell and recent XZUtils . Whenever a widely used opensource component is attacked, it's like the internet is on fire. A fair question could be: is opensource software then inherently less safe than closed source? The attackers can literally peek under the hood and find what they're looking for, right? I have a number of arguments against that question though.

Log4Shell was a zeroday

Technically the Log4Shell bug at the end of 2021 was already actively exploited in the wild before it was discovered to the maintainers. That's why it spread so quickly. This happens just as well happen to closed source software. That is often a reason to issue an emergency patch, out of schedule. To be fair, Log4J's maintainers issued an initial patch (2.15.0) within a day to address the issue and followed up with three more patches (2.16.0 through 2.17.1) when similar bugs and workarounds to the patches were discovered. Remarkably quick for no pay and a lot of dirt the volunteer maintainers had to endure.

Budget

Which brings me to my second point: with literally no pay, can you really expect maintainers of a free opensource product to spend money they don't have on expensive security audits, while the rest of the internet freely uses their product? Wouldn't it be fairer to spend some of your software licensing budget on security auditing the opensource projects you use and create the pull requests to patch findings yourself? And if you really don't want to spend any effort, why not throw 10% of your licensing budget to the top most used opensource projects as a sponsor? If 10% of the companies using opensource software would to that, I'm sure the internet will never be on fire again.

Kerckhoff's Principle

And finally, the Kerckhoff's Principle. This principle relates to cryptosystems and states that a system should be secure, even if everything about the system is known, including its code, architecture or algorithm, except for the decryption key. The opposite of Kerckhoff's Principle is Security through Obscurity, which basically is "the key under the doormat". If the attackers don't know where to find the key, then it's okay. But as soon as they figure out the trick, it's game over for basically all locks.

Translating this principle to software, I compare opensource software to cryptographic algorithms where it is common practice to peer-review them thoroughly by every expert possible. That's why all (respectable) cryptographic algorithms are opensource. In fact, the moment I see "patented encryption technology", my brain translates it to "snake oil", because no one is allowed to peer-review it.

And with that, I'll wrap up my first of probably many, many blogs on secure software development. Feel free to respond, correct, append, confirm or simply share this blog and let me know what I should write about for you. I've got plenty of subjects to write about, but I'll surely find a spot to add your request in.