Sep 15, 2022
Configuration management is the documented process with which changes to complex systems are executed. Historically, this has been a largely manual endeavor, relying on checklists, procedures, and reams of documentation. More recently — relatively speaking — configuration management has embraced automation through the use of tools like Ansible and Terraform, allowing teams to manage their infrastructure configuration using code — a concept helpfully called “Infrastructure as Code” — rather than the far-more-fallible human being.
Despite the advantages that automation brings to configuration management, it’s hardly perfect. As with all things, there is a learning curve, and even when you understand the underlying concepts, it is still easy to make critical misconfiguration mistakes unless you know what to look for.
You can’t secure what you can’t watch. It doesn’t matter how much effort you put into your cloud security, you’ll never know if (or when) it becomes compromised without a thorough and effective monitoring solution. Properly performing monitoring as well as integrating logging and other monitoring tools into your cloud configuration will allow you to catch problems before they become incidents; and, in the event that something does happen, they will allow you to properly identify how severe the problem is.
When you move into a new house, you always change the locks. It’s not because you are expecting the original tenants to let themselves in; it’s because you don’t know who else has copies of their keys. Failing to review and update default configuration values in a cloud environment is the same as not changing the locks. You’ll probably be fine, but you can’t be sure of that unless you take the time to protect yourself.
Default values can be as benign as predictable usernames and common ports, or as catastrophic as pre-defined (and publicly known) login credentials. You may or may not choose to leave those values alone, but it should be a conscious choice. Remember, trust… but verify.
One of the biggest mistakes in cloud security configuration is to not take identity and access management seriously. It doesn’t matter who it is, or what their seniority is. For every person that has unrestricted access to a given system, the possibility of a breach goes up, because all it takes is one person to click on the wrong email attachment or reuse the same password across multiple sites to compromise an entire company.
Always follow the principle of least privilege. Every user with access to a production system is a potential attack vector, so it is in everyone’s best interest to only have access to what they need, and nothing more.
Next to social engineering, unpatched vulnerabilities are one of the most common causes of critical security incidents. While keeping systems across an entire organization secure can be a daunting task, the same can’t be said for cloud configurations. Thanks to automated configuration management tools, it is possible to apply security patches within minutes of their release.
Most cloud environments require secrets to run. Passwords, API keys, access tokens… no matter what it is, you need to store it securely. While storing this configuration information in plain text isn’t necessarily an external vulnerability, it can drastically expand the impact and scope of a breach. As Gandalf the Grey said, “keep it secret, keep it safe.”
While Infrastructure as Code is an excellent solution for maintaining consistent and repeatable cloud configurations, what makes it particularly useful is how defensive it is despite the potential for misconfigurations. Just like any other code-based project, the code that is used to define infrastructure configurations can be analyzed and scanned for vulnerabilities, misconfigurations, and other best practices long before the changes reach a production environment.
By shifting left to integrate guardrails into the continuous integration pipeline, security teams can protect the organization against configuration mistakes early in the development process. Whether it is ensuring that logging is enabled, default values are explicitly accepted or replaced, access controls are as minimal as possible, package versions are the latest available, or even that API keys aren’t written directly into the configuration recipes, this type of automation can go a long way towards eliminating simple mistakes that can have big consequences.
In even the best circumstances, a security breach can mean the death of a company; but a security breach caused (or exacerbated) by a misconfigured cloud infrastructure can be particularly harmful. Beyond the damage to the brand and the loss of customer trust (and the customers themselves), it opens the company up to potential liabilities and regulatory fines.
When it comes down to it, customers expect companies to take the responsibility of data stewardship seriously, and that means making a clear and conscious effort to configure a cloud environment that keeps their data safe and secure. Just like ignorance of the law is no excuse for breaking the law, neither is ignorance of cloud configuration best practices an excuse for failing to properly maintain and secure a cloud environment.