Monday, August 21, 2017

The Laws of security


Continuing on a previous discussion about the book "Stealing the Network, How to Own the Box", I would like to follow up on a very interesting section of the book: the laws of security.

The Laws of Security

According to the authors, the 10 laws of security are:
  • Law #1: If someone can persuade you to run his program on your computer, it’s not your computer anymore.
  • Law #2: If someone can alter the operating system on your computer, it’s not your computer anymore.
  • Law #3: If someone has unrestricted physical access to your computer, it’s not your computer anymore.
  • Law #4: If someone is allowed to upload programs to your web site, it’s not your web site any more.
  • Law #5: Weak passwords trump strong security.
  • Law #6: A machine is only as secure as the administrator is trustworthy.
  • Law #7: Encrypted data is only as secure as the decryption key.
  • Law #8: An out-of-date virus scanner is only marginally better than no virus scanner at all.
  • Law #9: Absolute anonymity isn’t practical, in real life or on the Web.
  • Law #10: Technology is not a panacea.
If you are a developer, devops or sysadmin, I would like to ask you: have you seen any of these rules before?  

The Laws of Security and Developers

Now that we know these rules, in order to rethink them from a development standpoint, let's consider these questions:
  • Do we, while writing our code, think about how could make our code safer?
  • Do we, while reviewing other people's code, think about how to make our code safer or which are the vulnerabilities in it?
  • By knowing those rules, how could we protect our companies by writing safer code? Are we doing our best for them?
  • By knowing those rules, how could we write safer code protect our users from threats and even from themselves? Are we doing our best for them?

Unfortunately, the answer is probably NO for most of the above. Or maybe a false yes (I do but, you know, not exactly sure if it's right.) That's okay! Our objective here is to foster the discussion in the first place.

Next, work on incorporating cybersecurity paradigms into our lives so that we these patterns, tools and techniques become part of our habitual skill set.

Conclusion

Security is hard. We need to disseminate this knowledge and educate our families, users, managers, co-workers and everyone else around us so they can be constantly thinking about risks and threats, how we can mitigate them and why we should be discussing them.

We always think about threats in the real world so, why neglect the virtual one?

See Also

Security and development: how much is being done?
Security is only as strong as the weakest link
The Laws of security
Security and Ethics
Privacy and Ethics
Security Boundaries
Integrated security vulnerability alerts on GitHub - Why it matters 

For more security posts on this blog, please click here.