Sail Smooth with Cloud Threats, Part 2 – Cloud APIs

This is part-2 of a 2 part series that continues to discuss cloud threats and how they affect web applications in the cloud. The following addresses insecure API’s and Management Plane, deepening the threat landscape.

Management Plane – Security Perspective

The cloud API management plane is one of the most significant differences between traditional computing and cloud computing. It offers an interface, which is often public, to connect the cloud assets. In the past, we followed the box-by-box configuration mentality, where we configured the physical hardware stringed by the wires. However, now, our infrastructure is controlled with application programming interface (API) calls.

The abstraction of virtualization is aided by the use of API’s, which are the underlying communication methods for assets within a cloud. As a result of this shift of management paradigm, compromising the management plane is like winning unfiltered access to your data centre, unless proper security controls to the application level are in place.

What is a Cloud API?

The majority of API use REST (Representational State Transfer), which runs over the HTTP protocol, making it popular and well suited for interacting with cloud services. API is used to interact with cloud services and is usually wrapped in a web-based user interface. For example, they are used to carry out functions, such as, to provision, manage, orchestrate and monitor. They unquestionably open the door to the public and hence, you need to fully protect both; the API and the API keys.

API’s can use a variety of authentication mechanisms, there is no standard for authentication in REST (REpresentational State Transfer); an architectural style usually employed in web services development. Both HTTP request signing and OAuth are the most prevalent that leverage cryptographic techniques to validate authentication requests. Due to poorly-designed web platforms, on occasion, you may come across services that embed a password in the request. This type of configuration represents a less secure environment and poses a higher risk for credential exposure.

Example of a Cloud API Threat

Recently, a large cloud provider had a serious vulnerability in their API because of the way they implemented the signing of the API requests. In an attempt to implement your own signature algorithm, if you are able to intercept one properly signed request, you will be able to perform arbitrary request modification.

API – Security Perspective

All cloud service model – Infrastructure as a service (IaaS), Platform as a Service (PaaS), and Software as a service (SaaS) will use API in one way or another. From the security perspective, it is both; the biggest difference between protecting physical infrastructure and the top priority when designing effective cloud security. If an unauthorized individual gets into your management plane, the person could have full remote access to your entire cloud environment.

Application Security

The increased adoption of cloud augments the application scope. The security configuration of the management plane directly affects the security of the web application. All the components can be driven under control of the management plane. The management plane security is now within the scope of the application’s security and a failure on either side will leak into the other.

Within the cloud, there is a lot of reduced transparency as to what is really happening under the hood of the web application. Overall, due to the shared security model, the cloud will trigger the consumer to look for better and more efficient web application security. Therefore, consumers of the cloud must accurately think and plan for better security.

System Vulnerabilities

System vulnerabilities are bugs inside a web application that a bad actor can target and compromise. For example, both Heartbleed and Shellshock affected systems running Linux surfaces the fact that over 60% of website uses some variations of Linux. This is considered alarming to the open source community.

Vulnerability scanning and regular patching are the most efficient tools here. Patches are free and are released days after the announced vulnerability. However, a gap needs to be filled from the time when the vulnerability is announced, until when the patch was released. This is where Acunetix tools sets come into play. System vulnerabilities don’t evaporate when you move web applications to the cloud, especially if you are using a PaaS or IaaS service model of operation.

Summary

There will always be a balancing act between cloud security and business objectives. However, cloud threats have far-reaching implications as the cloud has manifold business touch-points.

You are running at risk if you outsource security. If there is a performance problem, you will notice it straight away. However, if there is a security incident and you are not armed with the appropriate security tools at the application level, it may go unnoticed for years. Therefore, it is significant to keep your fingers on the pulse and sail smooth.

THE AUTHOR

Matt Conran
Network, Security & Cloud Specialist
LinkedIn

Matt Conran has more than 17 years of networking industry with entrepreneurial start-ups, government organizations and others. He is a lead Network Architect and successfully delivered major global greenfield service provider and data center networks. Core skill set includes advanced data center, service provider, security, and virtualization technologies. He loves to travel and has a passion for landscape photography.