How I Do Communications Security Is How I Do Business

𝘛𝘩𝘦 𝘤𝘩𝘢𝘳𝘢𝘤𝘵𝘦𝘳𝘴 𝘢𝘯𝘥 𝘦𝘷𝘦𝘯𝘵𝘴 𝘱𝘰𝘳𝘵𝘳𝘢𝘺𝘦𝘥 𝘪𝘯 𝘵𝘩𝘪𝘴 𝘴𝘵𝘰𝘳𝘺 𝘢𝘳𝘦 𝘢 𝘸𝘰𝘳𝘬 𝘰𝘧 𝘧𝘪𝘤𝘵𝘪𝘰𝘯. 𝘉𝘶𝘵 𝘵𝘩𝘦 𝘴𝘰𝘭𝘶𝘵𝘪𝘰𝘯𝘴 𝘢𝘯𝘥 𝘴𝘶𝘣𝘫𝘦𝘤𝘵 𝘮𝘢𝘵𝘵𝘦𝘳 𝘦𝘹𝘱𝘦𝘳𝘵𝘪𝘴𝘦 𝘱𝘳𝘰𝘷𝘪𝘥𝘦𝘥 𝘢𝘳𝘦 𝘳𝘦𝘢𝘭!

By Evelyn W., CISO for a major telehealth app

Nothing—nothing!—is more important to a telehealth app’s reputation than the privacy and security of protected health information (PHI). Did you realize that? 

If you’re a telehealth CISO like me, about a thousand horrifying things keep you up at night. (Well, used to keep me up at night.)

Like hackers flat-out “Zoom-bombing” telehealth sessions. (Just ... why?!)

Like the wrong parties getting appointment-reminder SMSes featuring actual patients’ names from providers whose specialties may carry certain—ahem!—stigmas.

Maybe that’s the reason in 2019 some 51 percent of CISOs surveyed said they were getting ready for a HITRUST audit, and about half admitted they were getting ready for HIPAA and PCI audits. 

What are those CISOs afraid an audit might turn up in 2021? I don’t blame them for being sleepless though. Because:

Bad Communications Security Will Wreck Your Business!

Throughout the 2010s, bad infosec pummeled healthcare and affected millions of users. (One January 2015 breach affected 78.8 million alone!) 

And in 2020, with COVID-19, bad comsec forced countless healthcare companies to scramble to find communications vendors to get the basic video-conferencing, data-sharing, response-mechanism, and health-check capabilities (i.e., "Are you there?") patients needed.

So let me say something you won’t hear from every telehealth CISO, but you should: With every communications interaction, a telehealth app maker further establishes their reputation for taking—or not taking!—their comsec seriously.

In fact, I’d say bad healthcare comsec—deploying anything but fully HIPAA-compliant communications, using mediocre, publicly available web APIs, and risking a breach—is a death wish for a telehealth app. I’d even say this:

There’s No Such Thing as Wasting Money on Secure, Programmable Communications APIs!

And analysts recommend and praise your using APIs from vendors who offer certified, compliant solutions. HIPAA, HITRUST, KLAS—APIs that earn those stripes bring lots of analyst love and make analysts ready to recommend you to the buyers who value their opinion.

OK. Fine. Then why doesn't every CISO take APIs more seriously? 

I’ll tell you why, because I used to be one of them! I didn’t know if I could trust cloud-based communications APIs!

I had my issues. Lots of ‘em. But mainly I was iffy about communications API vendors. Some are reliable. Some aren’t. When you’re a healthcare organization, you’re responsible for end-to-end communications security, even if your API vendor flakes out. Your API vendor’s cloud based? Great. But are they fully HIPAA compliant? They might be great at APIs in general, but not so great at secure communications APIs for healthcare clients in particular.

These are real concerns. But getting end-to-end comsec with an API vendor who ticks all these boxes can be a piece of cake. If you know which vendor can do it.

But that’s a big if, because most vendors offer just one or two specific APIs, like video, SMS, email, etc., and they don’t bother with end-to-end API security implementation at all.

Still, if you do your homework, you can land a vendor who does it all. And I know of one vendor in particular who hangs its hat on being a one-stop shop with top-notch support. 

I’ll get to this vendor soon enough. For now, let's review the telehealth CISO’s biggest worry about their information security: How secure is it really? Or, rather, how insecure is it?

Know What Analysts Look for When Evaluating the Security Profile of a Telehealth App Maker?

