Too many IT professionals believe that companies that provide cloud platforms and services, such as AWS or Google Cloud, handle all the cloud-related security. Considering how much business transpires in the cloud, this is a dangerous assumption to make.

Unfortunately, far too many are caught off guard when they learn that the security of these web services is limited. Yes, you are purchasing a service from them, but the truth is, IT security within a shared API is a shared responsibility.

Brad Geesaman sees it far too often. He’s been in IT security and infrastructure for over 15 years, working with Symantec, Blackfin, and others. He’s worked as an ethical hacker, teaching others how to root out security threats within their networks, and he’s currently providing private IT security consulting.

He spoke at the Black Hat USA conference in Las Vegas, and after I heard him speak, I knew I had to have Brad on our Defrag This podcast. He came on the show and shared his expertise on how IT professionals can better protect their assets running on shared cloud platforms.

Here are some of the highlights from his interview. You can also check out Brad's deck from his BlackHat session here. 

Myth: Cloud Providers Have Shared API Security Handled

This is a common misconception among companies who are using AWS (or other cloud platforms, such as Google Cloud Platform, Microsoft Azure, or other related services).

IT professionals tend to overlook these security areas because the assumption is that these services are ensuring the safety of the transferred data. Simply, this is false — It’s a shared responsibility, and the lines are often blurred.

Truth: The Security Lines in Shared API Are Blurry

AWS has created seemingly clear diagrams of what the customer is responsible for, versus what AWS is responsible for. In reality, however, the lines are often blurry.

To both parties, either the customer or the cloud service is simply an API endpoint. The customer has the keys to that API, while the web service is responsible for ensuring that the calls submitted are valid. This seems simple enough, but often, individuals within organizations forget the obvious: Whoever has the key, has access.

In his 15 years of experience, Brad’s seen keys jeopardized because of everything from sophisticated botnets to unaware people literally posting their account numbers on support tickets. All of these have large-scale implications on a company’s cloud data.

Who Are the Threats?

The threats to AWS (or any other cloud platform) are numerous. Brad laid out a few of the top security issues he currently sees threatening the cloud space:

• Developers - Often times developers in operations are using unsecured laptops that provide easy targets.
• Third-party services - Targets often include third-party services that require your API keys. This could include an email client that’s integrating with your account, or any other service that has touchpoints with your software.
• Crypto mining - As crypto mining requires high levels of processing power, malicious hackers are often lurking to find easy access to cloud platforms on someone else's dime. Customers usually won’t even know they’ve been exposed until they receive a large bill from their cloud service.
• Botnets - Scattered across an entire network, hackers use bots that prey on default test passwords, such as “Abcd1234.” These bots will hack simple passwords within minutes to gain access to a network.
• Threats you don’t hear about - Often times, the truly malicious and large scale issues are those you don’t hear about. Organizations are hesitant to publish exactly how they were breached, so many times the most sophisticated attacks are those never publicized, or publicized in a way that doesn't help others protect themselves.

How Can Customers Protect Themselves?

Brad provided a thought process for IT professionals to follow when attempting to protect their organization:

1. Start with the usual IT security model of asking, “If this were compromised, what would the hacker have access to next?” Next, keep iterating until you reach the end, and then work backwards from that endpoint.
2. At every stage, consider what tools you have to limit the attack and protect your network. If at any point you come across something for which you do not have the answer, or the native system doesn’t provide a solution, consider using a vendor.

In Summary

In summary, the information Brad provided pointed to one overarching facet: As the IT professional, it is your job to protect your organization's data and assets. While the native service may provide many of the solutions, they will not provide security for the entire network.

Shared APIs are shared responsibility.