Security is only as strong as your weakest node

If someone said to you that security is only as strong as the weakest link, would you know what that means?

When we talk security, there are certain patterns that as developers, we should know about. The "Security is only as strong as your weakest node" is one of them. Bruce Schneier explained that on his excellent Secrets and Lies book as:

Security is also like a chain. It is composed of many links, and each one of them is essential to the strength of the chain. And like a chain, security is only as strong as the weakest link. In this part, we look at the different security technologies that make up a chain, looking from the inside of the onion to the outside

Let's review with a concrete example what that means.

A simple multi-layered Architecture

Suppose we have the following simple architecture, common in most IT shops:

As seen, the above architecture is composed of:

• a firewall;
• one web server;
• one database server;
• one backend server;
• storage accounts;
• a messaging system used to communicate between the servers;
• probably a build server;
• probably a deploying mechanism;
• probably multiple workstations with developers working on it
• probably multiple 3rd-party packages and dependencies used in development projetcts
• probably making use of multiple SaaS, PaaS, IaaS.

And what's necessary to secure this architecture? Let's review a security checklist.

A security checklist

In my company for example, this is the minimum that I could expect:

• on the firewall: inbound and outbound rules are safe, the firewall software is kept up to date, the accounts to access the service have strong passwords, the server is kept up to date, etc;
• on the web server: ensuring only necessary ports are open, services are not leaking any information, the server is patched, the webserver software itself is patched, the services utilized are secure (such as ssh, sftp, etc) and up to date, accounts to access the service have strong, rotating passwords, the code is reasonably resilient against attacks, has anti-virus software running, etc;
• on the database server: ensuring not open to sql injection attacks, server is patched, database software is patched, no horizontal/vertical escalation can happen, accounts to access the service have strong, rotating passwords, has anti-virus software running, etc;
• in the backend: code is somehow safe against attacks, OS is kept up to date, all 3rd-party libraries are kept up to date, accounts to access the service have strong, rotating passwords, has anti-virus software running, etc;
• on the storage accounts: have strong passwords, have some sort of rotation mechanisms
• the build server: the build is safe against external code injection, the build service is kept up to date, the OS is kept up to date, has anti-virus software running, etc.
• the deployment process: is done automatically with little option to interference, has the source OS patched, guaranteed that the build is intact, communicates to secure channels, etc;
• users have a clear understanding of how spam, phishing, smishing, vishing, malicious links can affect the internal network
• developers are aware of the vulnerabilities in 3rd-party packages utilized in their projects and are constantly upgrading their dependencies to the latest available stable version

So just on the infrastructure we have at least 40 very important policies for our development architecture of 6 nodes! How complicated is to maintain all of that? Well, considering that the CVE Database is dynamic and considering the complexity of the above systems, I'd say, it's very, very complicated.

What about Development?

And what about on the user/development side? If we factor the # of accounts, # of developers, # of 3rd-party software used and multiple attack types, that list escalates very quickly!

May it be clear that, of course, on the list above some items are more critical than others but you get the point. Why would an attacker spend time trying to crack your super-secure session encryption algorithm if your unsecured instance of MongoDB is running openly on the internet or if you're using admin/admin as username password, or if you're not aware of the vulnerabilities your tools, or ... provide-your-example-here. That's why security is only as strong as the weakest link.

Conclusion

It won't matter if it's on a jQuery, on a poorly implemented code, a Sql Injection or on a printer. The attacker will always seek the easiest route to get his job done. And it's our job to try to be as safe as we can.

References

• Secrets & Lies - Digital Security in a Networked World
• Information Security: ‘Only as Strong as the Weakest Link in the Chain’
• CVE Database

See Also

• How and why use stronger passwords
• Security and development: how much is being done?
• The Laws of security
• Security and Ethics
• Privacy and Ethics
• Integrated security vulnerability alerts on GitHub - Why it matters
• Dropbox officially debuts its password manager

For more posts about Security on this blog, please click here.