Illustration of a lock and shield guarding a computer monitor with a magnifying glass at its base

Analysts check things like how up-to-date the maker’s authentication methods are, how they control access to PHI, and what kind of encryption tools they’ve got on their belt.

And I Look at API Vendors With That in Mind, Too!

Any vendor worth their salt is going to nail all of the above. But they’re also going to offer their APIs on a single platform that reflects a serious security strategy. I’m talking physical, system, and application-level security, redundancy and vulnerability testing, and more. Here’s a list of secure communications APIs a great platform will offer the app maker who doesn’t want to risk a weak link with multiple vendors.

Disclaimer: Keep in mind, I’m not an analyst or an API developer—I’m an infosec professional. So believe me when I say I probably care even more than analysts and API developers do. Because I work in this for real. Security is my business, but my company’s business is to give providers and patients a secure experience, and to do this, we use a range of programmable APIs.

To name a few:

  1. Verify API: Patients connecting with providers via our app have to respond to a second authentication challenge (see the very next bullet in this list!) thanks to this API, which sets the tone for all the secure communications the following APIs make possible

  2. SMS API and Email API: Patients keep (1) appointments when these APIs deliver reminders and (2) their health matters private when these APIs prompt for a second authentication factor during login

  3. Messages API: Patients ping questions via social chat apps like Facebook Messenger and WhatsApp, and our customers (i.e., healthcare providers) can encrypt replies both within the API and in the transport payload

  4. Dispatch API: Do our customers send reminders and authenticate via SMS, email, and messages haphazardly? Like all at once? No. We fail reminders over to another channel—one after another—safely and orderly. Still no confirmation? Fail over automatically again and again until the appointment’s set

  5. Voice API: Our customers don't have to cross their fingers when relaying sensitive information like test results through our app. Voice biometrics tell them if the caller's truly the person they say they are

  6. Video API: Video chat’s just the beginning. Our customers use our app’s augmented reality filters to leverage data from previous encounters and authenticate patients with facial recognition

  7. Number Insight API: What do our customers know about who's calling? Oh, just all their Caller Name Delivery (CNAM) info! Caller ID, whether it’s a mobile or landline, what carrier, what region, etc.

  8. Reports API: I never wonder how much our users actually use our app’s secure channels, because this API keeps track of trends and calls out opportunities to drive adoption—and security!—even further

  9. Audit API: Look, breaches are always a possibility, no matter how many safeguards you’ve got. But this API ensures the source of the breach won’t stay a mystery for long. Shows which authentication was used to do what. (Here’s to never needing it!)

  10. Advanced Insights API: Why use an API to find out what kind of devices patients use? Or which browsers? Or how long their sessions are? Because it helps us make things that much more secure

  11. Subaccounts API: A provider with lots of departments doesn't need the same level of security for each one. The finance department doesn't need the surgery department’s data. And the surgery department doesn't need HR's. This API allocates subaccounts so our users can tailor reports, properties, and more

  12. Phone Numbers API: This API can let a provider use our app to generate a number on the fly and assign it to a specific patient. So it doesn't matter if the patient's got a blocked caller ID or it's not displaying correctly—they'll still get through, and the provider can be sure it's actually the patient

Pictogram of document with bulleted copy. ebook
Reimagining Healthcare
Your guide to the world of healthcare reimagined with digital communications.

Why Might a Telehealth App Maker Not Want All the APIs Listed Here?

Some are still anxious about putting their communications in the cloud. The cloud had a hard time penetrating healthcare for that very reason. It looked like centralized computing, i.e., very hard to secure and maintain.

Wait, though—how about if you're a CISO who’s got the inside scoop, one who doesn’t want to futz with deployment tools and servers? What if you say to a vendor, "I gotta have the full suite of communications APIs—their features, security benefits, everything!”? 

If we were talking about on-premises setups, adding and maintaining all of the APIs above would create big OPEX ranges. But cloud-based APIs? Nope! Like, imagine after signing up with a cloud API vendor you only wanted to call just one of the APIs above. And then later that day the API vendor signed up a second customer who wanted to call all of them. Would the second customer have to shell out a lot more to the vendor? This may come as a shock:

Customer #2 Wouldn’t Spend Much More Than You Would!

APIs aren’t exactly real estate, OK? So good API providers aren’t like landlords who charge for unused square footage. They won’t hold you to X number of API requests per month. They’ll charge you only for what you actually use.

