I recently sat down for an interview to share some of my thoughts around which data security concerns organizations need to start thinking about (if they are not already) and how they can be addressed.
Here are the questions I was asked:
- Why is data security more important now than ever before?
- What do you see are the biggest security concerns for large organizations right now when it comes to data privacy?
- How can companies ensure that their video platform metadata remains private to their company?
- Can metadata from video meetings be accessed by people not attending the meeting?
- How is Pexip unique in how we approach security compared to other vendors?
- Some things to take away
Why is data security more important now than ever before?
The biggest structural issue we face is the proliferation of the global attack surface, due to the explosion in use of IoT and mobile devices. By 2025, it’s estimated that the number of IoT devices will outnumber traditional network devices by 3 to 1. All of these devices - and yes, that includes things like video endpoints, cameras, microphones, etc. - are now potential targets.
Image & Source: IoT Analytics: https://iot-analytics.com/number-connected-iot-devices/
Hackers are constantly becoming more sophisticated, and compute power is continuing its inexorable march forward. There’s a concept in biology called the Red Queen hypothesis, which states that organisms must constantly evolve to adapt to a changing environment just to stay in the same general evolutionary position (taken from Alice in Wonderland, where the Red Queen is always running in place but never getting anywhere).
That concept is very similar to cybersecurity - we can never say that we have “achieved” security, as the attack environment is constantly evolving and improving. Even remaining “ever vigilant” is insufficient; our methods and techniques have to evolve as the attackers do.
AI drives most attacks today, and it’s only getting better as we adapt. On top of that, quantum computing will render almost all existing cryptography useless, and that’s only a few years away becoming a consumer-accessible reality (nation-states are even closer to achieving that goal). In other words, we have to think differently about what security means. That means different architectures, different frameworks, different operational and business models.
What do you see are the biggest security concerns for large organizations right now when it comes to data privacy?
The first challenge for organizations is to understand just how wide their organizational data boundary actually is. So many of our basic capabilities are now inherited from third-party cloud service offerings (CSOs), whereas our concepts of data security are still based on the outdated notion that we have a network perimeter that separates “internal” from “external”. Data security rules and technologies vary wildly from vendor to vendor, and yet CIOs and CISOs rarely have a complete picture of all of the different environments with which their systems interface.
Another big need is for organizational leadership to define the different types of data that exist within their organizational boundary. Data isn’t monolithic; there are many different subcategories and parsing methods by which you can categorize data classes. For example, the simple question of data ownership… turns out to be not so simple. All of these can have potentially huge impacts on your data security policies and methodologies.
For example:
Does the customer own the data? Does the organization or a third party own it, or even an entity like a national government? Does the customer own some part of the data set, while the organization has incorporated proprietary data into the master? What rules govern each of those, and how do you determine where the dividing lines lie? Do you protect customer data differently than partner data or organizational data? Why?
And...
What special isolation or protection techniques must you implement for Personally Identifiable Information (PII) vs Protected Health Information (PHI)? What vertical markets do you support, and what unique data compliance rules govern them? Are you part of an external supply chain "(hint - yes, you are!)", and how does that impact your security?
Security is not a feature
I can’t say this loudly or frequently enough - security is not a feature. What I mean by that is, you cannot add an auxiliary or supplementary layer of security to your products or services and hope to have an even moderately effective data security model. Security must be incorporated into everything your organization does to combat the threats your organization and your customers face. Products, applications, networks, components, systems, personnel, backoffice, CSOs, partner organizations, customer responsibilities...the list goes on. Choices made in or by any of these components inherently impact all of the others. In order to have a comprehensive data security policy, you must adopt a “defense-in-depth” approach across all elements of the data plane, which, in turn, impacts every aspect of your business lines.
How can companies ensure that their video platform metadata remains private to their company?
The key here again is going back to this notion of the data owner. Who is the data owner? How are they given ownership over their data?
In the larger scheme of things you're encrypting the application layer through TLS-based encryption whether you're using WebRTC or SIP TLS or something like that. If you're using an older protocol like H323, it is true that the signaling protocols built into H323 are not encrypted but that is a limit of the protocol itself. So that is a data choice or protocol choice that the organization needs to make.
If you control the entirety of the session data exchange path (for example, if two on-prem organizational users use an on-prem infrastructure product like Pexip Infinity to have a virtual meeting), then obviously you retain ownership of the session metadata. However, it's unlikely that all of your virtual meetings follow this use case. Even in a fully on-prem environment, sooner or later you will be conducting a meeting with a mission partner or public guests, and then your organizational or session metadata may potentially be exposed, to say nothing of a cloud environment or SaaS offering.
Organizations must make their own risk management assessments of cloud service providers (CSPs) and CSOs. SaaS offerings, of course, like Pexip's, will always retain organizational data, while PaaS/IaaS offerings, such as Pexip Private Cloud, enable you to use external compute while retaining control of the bulk of your metadata. Even there, metadata such as usage volume, time of day, and access location information will be known by your CSP (after all, they're providing you the compute, so they know when you use it), so you'll want to make sure that your Service Level Agreement (SLA) describes how your provider is protecting and eventually purging that data. Always remember: All. Data. Has. Value. And it is yours. Don't give it away for free.
Ok, so you're thinking, "Sure, that's great, I've got all that." Well, there's another potential area of metadata leakage that I bet you're not tracking so tightly. What we've described above is true for pretty much any cloud data service, regardless of what it actually provides. However, video has two other unique issues we have to address.
The first is the notion that every single endpoint that you don't control in your sessions will be collecting call metadata at all times. They have to do this -- all video communication is, of course, data, and data about data is what metadata is, after all -- but there are steps you can take to minimize or limit the extent of the metadata you're revealing. You should always have strict access control policies for your sessions, ideally controlled by an external organizational policy stack tied to a strong Identity and Access Management (IdAM) service, whereby you have high confidence in the identity of the far end systems and personnel with whom you're conversing. You can also take architectural steps to mitigate this, and conveniently, that approach also addresses the second unique video metadata concern: what we refer to as the Backend Problem.
To understand the Backend Problem, let's say I'm conducting a virtual meeting somewhere in my Pexip Conference Node stack. I'm talking to a mission or business partner Multipoint Control Unit (MCU), which could be Pexip or some other product, and they have some number of endpoints -- or, critically, other MCUs or gateways --- attached to their MCU. You will never have any true idea of who or what is on the "back end" of the partner MCU. It's like the dark side of the moon -- we know it's there, but we can't see it. It could be anyone or anything, and you don't control that -- but whoever they are, they will have access to your session data every time you talk to them.
So how do you deal with that?
One way is to essentially classify all of your video sessions based on who is participating in them, so that you essentially locate those particular conferences virtually, or even in some cases physically, outside of your boundary. This is what we call a MeetMe zone, in which people from your organization are dialing into a remote call zone into which the far end is also dialing. The data actually doesn't occur inside your core environment. You are dialing out from your core, they are dialing out from their core. So it protects your information and it also protects their information.
You can set that up in a different cloud if you're already in the cloud, you can set it up in a cloud if you're on-premise, or you can set it up as a separate zone within your cloud, but one that has protected access restrictions. And most importantly, you can set up policy rules whereby people from your organization can only call into your MeetMe zone, and of course people from the far end can only call into that zone based on whatever set of restrictions you want. It can be a time of day, certain users, certain types of devices, etc. You can define that in your external policy stack and then that would govern who can access the MeetMe zone and when. Now you can take the same policy concept and create more internal locations and zones and start to parse them ad infinitum.
For organizations that are the most concerned about metadata, I would always recommend some kind of external zone capability. And all of that can still be managed as part of your core Pexip service that you are offering to your customers.
Can metadata from video meetings be accessed by people not attending the meeting?
So that comes back to data ownership. If you are restricting access to these zones, whether they are internal or external, then you control what happens to that. To be clear, with the backend problem you will never ever be able to always control what the other guest party or the far end user is doing. You can control how they dial into you, but if you are going to allow MCUs or neighbors to register with you, you have no idea what policies govern them. There will be call detail records (CDRs) and metadata generated by that and that's why locating these, again, in a separate zone or restricting access to certain conditions or certain devices, allows you to constrain the metadata that would be transmitted to those other parties. But because you are constraining how people are accessing the system, you are constraining how those calls occur, they are getting a very limited and a somewhat inaccurate depiction of how your organization works.
The other thing that I would always do is I would always be very careful about how I define guest policy right now. Some of that is going to be local to a session but some of it is more organizational. Organizations need to think about what they mean by guest policy. Does it mean that literally anyone can dial into any of their property rooms anytime they want? If that's a risk that you are willing to accept as an organization because it helps you from a business case perspective, go ahead, but make that choice as a choice. Recognize that that's what it is, because there is definitely a tradeoff there. If you are an organization that wants to be able to communicate with mission partners, then set up SLAs with them about how to do this.
Organizations need to have a much more programmatic approach to these kinds of things. All too often, video is still thought of as a luxury feature, rather than a critical business enablement tool. As we continue to shape our new global communications reality, organizations need to be thinking of their video conferencing system in the same light as their VoIP tool, their email tool, their file storage tool. They need to be giving it the same level of organizational protection and policy development that they grant to all baseline corporate communication systems because, really, that's what video is.
How is Pexip unique in how we approach security compared with other vendors?
We have what we would consider to be the most flexible array of deployment options. Take a look at what we have, see if it's appropriate for you, see if it meets your organizational risk policy.
If you choose our self-hosted solution, Infinity, then you own the compute, you know how much compute you're using, how much you're spending, etc -- in other words, you own your metadata. You can deploy on-premise or anywhere else you want (although, as noted above, be mindful of metadata generated by external compute platforms).
All that said, the real power of Infinity is our extensive block of APIs and the policy stack architecture, which allows you to codify and automate workflow(s) as a set of formal video policies. We have built a lot into the basic Infinity management capabilities, but if you want the ability to define your own and you want a unique form of authentication, validation loop, or some particular set of constraints or permissions or integrate it with a Zero Trust architecture like we've talked about previously ... well, go ahead, build a plug-in or policy stack. All policy is, really, is data management. It's how you are governing what happens to that data, which again, is yours, because you are the ones generating that content.
If you'd prefer a shared service, the Pexip Service leverages best-in-class industry standards for communication encryption for meetings and end-user devices, such as FIPS 140-2-compliant encryption, as well as mandating full ISO 27001 data security compliance, SOC2 compliant datacenters, and all the good security stuff you've come to expect from us. As I noted before, we will always have access to some data for operational reasons, but we are GDPR-compliant and will never sell your data to a third party. If national origin is a concern for you, take a look at our Schrems II discussion when you get a chance, and, as always, please ping us. We love to talk about security. (This interview is a case in point!)
For organizations who want control of their data but don't want to host it on their own premises, Pexip Private Cloud is an option where we can own the compute but you can own the management node, which is the "brain" of the operation. You own and distribute your data and you control where it goes.
As a software-based product, we have always said that we probably aren't going to be the only tool you ever use, but we want to be the best tool you ever use. We don't want to define your workflows for you. You know how you conduct your business better than we ever possibly could. So we don't want to ever be in a position of forcing you to change that. All we ever want to do is insert seamlessly into your business process.
That said, we aren't just saying, "OK, here's a thing, call me when you've got this done." We know this is complicated. If you prefer, we would LOVE to work with you to identify what's possible and help you put something together. Again, maybe that's zero trust, maybe it's a monitoring system. Maybe it's some form of 2- or even 3-factor authentication that you want to do. Cool, great. Here's the piece for that. Let's go make that happen.
Some things to take away
There is very much a sense amongst organizations of "okay, we've done that, now let's move on." Yeah, that's not how security works. Security is not a goal. Security is a process and it is baked into our DNA, into our Software Development Life Cycle (SDLC). It's built into our basic corporate structure. We as an organization have a very sophisticated SDLC, because we know that as an application, as opposed to a hardware-based product, we are going to be constantly rolling out new features, new capabilities, patching this and fixing that. We have to be able to roll out these things faster and faster. We are an application that's built from a security perspective, which means that we are going to be even more responsive in terms of patching and fixing and upgrading.
That's not all, though. For a lot of products out there, security is kind of static and is a maintenance-level thing. What I mean by that is, you have an OS or application, you get your updates, you run them, you patch them. Okay, fine, and then the new version comes out. With a lot of products, especially hardware, companies are not rethinking their threat models. They're not rethinking how to take an architectural approach to security. It's just "OK, we patched that thing," "That bug is fixed," "That loop has been closed". Those types of things.
We are constantly reevaluating the threat environment, both at a tactical and a strategic level. Some things take a very long time to develop and implement, such as quantum-resistant cryptography or integrating with blockchain standards. Those may be far, far down the road, but we're looking at them and thinking about them now, so that we are ahead of the curve if and when. And we on the security team are empowered and encouraged within the organization to raise our hand and say, hey, we would like to see these things happen. We know that they're going to take time. We know that this is a long term development effort but let's see if we can tie those two other product features, or business cases, or use cases together, and allow them to do x, y and z.
Security is a continuous process. It's an iterative process, not a goal or a destination. You don't achieve security - it's just something that you do. All day, every day.
Learn more about Pexip's secure video meetings solution.