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 outsideBut 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:- 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
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!
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 WorldInformation Security: ‘Only as Strong as the Weakest Link in the Chain’
CVE Database