I recently sat down for an interview to share some of my thoughts about 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 the 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 becoming more sophisticated, and computing power continues 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 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 constantly evolves and improves. Even remaining “ever vigilant” is insufficient; our methods and techniques must evolve as the attackers do.
AI drives most attacks today and only improves as we adapt. On top of that, quantum computing will render almost all existing cryptography useless, and that’s only a few years away from 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, and 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 understanding how wide their organizational data boundary 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 data types 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… is not so simple. All of these can potentially impact 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 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, back office, CSOs, partner organizations, customer responsibilities...the list goes on. Choices made in or by any of these components inherently impact all others. 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 returning to this notion of the data owner. Who is the data owner? How are they given ownership over their data?
In the larger scheme, you encrypt the application layer through TLS-based encryption, whether WebRTC or SIP TLS. If you're using an older protocol like H323, the signaling protocols built into H323 are not encrypted, but that is a limit of the protocol itself. So that is a data or protocol choice 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), you obviously retain ownership of the session metadata. However, all of your virtual meetings are unlikely to follow this use case. Even in a fully on-prem environment, you will meet with a mission partner or public guests sooner or later. Then your organizational or session metadata may be exposed, to say nothing of a cloud environment or SaaS offering.
Organizations must make 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 computing 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.
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 any cloud data service, regardless of what it provides. However, video has two other unique issues we have to address.
The first is the notion that every single endpoint you don't control in your sessions will always collect call metadata. 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 know 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 a MeetMe zone, in which people from your organization dial into a remote call zone into which the far end is also dialing. The data 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 with protected access restrictions. And most importantly, you can set up policy rules whereby people from your organization can only call into your MeetMe zone. 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, which would govern who can access the MeetMe zone and when. Now you can take the same policy concept, create more internal locations and zones, and parse them ad infinitum.
I would always recommend some external zone capability for organizations that are most concerned about metadata. And all of that can still be managed as part of the core Pexip service you offer your customers.
Can metadata from video meetings be accessed by people not attending the meeting?
So that comes back to data ownership. If you restrict access to these zones, whether internal or external, you control what happens to them. To be clear, with the backend problem, you will never be able always to control what the other guest party or the far-end user is doing. You can control how they dial into you, but if you allow MCUs or neighbors to register with you, you have no idea what policies govern them.
There will be called 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 transmitted to those other parties. But because you are constraining how people access the system, you are constraining how those calls occur; they are getting a very limited and somewhat inaccurate depiction of how your organization works.
The other thing I would always do is be very careful about how I define guest policy right now. Some will be local to a session, but some will be more organizational. Organizations need to think about what they mean by the 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 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 think of their video conferencing system in the same light as their VoIP tool, email tool, and file storage tool.
They need to give it the same organizational protection and policy development level they grant to all baseline corporate communication systems because 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. Look at what we have, see if it's appropriate for you, and 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).
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.
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 the national origin concerns you, look at our Schrems II discussion when you can; 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 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 the only tool you ever use, but we want to be your best tool. 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.
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 you want to do some form of 2- or even 3-factor authentication. Cool, great. Here's the piece for that. Let's 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 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 will constantly be rolling out new features and capabilities, patching this, and fixing that. We have to be able to roll out these things faster and faster. We are an application built from a security perspective, which means that we will be even more responsive in terms of patching, fixing, and upgrading.
That's not all, though. For many products out there, security is static and is a maintenance-level thing. What I mean by that is you have an OS or application, you get your updates, run them, and patch them. Okay, fine, and then the new version comes out.
Companies are not rethinking their threat models with many products, especially hardware. They're not rethinking how to take an architectural approach to security. It's just "OK, we patched that thing," "That bug is fixed," and "That loop has been closed"—those types of things.
We are constantly reevaluating the threat environment at a tactical and strategic level. Some things, such as quantum-resistant cryptography or integrating with blockchain standards, take a long time to develop and implement. Those may be 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 this is a long-term development effort, but let's see if we can tie those other product features, 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.
- Meet & collaborate securely
- Secure Meetings
