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…
-
Default Enable: as many hardening settings ought to be turned on by default.
- That’s why we there is Kicksecure and Whonix.
- Easy Enable: otherwise these should at least be easy to enable.
This is a call to action.
-
Developers:
- Follow development discussions.
- Contribute solutions and source code.
- Review existing security enhancing packages.
- Implement enhancements and security ToDo.
-
Documentation writers:
- Simplify, improve existing documentation.
- Screenshots. Improve documentation by adding screenshots.
- Users:
