Securing assets and applications in the cloud

More organisations in Hong Kong are adopting and recognising the strength of cloud. One of the main attractiveness of cloud for Hong Kong companies is the convenience, efficiency and cost savings. According to the Cloud Readiness Index released by Asia Cloud Computing Association (ACCA) last year, Hong Kong and other Asia Pacific countries such as Singapore and Australia ranked above markets compared to United States and United Kingdom. Hong Kong in particular claimed top spot with a jump of 4 ranks, scoring CRI of 78.1, while Singapore takes second with CRI score of 76.7.

With this, the debate surrounding the security of cloud computing, specifically whether data was more secure in the cloud or not, has for the most part been settled. A growing number of organizations now view the cloud as secure, and in many cases, more so than an on-premises deployment.

Beyond that, as each of the public cloud vendors point out, security in the cloud is a shared responsibility – with the organization as the application owner being responsible for protecting applications, the OS, supporting infrastructure, and other assets running IN the cloud.

From a security standpoint, 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. As such, the enterprise's responsibilities, specifically the functions above the hypervisor, include 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.