The Problem with Security Guides and How We Can Fix It

Security hardening instructions are amazing but these have some issues.

  • Vulnerable until applied: After installation, these security tips are not yet applied. During that time window, you’re vulnerable.
  • Recipient Insecurity:
    • Now you’re security hardening. Great! But what about your correspondence partners?
    • The NSA might now no longer wiretaps the phone of German chancellor Angel Merkel. But how does that help if everyone she’s calling is wiretapped?
    • It’s great that you followed a guide and now have first class entropy. But what about the Tor relays you are using? If Tor relays are insecure, these cannot protect you.
    • Often, your security can only get improved if also the security of others gets improved.
  • Reliance on human memory: You need to remember to apply all your favorite security guides.
  • Reliance on human labor: Manually applying security guides risks that a typo renders the whole procedure ineffective.
  • Time requirements: You need time to apply the security guides.
  • Too many: There are too many security guides. You cannot follow them all and you probably find new ones once in a while.
  • Incomplete: Somebody hardens the kernel. Someone else using sandboxing, uses better true random number generators, installs CPU microcode updates and so much more. But most users are missing something because they’re not aware of the possibility.
  • Outdated: Often get often out of date after some time.
  • Non-collaborative: Many security guides are written in blogs. Sometimes not even comments can be posted. This is a grave disadvantage compared to collaborative version control system based (for example git) software or collaborative websites (such as a wiki) because contributors who like to fix issues or update contents cannot easily to so.
  • Unknown unknowns: Have low popularity. People don’t find out about them.

Security guides fixing specific issues aren’t a holistic security concept. Don’t get me wrong, security guides are awesome. These are often the basis for our security hardening work.

We can fix these issues by providing software which applies as many hardening instructions as sanely possible and then offering users and Linux distributions of using these. Free and Open Source. We are already in progress of doing that but need help.

Because of these issues…

This is a call to action.


This. Ideally the secure OS comes with everything software related applied already. Guides would cover hardware choices that are outside of our control also because there is huge selection to choose from.


Security hardening is always a layered process; there’s no magic bullet that makes the system invulnerable. Degrees of hardening and applicable techniques also vary based on threat models, hardware capability, and user motivation and knowledge.
It is prudent to apply as many settings as reasonably practical by default.
There is also such a thing as too much hardening. By that it means that the system may be very secure against a great number of vulnerabilities, but now becomes unusable, or a real struggle for the user. Now it is a freedom issue. If a user cannot do whatever he/she wants to do, then the hardening fails. That’s why there has to be a fine line between “too much” and “not enough.”
I believe that the current Whonix and Kicksecure releases both balance usability and hardening, and they do it very well.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]