Security, convenience, and shiny toys.

Let's talk about reasonably secure options and why they are the road less traveled.

People love their shiny new phones and last-generation computers running the latest niceties. They adore the latest, fully featured software and frictionless new tech. The problem is that it's tough, or better yet, downright impossible, to secure fat systems with millions of lines of code aiming to provide every possible feature to consumers. It is much easier to make simpler systems reasonably bug-ridden and secure.

Welcome to the wild, wild west!

It pains me to say that the software industry is still in its infancy after half a century of mass-market-driven choices. I sound like a broken record since I have been repeating the reason behind that observation for my entire professional life. Software publishers can ship whatever they want without legal liability for how buggy and insecure their product is. People want more features and functionality, and that is what they sell. Security is an afterthought, handled if and when it becomes problematic and inconvenient.

In the corporate world, regardless of how often they tell you otherwise, the same trends are followed with slightly different flavors of stupidity. The “professional editions” add more features to the software, not a more spartan and guaranteed less vulnerable version of their mass-market aimed for hobbyist counterparts. I don't even know what the “pro” label means in the software market...

Corporate computers are usually the consumer versions of the software with managed restrictions (some control masked as “advanced features”) on top in a vain effort to mitigate the most apparently dangerous user behavior. For example, the users cannot install additional software; password changes are mandatory, and I.T. enforces upgrade cycles.

Market maturity means legislation making software companies liable for the quality of their products. The same happened in other industries as markets matured. For example, can you imagine a world where cars and airplanes did not meet minimum security and reliability standards? Well, in the software world, we are still living in a new frontier, the wild west, as far as law enforcement goes.

Bad ideas are hard to kill; embrace them!

Can you keep a secret? Really? Can you?

It's hard to keep a secret. It's not a matter of people realizing the importance of not sharing confidential information, like their credentials, on corporate servers; they understand they are supposed to do it. The problem is that they can be tricked or coerced into giving them away.

How many of you would keep your phone/computer passcode secret under the threat of violence? It's tough to argue the merits of risking physical integrity in the name of a company's information security. However, a hammer and your two knees are an unbeatable combo making your silence and loyalty to a corporation a tough sell.

Judging by their actions, corporations do not care much about messaging security. The technology to digitally sign and encrypt communications has been available for years, yet email in the corporate world mostly does not use it. As a result, phishing scams and identity theft exist because no one seems to have them identified as severe problems worth a few lines/clicks configuring profiles and issuing certificates for every email user.

Is it reasonable to expect users not to be tricked into revealing their secrets in a world where user credulity is used instead of cryptography-identified identities? It's a rhetorical question with an obvious answer.

The best way to protect users from hiding corporate secrets is to provide them with none. Instead, you can authenticate connections using asymmetrical encryption and challenge-response dialogs using USB security keys that cost a dozen dollars rendering phones/computers useless without them as authentication methods. In addition, biometric reading devices have been available for decades, and you can ensure only a live individual can even use the authentication devices.

The tools needed to spare users the burden of keeping secrets are known and have been available for years. For example, geolocation and synchronized clocks are not rocket science, and you can limit the power of authentication tokens by limiting their use when an abnormal pattern is detected. For example, users are not likely to travel at light speed or be in two locations simultaneously. In addition, you can (and should) restrict privileges based on regular usage patterns. For example, you can render an authentication match null and void in the wrong location or off-the-clock times.

Passwords and shared secrets (used for second-factor time-based authentication codes o HOTP and TOPT) are terrible ideas. Spreading “secret keys” in both the systems and user end is an accident waiting to happen. While it's rather apparent that on the user end, the protocol designers expected the authentication devices not to be used to authenticate their connections, unfortunately, that is not what happens in the real world. In many ways, this secondary authentication approach is even more fragile than the primary authentication method. We can do much better.

Google and Yubico created FIDO U2F and support from NXP, with the vision to take strong public key cryptography to the mass market. As a result, large-scale services, including Facebook, Gmail, Dropbox, and GitHub, have successfully deployed U2F. The next evolution of the FIDO U2F modern authentication protocol is FIDO2, which introduces passwordless authentication capabilities.

