Be a great network landlord and keep your visibility tenants happy!
User access management has always been and remains a top concern for security professionals. Starting from changing the default “admin” password, to hardening the serial console access, to creating Role-Based Access Control rules, there are necessary steps to take to secure your network devices while ensuring all stakeholders get the access they need.
Have you ever wanted to give each user the exact access he needs to perform his duties based on his role, no more, no less? Have you wanted each user to see what traffic is going where, strictly on a need to know basis?
That is why in this blog post, I will cover Role-Based Access Control (RBAC) and how it functions as a balance between security and manageability of Vision Network Packet Brokers (NPBs). RBAC is not a new functionality in NPBs, in fact it’s been there for a pretty long time, which we can trace back to pre-Ixia’s acquisition of ANUE. Most of our NPB users have probably noticed the way it works:
Say Alice is the all-powerful administrator of an NPB, while Bob and Charlie are humble owners of individual monitoring tools. Let’s say that Bob owns Tool B and Charlie owns Tool C. Bob and Charlie both want management of the NPB so they can pull the right traffic to their tools. This is easy, Alice just has to give them both access rights. Can she just share the admin password with Bob and Charlie? Not likely, because then Bob might accidentally use Charlie’s ports, or vice-versa. So then, Alice creates a user Bob and a user Charlie, and assigns them to groups B and C, respectively.
She then assigns ports, say, 1-10 to group B and 11-20 to group C.
Bob and Charlie should be happy now, because they each got their own slice of the NPB to use for Network Ports, Tool Ports and carry traffic to their tools.
One notable enhancement in the history of RBAC, launched in release 4.8.0, is true “multi-tenancy.” To illustrate the importance, imagine what can happen if, let’s say, Bob and Charlie are sub-contractors from different companies, in a defense project where security is so strict that Bob and Charlie should not even know about each other’s ports, traffic, and possibly existence? Such a situation is defined as multi-tenancy – just as the name suggests, multiple users, “tenants,” require access to individual resources on the same appliance. Often, the access must be granted in such a way that each tenant owns the resource exclusively and in secret from other tenants. Before release 4.8.0 multi-tenancy, ports and filters could not be hidden from the view of other users. Likewise, the user who controlled the Network Port and Tool Port also controlled the Dynamic Filter between them automatically. That meant, however, that if ports P01 and P06 were shared between Bob and Charlie, then Bob could view and modify Charlie’s DFs and Charlie could view and modify Bob’s. Let’s see what that meant:
Before 4.8.0, here is what both Bob AND Charlie would see when they log in:
Even though Bob cannot modify Charlie’s DF, he could still see Charlie’s traffic filtering criteria:
And he (Bob) could change Charlie’s DF’s connections to tools, effectively getting full access to Charlie’s traffic:
Not very good news for Charlie, if his traffic and traffic filtering criteria, or traffic modification, must remain private ☹
After release 4.8.0, this can be securely avoided, by doing two things. The first, assigning view access rights to everything: ports, DFs and resources.
The second, by assigning individual owners to each DF, even if they share one of the ports.
After release 4.8.0, this is what Bob sees once he logs in (spoiler alert! he can see only his ports and filters).
Cool stuff, right? It got even better, with release 5.0.0! Inline is no longer the Wild West where any regular user can have his way and create, change or delete Bypass Port Pairs (PBBs), Service Chains (SCs) or Inline Tool Resources (ITRs). In release 5.0.0, the RBAC sheriff came to Inline town, and now every tenant is a civilized citizen with all the rights he needs to perform his job, protected against interference from other tenants. Inline now has full-fledged Access Control with Modify and Connect permissions – everything except View permissions, because we’d like to keep mission-critical traffic running in “View All” mode, for now, so your users don’t overlook an important SC, by chance.
Wrapping Up
RBAC improvements have made it a must-have, mission-critical solution for managing user access to all the objects of a Packet Broker, such as system settings, traffic sources, filtering and destinations, and traffic modification. And we are continuing to develop and enhance RBAC with every new feature we are adding to our visibility software so stay tuned to find out what’s next!