Last year, we wrote about ‘security’ blogs and websites that actually cause insecurity. This time, we look at three reasons for a false sense of security.
Always stay in the loop!
Subscribe to our RSS/Atom feeds.
Three reasons for a false sense of security
Oftentimes, private users are focused on “secure configuration”. They ask whether their setup, tool, or hardware is “secure”. We discussed this in “What is ‘secure’?”. Their mindset seems to be like shown in the picture below: There is a toggle switch somewhere, and you just have to turn on some security and privacy.
The main reason for this mindset could be the omnipresent focus on technology when it comes to information security. However, as discussed in other articles, technology is only a small subset of information security.
In the following, we present three reasons for a false sense of security when it comes to configuring technology to make it “more secure”.
Reason 1: Legacy configuration and outdated security tips
If you look for “hardening guides” or “secure configuration” on the internet, you find hundreds of blog articles, online assessment tools, and recommendations.
What is the problem?
Guides and recommendations are snapshots in time. The next software update could remove parameters that were recommended, or good practices change since there are new cryptographic algorithms available. This means that you configure something as written in a guide, however, you don’t improve anything in reality. You think that something is more secure now, but this is wrong.
- Legacy HTTP response headers: Many guides recommend setting the HTTP response headers “X-Frame-Options” and “X-Xss-Protection”. There are even some bloggers who tell you that their blog is more secure since they set these headers. In reality, all major browsers don’t support “X-Xss-Protection”. Web browsers simply ignore the header. You don’t get any additional security by setting this header. “X-Frame-Options” can be set as a directive of the Content Security Policy (Level 2), which is supported by all modern web browsers.
- Contradictory TLS recommendations: Some blogs still recommend TLS 1.0 to 1.2. Others updated their recommendation to TLS 1.2 only. Then, there are already blogs recommending TLS 1.2 and 1.3. If you look at TLS curves, some recommend “prime256v1” and “secp384r1”. Others tell you to use “secp521r1” or “X25519”. Looking at cipher suites, this gets even more complicated. If you compare these recommendations with current good practices and look at parameters that are actually supported by web browsers, you see that some recommendations are outdated or unsupported.
- Legacy OpenSSH parameters: Some tools still recommend to set parameters like “Protocol”. In reality, these parameters aren’t supported anymore by current versions of OpenSSH. The same is true for the “-o” flag when generating private keys.
How to solve it
A good approach is to actually read documentation of things you want to configure. For instance, read
man ssh to see parameters that are supported by your OpenSSH version. Then, some tools come with built-in checks for their configuration. For example, use
nginx -t, or
apachectl -t to check server-side configuration. In some cases, these checks show which parameters are in use. Remove any unused parameters.
Be aware of parameters you configure. Understand their meaning. Don’t blindly set any parameters. Furthermore, it is important to define your own threat model.
Reason 2: No threat model
Some people aimlessly implement tips from the internet. They configure their Android smartphone according to some guides, then they harden their desktop operating system a little bit, and finally they install some web browser plugins. In the end, they changed something without ever checking whether their setup covers their use cases.
What is the problem?
Different people have different hardware, software and use cases. For instance, some people only use Apple devices. Others only have an Android smartphone. Some people use their devices for entertainment only, others use them at work. However, the vast majority of guides only reflect particular use cases of their authors. There may be relevant use cases that aren’t covered by guides. The obvious problem is that you forget something, because no guide reflects exactly your combination of hardware, software and use cases.
- Out-of-scope use cases: You look for a guide that covers server hardening. You implement every part of it, however, the guide covers configuration for static content only while you use a content management system. You are convinced that everything is secure now, but you forgot to lock down the database used by the CMS.
- The forgotten risk: You want to secure your Android smartphone. As mentioned in a guide, you install F-Droid, Firefox and some browser plugins. Finally, you install some apps that mention “security” in their description. Seven days later, you lose your smartphone. Later, somebody easily reads all of your end-to-end encrypted messages, views all of your private photos, and accesses your e-mails. The root cause was the missing part about full-disk encryption and the risk of losing physical access to your smartphone.
- The wrong assumption: You switch to an instant messenger, which was recommended due to being “secure”. You manage to turn on end-to-end encryption. While you think that your messages are “secure” now, tons of metadata and data are managed and stored server-side—in cleartext. The recommendation was only focused on encrypting contents of messages in transit, and assumed that the server is always trustworthy.
How to solve it
Define your own threat model. There is no other solution. You are the only person who knows which hardware and software you use. You are the only one who knows all of your use cases. If you only do things that are explained in some guides, it is very likely that you forget something.
Reason 3: No checks and no monitoring
Many people configure their hardware and software exactly one time. Then, this configuration is left unchanged for a long period of time.
What is the problem?
If you never check whether your configuration actually works (or still works), you don’t know it. You just assume that everything works as expected. We showed this in our article on the LineageOS-based /e/ operating system: People just assumed that there is no Google anymore, however, many of them didn’t actually check it.
- The attacker was already there: Our favorite example are servers. Nearly all guides on server security only show you how to configure it once. That’s all. They mostly never mention that monitoring, alerting and reacting is essential for server security. This may originate from the wrong assumption that you can prevent every type of attack. Detecting ongoing attacks is as important as preventing them, though.
- Data leaks everywhere: If you look for guides on privacy, you likely come across blogs recommending VPNs for privacy. While VPNs can help you securing network traffic under certain conditions, you never know whether all of your traffic is actually routed to your VPN.
- No control at all: Some guides tell you about “taking back control” by installing certain operating systems and changing some configuration. At the same time, most of your hardware components are likely proprietary and there may be other hardware or software components that are also connected to a network. If you don’t check this, you never learn about it.
How to solve it
It is essential to monitor your complete network traffic and hardware. This is especially true for remotely-located hardware like servers in data centers. Detecting attackers is as necessary as preventing attacks. Furthermore, you need to check if your configuration actually works as expected. Don’t assume it—check it.
Follow us on Mastodon:
Hopefully, you got an idea why blindly configuring your hardware and software without a threat model or without checking anything results in a false sense of security.
We update our guides from time to time to address the issue of giving outdated advice. However, we don’t know your threat model or uses cases, too.