Cyber Attacking Targets
Privileged Credentials Used to Administer Cloud Services Make an Attractive Target and Entry Point for Attackers
In recent weeks, cyber attacks ranging from Operation Cloud Hopper to the breach at FlexiSpy demonstrate the vulnerable, expanded attack surface associated with greater cloud adoption. As organizations work to secure their applications and other sensitive assets in the cloud as part of their digital transformation strategies, these attacks demonstrate the need to quickly implement consistent security controls across cloud and on-premises environments.
The risk and potential attack surface posed by privileged credentials, which include API and SSH keys, increases exponentially in dynamic cloud environments – and were a common denominator in these attacks.
In many cases, the first target of attackers are the privileged credentials used to administer cloud services, such as Infrastructure as a Service or Database as a Service. In on-premises environments, privileged credentials are referred to as the keys to the IT kingdom. Now, increasingly cloud-first organizations must adapt to an expanding attack surface and adopt proactive strategies for also protecting these keys. All it takes is a user with administrative privileges for cloud services to click on one phishing email to give an attacker access to the entire cloud infrastructure.
Cloud Security – A Shared Responsibility
One common misunderstanding when it comes to cloud security is who is responsible for what. This level of uncertainty can create gaps that attackers will exploit to infiltrate your network.
Almost every cloud vendor points out in the terms of agreement that security in the cloud is a shared responsibility. But that division of responsibility must be clearly understood by both parties.
Cloud vendors are responsible for security of the cloud — this includes computing, storage and networking resources, as well as the physical infrastructure and making sure services are delivered securely. This is only a partial security solution. Organizations are responsible for securely using the cloud, including ensuring the security of applications deployed in the cloud and securely using cloud infrastructure.
If your organization relies solely on the cloud vendor for security, you’re exposed to unnecessary risk. Being proactive in cloud security is a requirement to face down today’s cyber threats. While there are several steps that are needed to protect cloud infrastructure, the best place to start is protecting the privileged access necessary for administering cloud services.
Protecting Access to the Cloud Kingdom
Just like in the on-premises world, privileged credentials provide root-like access to cloud infrastructure and can extend security risk to hybrid environments. Most cloud providers rely heavily on APIs. Access to cloud services can be driven automatically by APIs or manually through the management consoles. Either way, that privileged access must be locked down and protected.
With public cloud vendors like AWS or Azure, an organization’s entire cloud infrastructure is accessed through interfaces and APIs with privileged credentials. These powerful credentials are attractive targets because they enable the set up and configuration of the entire cloud infrastructure, including setting security parameters and providing broad access to on-premises infrastructure.
Securing cloud assets starts with securing administrative privileges. Privileged and administrative credentials that are used to authenticate access to the management console and APIs should always be stored in a secure vault and rotated after every use. This is true for on-premises, and remains true in the cloud.
Hardcoded and Embedded Credentials Can Threaten Your Cloud
Applications and scripts running in the cloud require access to resources, such as APIs for cloud services, or other application layers, customer databases and other sensitive assets. The access is typically provided by hardcoding or embedding access credentials (including certificates and API keys) into the application, often in clear text. This is a troubling and unnecessary vulnerability, resulting in many hardcoded credentials being used through cloud and even hybrid environments.
These credentials represent a static, easy target for attackers to exploit. For example, DevOps teams often share source code developed on repositories like GitHub. It’s part of the process – but is also a 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, they can still be easily accessed by other developers and used inadvertently, or maliciously. Additionally, it’s nearly impossible to fully identify which credentials, applications or scripts are being used to interact with other applications and assets.
In an on-premises environment, not knowing everywhere embedded credentials are used may not have been as risky, exploitable or potentially damaging. In today’s world, a configuration of this nature is an unacceptable risk to the entire organization.
To minimize these risks, organizations should never hardcode passwords and keys used by applications. In accordance with best practices, these credentials should be secured like any other privileged credential used by IT administrators – stored in a secure digital vault and rotated according to existing policy. This allows IT administrators to gain visibility into what applications are accessing these credentials, and when the application is retired, the privileged credential can be turned off.
Taking Responsibility for Cloud Security
Whether your enterprise is fully in the cloud, or is migrating – finding and securing the privileged credentials used by IT administrators, applications and scripts is a critical part of security. And in most cases — it’s the organization’s responsibility. Risk management in the cloud needs to be prioritized with the same, consistent policy enforcement that organizations use on-premises.
By Gerrit Lansing, Chief Architect, CyberArk