Security of a solution is not the sum of the security of its parts.
Imagine a jet engine in isolation – it looks good and secure, doesn’t it? Imagine a bicycle in isolation – it looks good and secure, doesn’t it? Now imagine jet engine strapped to a bicycle – what a disaster!
(Nevertheless, it has been tried – A Jet Engine On A Bike )
Secure components don’t guarantee a secure system.
A striking demonstration of the fallacy is the corporate cloud services certification or assessment programs. Cloud services, or elements, are being assessed for security outside of the context of the actual implementation.
Let’s take a cloud storage bucket, for example. Assessing it in isolation, you may prescribe that it must never have public access. However, there are scenarios where it is totally appropriate to have such configuration. Product descriptions or T&Cs are perfectly fit to be served from a publicly accessible storage bucket.
Opposite example is copying production customer data to a development CloudSQL instance. Both production and development databases are “certified” and “secure” cloud elements, but is that a secure solution overall?
I think these programs do more harm than good. They slow down adoption of cloud services, and provide false peace of mind. They take focus away from actual implementation.
Configuration baselines have similar problems. The “gold standard” configuration can be defined only at the element level, not at a level of the complete solution. It will be either too rigid and require painful exception management, or it will be too vague to be useful.
Solutions need to be assessed holistically, as a whole. Period.