Security is only as strong as the weakest node

If someone said to you in a tech-related conversation that "security is only as strong as the weakest link", would you know what that means?

Bruce Schneier explained this 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

 But what does he mean? Let's check an example.

A simple multi-layered Architecture

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

As clearly 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.

What then is necessary to secure this simple architecture? This is where things start getting interesting. Let's review a simple 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, very complicated.

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 or on a printer vulnerability. 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.

See Also

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

References

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