Fine. So, how can you ensure comsec without communications APIs? Easy! Just keep it all on premises and only share information by inviting users to visit you in a secure room at your HQ. 

JK.

No, seriously—using even one communications API is a better choice. Why? Because of a phenomenon called the planning fallacy, i.e., what looks easy to implement and secure will take far, far longer than it seems. You contracted one developer to build your app, now you need to contract another developer who specializes in securing the app’s communications. Then you need to sign a contract with every single operator in every country your app will be used in(!) so you can deliver in those territories. And with all these players, what if you have a data breach? Whose throat do you choke? Good luck answering that. Even if you do, how do you figure out the source of the breach before you choke that throat so you can prevent it from happening again? 

Again, the Only Game in Town for the Comsec of Telehealth Is Secure Communications APIs.

Why do I think these APIs are the only choice for a CISO like me? This:

Illustration of a person standing knee-deep in a computer monitor with thoughts of video, voice, and more circling their head
  1. They’re easy to switch off and/or swap out if they’re not working for you and/or when you find one that’ll serve you better

  2. All secure communications APIs in a suite are built on the same model and follow the same rational billing logic. That means that any one communications API you invoke will be tracked and reported on in the exact same fashion as the other communications APIs in the suite, which gives you better reporting and consolidation capabilities—and better communications security!—because you can share information based on API keys and conversation IDs

  3. These APIs help providers securely reach the most patients possible, without favoring one method of communication over another (e.g., messaging vs. video, video vs. voice, etc.) 

  4. These APIs let providers quickly update and change patient data without having to worry about clerical errors, tampering by unauthorized parties, and more

Thanks to all this, you shouldn’t need long installation times to dramatically improve the security profile of your telehealth offering! 

And Guess What.

As rough as the pandemic has been on virtually all aspects of our lives, it’s also forced CISOs like me to ratchet up communications security whether we wanted to or not. For the longest time, when it came to authentication and security, my fellow CISOs were willing to build their own code generators to control inputs and outputs of code. But then COVID-19 hit and authentication became more urgent than ever, especially for video. CISOs realized that since the code generator would be hosted outside of the app, the chances of being compromised by someone hacking the code generator were basically nil. And so my peers started using verification APIs, which allowed them to implement two-factor authentication outside the scope of their app.

Back to why some folks who know about secure communications APIs don't use them. That bit about being anxious about putting their communications in the cloud.

These folks wring their hands and are like, “Is my data readable in the cloud?” 

What a tragic misconception! Because a good API vendor won’t store any personally identifiable information (PII) or PHI in the cloud at all. Call detail records, maybe, but the PII and PHI my telehealth app handles sits on my network in my on-premises database. The API vendor has no reason to host it for me.

What’s more, some folks can’t get on board with the idea of securing their communications with APIs simply because some folks are impatient. “I don’t have time for that!” they say. But that’s hogwash. Depending on the complexity of your workflow, integrating an API (after a few initial quick meetings with your API vendor) could take literally just a few minutes.

Perhaps some CISOs are nervous about the idea of downtime. I sure was. Downtime? What?! No!

Zero Downtime for Me, Thanks! (or Very Close to It!)

Illustration of a computer monitor with an error screen that's being rained on by a cloud

Thankfully, there’s at least one vendor who creates virtually no downtime at all. Just the very mention of downtime gives me the heebie-jeebies. But we live in a world where your API vendor—if they know what they’re doing—can give you five nines availability (i.e., 99.999 percent uptime). 

Here’s what it comes down to: When an API vendor wants to work responsibly in the cloud, they need to follow the rules of the cloud: high availability, elasticity, and no downtime. How do they obey those rules? By maintaining a single API delivery platform that connects users to all the telecom operators, testing it like crazy to ensure five nines, and ensuring that when they upgrade part of that platform, only some functionalities get affected (at most), and the rest of the platform remains live.

None of those details interests me very much, to be honest. I just want to know how much all this zero downtime will set me back.

The price tag. It’s always there. Good APIs aren’t free. But if you get a good API vendor who knows what they’re doing, you’re going to save a lot of money securing your communications. At least, you’re going to drop less cabbage than what you’d drop building your own telecom infrastructure, buying hardware, maintaining software, setting up contracts with all the telecom vendors in the world, and making sure that your home-grown abomination is compliant with security requirements like HIPAA and HITRUST. (And you’re going to spend more time focusing on your app’s users, too!)

