By Derek Handova

With the rise of API integration platforms like MuleSoft and communications platform-as-a-service (CPaaS) APIs such as Twilio, API security has become a general concern for cloud startups. In addition, because many traditional enterprises are now migrating from on-premises communications to cloud platforms, API security for them has come in sharp relief due to ransomware, phishing, e-commerce, and other endpoint security bête noires.

CPaaS and APIs offer benefits including improved productivity and third-party app integrations, but they also come with endpoint security risks. Before migrating, customers and their MSSP partners need to consider the risks of CPaaS APIs and come up with a plan to protect endpoints from any potential security risks. MSSPs can play a vital role in managing the CPaaS API endpoint security risk for their customers, but first they must answer critical questions about how to:

API Security and Internet and Mobile Endpoints

Developers of the wireless internet and mobile apps often desire communications capabilities that are native to their applications. Prior to CPaaS, these app developers would either have to build their own communications stack, replicating fairly complex software, or redirect a user to a third-party business phone app such as Skype or WhatsApp, according to security experts. They also state that CPaaS allows native integration of communications capability with simple API interactions so that developers can deploy capabilities quickly and customize it to their needs, without sending customers to other applications.

Kudelski Security’s Andrew Howard

“But the APIs are only as secure as the CPaaS platform makes them,” said Andrew Howard, CEO of Kudelski Security, a global security firm. “Typically, a developer would write code to interact with the CPaaS API based on specifications written by the CPaaS platform. It is critical that those specifications follow API security best practices, such as requiring authentication, and that the API implementation actually matches the specification. Developers should demand API security best practices in the CPaaS API, carefully inspect API specifications and implementations for flaws and demand regular security audits of the API by reputable third parties.”

And focusing on Authn/Authz strong authentication as well as transport layer security (TLS), and a good content data network (CDN) to provide web application firewall (WAF) services are key best practices to keeping cloud API and CPaaS implementations secure, according to other security experts.

Ivanti’s Phil Richards

“A strong Authn-Authz authentication model with excellent password strength and multifactor authentication is a must for this environment,” said Phil Richards, CISO, Ivanti, a provider of unified IT solutions. “Additionally, a strong authorization model with multiple roles is critical to granting access based on need and to keep a narrow scope. And using TLS 1.2 with CA-signed certificates is critical for web-facing interfaces, keeping traffic encrypted and guarding against man-in-the-middle attacks. But having an…

…updated WAF is very important for web-facing APIs because your ability to patch the CPaaS may not be under your control, but under the control of the provider. A WAF is great insurance for when you cannot manage the patching.”

API Security and Endpoint Security

42Crunch’s Dmitry Sotnikov

When it comes to MSSPs protecting customer endpoints from API security exploits and possible CPaaS data breaches, each communication scenario has different risks that need to be addressed, according to Dmitry Sotnikov, vice president of cloud platforms at 42Crunch, an enterprise-grade, full-fledged API security platform. These scenarios include:

CPaaS invoking your endpoint: According to Sotnikov, make sure that only the expected CPaaS servers can invoke your endpoint with IP whitelisting, mutual TLS and authentication as well as enforce HTTPS and TLS 1.3. In addition, check the integrity of each call by verifying signatures, JSON Web Token (JWT), payload, and parameter formats. Also set rate limiting and use monitoring, log management, and analytics solutions to analyze usage and detect suspicious events.

Application invoking the CPaaS API: Depending on how and where you store the API keys can be very determinative. That’s because these are effectively your passwords, so you should reduce the exposure as much as you can, in the view of Sotnikov.

“Don’t put them in your source code repository or log files, use the protected vaults of the infrastructure that runs your apps, and if the vendor gives you a choice to pick the authentication scheme, go for OAuth/OpenID Connect and user-specific keys,” said Sotnikov.

In addition, he counsels that MSSPs should minimize the amount of sensitive data that they integrate into CPaaS solutions — assume that it can get breached at some point. Therefore, MSSPs should purge historical data as soon as possible and otherwise store the bare minimum of end-user personal information.

Application using CPaaS code: In the API security scenario where the application is using CPaaS code, Sotnikov advises analyzing the extra risks that come with using someone else’s code as part of your app. For example, make sure that only code from expected sources can get into your application as well as only use the minimum level of account permissions necessary to run the code. In addition:

API Security and Voice and Video Communications

While CPaaS APIs have given developers tools to integrate real-time communications, such as voice and video communications, into their apps without building interfaces and backend infrastructure, it comes at the cost of decision-making power over API security, according to voice and video communications experts. In this scenario, businesses don’t have full control over the development process and the endpoint security of the CPaaS solution. So, they can only hope that there are no CPaaS data breach vulnerabilities in the APIs provided by the CPaaS…

…vendor, in their opinions.

TrueConf’s Dmitry Odintsov

“The truth about CPaaS offerings is that the audio and video streams of your users will be processed by a third-party platform that will inevitably pose certain API security risks,” said Dmitry Odintsov, CEO at TrueConf, a video conferencing vendor. “Developers are not immune from the errors and vulnerabilities that can be unintentionally created by the platform owners at any given time. Think of it as an unavoidable risk you can’t control. CPaaS customers and business partners simply have no say over how their data and communications are protected. More importantly, since they are dealing with cloud-based solutions there’s no way for them to roll back to a more secure version of the platform.”

And not only does the potential for CPaaS data breaches apply to data in motion such as in the case of real-time voice and video communications but also to data at rest—including data stored in services at the edge of the network. In particular, developers should recognize that the CPaaS data stores — or even in some cases, the logs — may actually contain data that might create another audit point for sensitive information, according to API security consultants.

Hillwork’s Steve Pao

“Application developers should carefully consider whether they choose to utilize the CPaaS providers’ embedded capabilities to store voice messages, faxes and other data at rest,” said  Steve Pao, principal of Hillwork LLC, a consulting and board advisory practice to early stage technology companies. “If they choose to delete these objects, they must store them completely on their own. Or if they choose to keep them within the CPaaS provider platform, they should implement all the API security protections afforded by the platform. And any applications that might accept credit cards, Social Security numbers or any other personally identifiable information (PII) via voice, text or fax message should also consider these implications.”

Unknown API Security Risks

MSSPs should keep in mind that some API security risks remain unknown because they are hidden or the APIs are not in use. It’s important to get a full listing of older legacy APIs that still exist in the system. Having access to as much data as possible from the provider about the APIs and how they are used will better position the MSSP to determine the CPaaS data breach risk APIs may pose to endpoint security.

Synnex’s Kirk Nesbit

“Overall, the CPaaS host will have control over what APIs they use,” said Kirk Nesbit, vice president of design and support services at Synnex Corp., a technology solutions provider. “Because of this, the MSSP must diligently monitor how these APIs are developed and how they work. Pen testing should be conducted against the APIs in production as well as those being developed. A third-party source code review of the API can also help. If the CPaaS provider hesitates to share this information, it should raise red flags. Note that neither MSSPs nor the end customers can fully outsource their risk. Risk should be managed internally through a strong vendor risk management program.”