If we had to pick one cybersecurity mantra to cement in our collective minds, we’d likely pick, “Your security is only as strong as your weakest link.” Say it out loud, perhaps think of the most annoyingly catchy jingle you know, and sing it to that tune. (If that worked, we’re equal parts thrilled and very sorry it’s now stuck in your head.) It’s a good rule of thumb for any cybersecurity approach. That said, it’s easy to think your cybersecurity responsibilities only exist inside a virtual wall around your office. If you use any cloud service—and we’ll bet you do—then you’re part of a shared security model. This means that both you (the user) and the cloud provider are accountable for the system’s overall cybersecurity.
Now, don’t panic. You’re not suddenly realizing that AWS’s security hinges entirely on your password practices. But you do play a part in your cloud security framework.
Since you can’t hoard the keys to the cloud, everyone with access has to pitch in to keep it secure. So as a cloud user, what are your responsibilities? The too short answer is: everything directly in your control. For the longer version, check your specific provider agreement. Shared responsibility language is fairly synonymous across the board and vague enough to allow broad interpretation. (And if “vague data privacy language” rings a bell, five points to you!)
To best understand your place in the shared responsibility security model, it’s most important to know which cloud service you use: SaaS, PaaS, or IaaS.
We’ll start with the easiest one. Well, maybe we should say “clearest” instead of “easiest.” With an Infrastructure as a Service (IaaS) cloud model, most responsibility lies with the user. On the bright side, the responsibilities are pretty clear cut between provider and user. The cloud provider handles the physical infrastructure that makes everything run—think Amazon EC2, for example. The user handles everything else, from the apps built upon the hosted hardware to connected data. While your work is certainly cut out for you, the “Wait, do we handle this or do they?” gray area is significantly diminished.
Things get a bit more mixed when you subscribe to a Software as a Service (SaaS) cloud model. You didn’t build the software in use, so it’s not entirely on you to maintain security at the operating level. It is on you to maintain basic cybersecurity practices. Take Google Suite, for example. Gmail warns you when emailing an unknown contact. You have to grant access to Google Drive files before others can see them. Google handles the software security, and you ensure that your sharing settings are appropriately limited.
Platform as a Service (PaaS) is the trickiest of the lot. It’s not as hands-on as IaaS and not so simply hands-off as SaaS. Hooray, a cybersecurity twilight zone! As a result, this particular cloud service calls for extra careful reading when negotiating a shared responsibility agreement.
With PaaS, you build on top of the cloud provider’s operating system and existing software (as opposed to the IaaS model, where you build those yourself). Everything specific to your apps is in your hands—including testing, deployment, and patches. The cloud provider maintains the base platform’s security, and you handle your apps’ security so that neither messes with the other. For example, OnSIP offers PaaS. Because we built our platform from scratch, we made it available to developers. They can build their apps on top of our software infrastructure, completely separate from the OnSIP app (the SaaS offering you know and love).
Congratulations, you’re a trendsetter! Like other on-premise systems, your private cloud is entirely your security risk. Risk, responsibility, sacred duty to protect—whichever term floats your boat. The parts of your business in the public cloud, however, do tie you into the shared security model, and that’s where you need to carefully check out the specifics.