The use of the cloud is now mainstream and, despite some concerns, it is generally accepted that the public cloud is not inherently insecure. In fact, in many cases it is more secure than most data centres.

This can be explained when we consider how many opportunities there are for a piece of sensitive information that has been emailed, saved on a USB drive, or otherwise shared with colleagues to fall into the wrong hands.  Compare that to the same information being created, edited and saved in the cloud.  Major providers such as Amazon Web Services (AWS) and Google certainly put their best foot forward to provide layered security models for encapsulated cloud environments, with the intended outcome that customers can then benefit from these economies of scale at minimal expense.

Keys to the door

But of course, cloud security is not the only form of security required for systems and applications running in the cloud.  Relying on cloud providers for firewall, VPN, and WAF security is common and those components are often integrated aspects of a cloud provider security model.  However, the exposure of data and information to applications in the cloud is done via APIs (application programming interfaces). API security is an entirely different game.  This involves identity, security, and policies that should be within the control of your own organisation, not outsourced to the cloud.   This is also a necessary aspect of governance where your APIs represent the keys to the door and giving those keys to the cloud provider tips the balance of control too far.

APIs are the focal point of cloud innovation and enable the connections and data sharing that has allowed the cloud computing landscape to be adopted across virtually every technology and market segment.   But just as you would be cautious about handing over the keys to your house to another person, you should be equally cautious about handing over the API security capabilities to your cloud provider.

APIs have a pivotal role in widespread adoption of smartphones and tablets (and any other smart and connected devices like fitness trackers and smartwatches), the Internet of Things, and even social media. All of these have relied on APIs to function or grow. The threats posed by an exposed API are significant and ever-growing.  Yet, they remain the most overlooked threat to information security today. This is because API vulnerabilities are not easy to spot and require specialised technology for detection and prevention.

In recognition of this, in 2017, the non-profit, non-affiliated, online web application security community Open Web Application Security Project (OWASP) recognised API Security as a primary security concern by adding API to 9 of the top 10 vulnerabilities noted in the latest publishing of the OWASP Top 10 report.

API gateway vs API security gateway

Most cloud services use their own rendition of API gateways to serve as the single-entry point into the application or service and to provide access control. Because APIs are exposed via API gateways, the gateway product itself has become the target of attack and compromise. Any hacker who can compromise the API gateway will have the ability to turn any “no” into a “yes”. The primary issue is that API gateway technologies were designed for integration, not for security. API security best practices instead use cyber-secure technology for API enablement, which performs the roles of an API gateway, but includes the IAM and cyber security technologies together within the gateway itself.  This product technology is known as an “API security gateway”.

An API gateway will never provide the same layer of protection as an API security gateway. When an untrusted connection comes to your API and asks for your data, how can you be sure that that API has access to only the particular data that they need, or that they are allowed to have?  Are there embedded threats inside the API request? Is this trusted user accessing the API sending and retrieving the information expected? Access control alone is not API security and because API gateways are not based on cybersecurity technology, but rather based on integration platforms that run as software applications on insecure operating systems, they are designed simply to share information, not keep information safe.

Don’t outsource your cloud API security – control it

The only way to truly protect the data held in a public cloud is to embed secure API gateways within the cloud itself by deploying API security gateways.

If the gateway is not inherently secure by design at the point of its creation, then you will always be playing catch up as new exploits are inevitably discovered. The Panera Bread data breach when an unauthenticated API-endpoint exposed 37 million customer records and Shellshock (aka Bashdoor) family of security bugs which hit Yahoo! are proof of what can go wrong when using API technologies with insecure product architectures.

Many product vendors talk about their products having security features, but bolting on security features on products that are already inherently insecure at their core will not stop attackers from compromising the product by attacking the basic foundations of their insecurity.

More importantly, relying on cloud providers for API security will result in outsourcing your data security model and control of it.  This means that breaches and access to sensitive governance data by third parties are outside of your control. Instead, take control of your cloud API security policies and control your own keys and governance rules. Then you can fully realize the many benefits of cloud adoption with the assurance that the next API breach news story won’t be your company name in the headline.