March 30, 2017 | Security and Risk | Chris Smith
In our recent blog, Cloud Security: Who is Responsible for What?, we focused on the idea of shared responsibility in cloud environments; with IaaS/PaaS, the customer is responsible for everything above the hypervisor, while the cloud vendor takes responsibility for the infrastructure itself.
We also addressed how the public cloud vendors’ management consoles are a key weak point and consequently an attractive target for an attacker, often via a phishing attempt. As such, it’s important to lock down and secure privileged credentials in a digital vault to secure the management console. Now, I’d like to further address the enterprise’s responsibilities, specifically the functions above the hypervisor, including securing the privileged credentials used by applications and scripts accessing other applications and assets, such the enterprise’s customer database. Unfortunately these credentials are all too often hardcoded. This is a particularly troubling vulnerability as there can be a large number of hardcoded credentials used throughout cloud and hybrid environments.
Hard-coding and embedding credentials in the code or a script can initially make them easy to use – but this represents a significant vulnerability because attackers or malicious insiders can also easily access them, especially if the credentials are in clear text. But, even worse, when credentials are hard-coded or locally stored, they are nearly impossible to rotate, further making them a static and easy target for attackers.
The risk is real. As part of the DevOps process developers often share source code they’ve developed on code repositories such GitHub. While it’s part of the DevOps process, it’s an all too common example of how embedded passwords and credentials can become public if they’re hardcoded. Even if the code is only saved in the enterprise’s internal code repositories – those passwords and credentials can easily be accessed by other developers and used either inadvertently or maliciously. It also becomes difficult, if not impossible, to fully identify which applications or scripts are interacting with other applications and other enterprise assets.
In the past, these mistakes might not have been so risky, exploitable and damaging within an on-premises environment. However, in a cloud environment, because of the rapid pace of change, the ability to quickly scale, and the tools being used, these vulnerabilities are amplified and can pose unacceptable levels of risk.
To minimize risk and follow best practices, enterprises should avoid hardcoding passwords and credentials used by applications and scripts, and instead, secure credentials in a secure digital vault and rotate them according to policy. With this approach, just like with human users, enterprises can assign unique credentials to each application, code image or script, and then track, monitor and control access via a secure digital vault. Taking this approach, IT administrators will know which applications access resources such as a customer database. Also, when an application or script is retired, the administrator or script can simply turn off the credentials.
A core business benefit of cloud is elasticity – the ability to easily and instantaneously scale up and scale down the number of compute instances, or virtual servers, to meet the needs of the business at a specific point in time. With on-demand cloud computing, the business only pays for the compute, storage and other resources they use. No human intervention is required. The cloud automation tools are either built-in as a capability of the public cloud vendor’s offerings, such as AWS Auto Scale, or as part of the orchestration and automation tools used with DevOps, such as Puppet, Chef, Ansible, etc.
On-demand computing in the cloud, enabled by the automation tools, is a huge business benefit, but it also presents challenges and new potential risks – when these new application instances are created and launched, they need privileges and credentials to access resources. The automation tools can provide the credentials, but these credentials also need to be secured. Consequently, when a new application instance is created, as the compute environment dynamically scales, a best practice is to immediately secure the permissions and credentials assigned to the new instance in the secure digital vault. This ensures that the credentials can immediately be monitored, managed, secured and rotated according to policy. When the compute instances are retired, the associated credentials can also be removed. This is achieved with integrations between the various automation tools and the secure digital vault.
Whether the enterprise is fully in the cloud with IaaS or PaaS or is migrating to the cloud, it is critical to ensure applications, scripts and other assets use secure passwords and privileged credentials to access other applications and assets in the cloud.
Increasingly, businesses leverage the CyberArk Application Identity Manager to store, monitor, track and rotate credentials and passwords according to policy in the secure digital vault for their cloud and elastic compute environments. Learn more here.