Today, the benefits of cloud computing are very well established: it is less costly and provides increased flexibility and agility, including the ability to support on-demand computing at scale. 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.
Infrastructure-as-a-Service (IaaS) and Platform-as-a-service (PaaS) – where a company’s own applications and assets run on infrastructure operated by the public cloud vendors — have also grown in popularity. Amazon Web Services (AWS) and Microsoft Azure have experienced significant growth, in part because of the relative ease for an organization to set up and deploy their applications at scale in cloud environments.
Public cloud vendors focus on the security of the cloud infrastructure, including the compute, storage and networking resources as well as the physical infrastructure, but they recognize that they are only able to provide a partial solution. In fact, 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.
Essentially, everything above the hypervisor or equivalent layer is the responsibility of the application owner. Organizations may also need to configure some of the services provided by the cloud vendor. For example, basic perimeter security is included with the cloud vendor’s infrastructure, but it is configured by the customer.
In case there is any doubt, the AWS Customer Agreement, for example, is very clear on the limits of AWS’ responsibilities for securing the enterprise’s applications and data. The liability is limited to refunding what the enterprise paid AWS for services in the past year. As a speaker at the recent HIMSS healthcare IT conference pointed out, even if the cloud vendor could be proven to be at fault for a breach, and that’s a big if, it’s very unlikely the enterprise would be covered for direct financial loss caused by the loss of patient’s medical records. On top of that, there are other costs including regulatory fines, reputational loss and, most importantly, impact on the organization’s customers.
While the public cloud vendors take steps to ensure the security OF the Cloud, ultimately, just like with an on-premises data center, it is the enterprise and application owner that is responsible for security IN the Cloud, and for ensuring that your customer’s data is secure.
Unfortunately, that message may not be getting through to all cloud users. A recent survey carried out as part of a webinar I gave to security professionals revealed that 19 percent of respondents rely on the cloud vendor’s security while 28 percent use a mixture of third-party security and the cloud vendor’s technology. A further 16 percent said their security arrangements varied based on the specific application or business unit.
Organizations that rely solely on a cloud vendor’s built-in security are potentially exposing their organization to unnecessary risk.
While there are multiple steps required to protect cloud infrastructure, particularly when it comes to IaaS/PaaS, for most organizations it makes sense to start with the cloud vendor’s management console. With a public cloud vendor such as AWS or Azure, the enterprise’s entire cloud infrastructure is accessed through the cloud vendor’s management console. This management console is incredibly powerful and really does hold the “keys to the Cloud kingdom,” even more so than for the on-premises admin consoles.
The management console typically enables:
- Set up and configuration of the entire cloud infrastructure – allocating resources, setting up applications, compute instances, determining the regions and zones the apps run in
- Setting security parameters, delegating authority and enabling others to have access
- Billing, and purchasing of applications from the marketplace
Unfortunately, the management console is also an attractive target and likely the entry point for an attacker, given the human administrator’s vulnerability to phishing. So a first step in securing the cloud assets is to make sure that the enterprise locks down controls and monitors the management console and secures the associated credentials.
Fortunately, for most organizations this first step of ensuring that the credentials for accessing the management console are secure should be relatively straightforward. In fact, CyberArk’s customers use our digital vault infrastructure to secure, rotate and control access to the privileged passwords used to authenticate to the management console.
Another critical step is to protect the credentials that applications and other assets running in the cloud need to access resources, such as customer databases and other assets. Unfortunately, the required credentials are all too often hardcoded in applications and this is a troubling and unnecessary vulnerability which needs to be addressed. Today developers and cloud administrators use CyberArk Application Identify Manager (AIM) to eliminate embedded credentials in cloud applications, by storing the credentials in the CyberArk digital vault, rotating and controlling application credentials according to policy, etc.
Taking these steps helps organizations address their responsibilities to ensure the security of their cloud applications and to meet their compliance needs. An added benefit is that the same digital vault infrastructure can be used to secure credentials for not only the public cloud management consoles and cloud applications, but also for all the other privileged credentials and passwords used to secure on-premises and hybrid environments, as well as DevOps tools. This is extremely important to CISO and IT leaders wanting to follow the best practice of enforcing the same security policies across the enterprise regardless of the compute environment.