Add biometric, time, and location-based restrictions to access the security enclave where private keys are stored, and you will effectively protect users from a myriad of problems and risks.

Since many systems will not support decent solutions, use a password manager. If you must use a fragile authentication solution, at least do it as well as possible. I like Bitwarden.

Do yourself a favor and go buy a pair of hardware security keys! Make sure you pick one that supports FIDO2 (because that is what you want to use on any site that provides the best option available today). I use Yubico keys.

Please avoid using the same device to store primary and secondary authentication secrets (that is why I recommend using security keys). While you can do a lot to make your devices safer, most people reading this are clueless on security beyond “I probably need some sort of firewall, anti-vírus, and should be careful about clicking on email links and attachments”.

The latest shiny new and trendy device will always be a user favorite!

Did I tell you that keeping fat, feature-rich, general-purpose systems secure is really hard? It is. You cannot do it. Ensuring an acceptable level of security in general-purpose products like MacOS and Windows is downright impossible, so use both operating systems for what they are: insecure machines for general-purpose usage. Control and sanitize the output of work done on such systems and ensure they cannot access sensitive information or perform critical operations.

While Windows and MacOS can be locked down to a level where the ease of use and versatility that makes them user favorites is no longer there – both operating systems can be stripped of bloatware beyond recognition for a specific use case. Still, you will likely end up with a universally hated Frankenstein setup that is borderline unusable.

The same goes for iPhones and Android devices; they are great mobile computing platforms people love and are awful second-factor authentication devices. Like their bigger laptop or desktop counterparts, they are general-purpose devices running bloated and insecure operating systems. What you want in a device that stores secrets is the opposite of accessing random sites, insecure emails, receiving an SMS and installing apps. If you want the user to carry a single phone, at the very least, provide them with a security key that stores and uses private keys; it's already a bad idea, so don't make it even worse.

Mission-critical operations should happen on secured systems unable to run non-signed binaries with minimal connectivity according to their purpose. Authentication should be decoupled from the system and require human intervention, like touching a Hardware key and passing a biometric test on a security enclave (system on a chip).

Secure systems are synonymous with minimalistic installations, only the necessary software to fulfill their mission, and nothing else. Top-of-the-line hardware is cheap when compared to the cost of risking not isolating and securing systems.

I like the “reasonably secure Qubes OS” approach, implementing a security-by-compartmentalization using virtualization technology. Cubes OS isolates programs and sandbox many system-level components, such as networking and storage subsystems, so that the compromise of any of these programs does not affect the integrity of the rest of the system. Furthermore, virtual machines are not persistent and revert to a known secured state between uses.

Critical-mission users need separate devices. Unfortunately, there is no way to avoid it. However, these users are usually a tiny percentage of a company's workforce. For most employees, the focus should be on zero trusting the toolset and ensuring control over what they can access and share.

Security is a balance between letting users use whatever tools they need to perform the job efficiently and limiting the potential damage they can inadvertently cause. Unfortunately, it is not easy to achieve the perfect balance. But on the other hand, that is why I.T. exists in organizations. So be glad you have the job, and while you are at it, do it.

Microsoft Office scripting language and macro support

I would love to meet the people that thought running scripting languages in Office documents was a good idea! It sure enables a ton of otherwise impossible options for ill-prepared software engineering. But unfortunately, while I am a proponent of letting people use the best productivity tools they can find, we should limit the number of bad options allowed in a corporate setting.

While running alternative safer Office-like packages with fewer “features” is the easy way out of many headaches, there are ways to enable power users instead of shutting them down. Office applications and data should only run in chrooted (isolated) environments with strict per-document and toolset limitations. Running them online is not the worst possible approach.

I have been managing I.T. for the better part of 30 years. During that time, I saw fantastic stuff created by power users with Microsoft Office tools that delivered great value to companies. While a whole lot of risk and (security) issues come with some (let's call it) creative approaches, the solution is to find ways to accommodate those “solutions”. They even existed because conventional systems to solve a particular problem were unavailable. So I hired the individuals behind some of those insane projects.