Is it time for us to get down to brass tacks? For real: It’s riskier and costlier to shirk secure communications APIs than to spend your budget on some. While I don’t want to drop numbers here, it’s like this: Think about the security and maintenance budget—which is separate from, and additional to, your telecom budget—versus the per-minute cost of securing and running your telecom, and the delta you get is basically the cost of not using these APIs. You might not need the whole suite of APIs listed above to have great comsec. But if you don’t have great comsec because you’re not using them, I suspect the dollar impact in the coming years for your business will be gut wrenching.

What about these APIs’ impact on my emotions? Is that a weird question? Maybe. But knowing that my app’s users’ communications security is sound, I can finally sleep at night.

And I Know I’m Not the Only One Who Feels This Way.

Hey, in my time as a CISO, I’ve had some moments when I’ve given my CEO security assurances that were less than, um, ironclad. That’s also part of why I avoided taking communications APIs seriously for so long—my flimsy assurances worked

But at one point in recent years, I realized that privacy and security were non-negotiable, that there was a big danger in having our providers and patients connect via an app if all we were using was publicly available web APIs from one of the big-name (you’d recognize it) proprietary telecom apps, especially once I actually read HIPAA’s FAQ on telehealth. If I wanted to stop lying to my CEO, I needed to go with the best secure communications APIs available. Period.

And so when I chose to ditch publicly available web APIs and adopt secure communications APIs to enhance our security, I invested a lot of time researching vendors and decided to go with Vonage.

Let me give you an idea of what to expect with Vonage. First, you’ll speak to a salesperson and identify your app’s use case. Next, you’ll chat with a solution architect who will work with you to figure out which countries your app needs to work in, compliance and regulatory requirements, how your app and Vonage’s APIs will work together, and how to minimize the complexity of your app, maximize its effectiveness, and keep costs under control. After that, you’ll meet with a project manager and a customer success manager to determine any additional functionalities that could be added on top of the Vonage platform. And: 

All of These Meetings Will Be Quick Calls Over the Phone!

And Vonage offers workshops! You know a vendor wants you to succeed when they throw frickin’ workshops for you. 

Vonage will bring all the relevant people on its team and yours into the same room (or virtual room). This ensures everyone’s on the same page, that no one has any expectations that are unrealistic, and that—if anyone has any expectations that conflict with anyone else’s—those expectations can be reconciled with one another. After all, not everyone thinks alike! 

Then, once everyone’s expectations are managed, Vonage will crunch the numbers and give you a quote. That’s where the pricing negotiations begin. You and Vonage will work together to figure out a number that makes sense—one you’re totally satisfied with.

Oh, and Vonage won’t oversell you either. (I actually tried to buy too much, and they stopped me cold. “You probably don’t need that particular API,” they said. Amazing!)

And Voilà!!!

As soon as you’ve implemented your project, you’re ready to sign up an API key. That’ll wrap up in a couple days or so. 

You’ll want to square away some QA work, too, but after that:

Your App Will Be Ready to Call on Your Vonage APIs!

Again, there won’t be any downtime for your app or other APIs your app’s already calling out to because Vonage’s API delivery platform works independently from your app. But the capabilities it can deliver? The enhanced security? I just can’t overstate how extraordinary it all is!

Just so you know, Vonage already helps thousands of companies in all industries do the sort of things I’ve described here.

And Vonage has salespeople all over the world. You can connect with one by calling +1 (844) 365-9460.

Illustration of people at desks using computers and smartphones beneath ellpises thought bubbles

If what I’ve talked about here hits home, get on the horn with Vonage ASAP. Vonage has customers everywhere clamoring to give their apps the advantages of Vonage’s secure communications APIs, because not only is Vonage a top choice for providing them, it’s also got a bunch of smart cookies on its staff that are constantly dreaming up ways to help developers deliver innovative products. You’re going to want to get Vonage working for you before your competition does. (And they surely will—soon!)

I realized something else the other day, now that we’re months and months into using Vonage’s APIs. I don’t feel icky making promises anymore. I can adapt our business model to changing market conditions without impacting our telecom costs. Without investing in specialized resources. Without running up a bill for my CEO. I’m no longer one security breach away from the unemployment office. I don’t have the sword of Damocles hanging over my head anymore. 

Want to talk about security?! Let’s talk about that!

It’s Time to Secure Your Communications: Connect With Vonage Today!

Vonage Staff

Deskphone with Vonage logo

Speak with an expert.

US toll-free number: 1-844-365-9460
Outside the US: local numbers