Security is top of mind within IT departments…especially lately. We’ve seen many headlines about breaches happening across corporate America and we just heard about the Solarwinds breach — one of the most sophisticated hacks in the history of IT hacks.
Despite IT security making the headlines again and again, one often overlooked aspect of security breaches is that, according to several reports and analysts, over 40 percent of these breaches actually occur internally (meaning that they happen from within the organization whether accidentally or deliberately). When it comes to protecting our systems internally, it’s crucial to ensure that the right users have access to the right parts of the system. This is especially true with network documentation or DCIM software as they do, after all, hold the keys to a big part of the kingdom.
In a DCIM or network documentation system such as netTerrain, you may have different parts of a project that should only be granted access to specific users.
Let’s say, for the sake of example, we need to limit access for the physical networks to a certain user or a group of users in the following way: read-only for the network room and edit permission for the Layer 3 IP/MPLS network, and no access to everything else…is this possible? Yes: in netTerrain, it’s easy.
Grant or restrict certain types of access based on project type
While it’s important to ensure that a DCIM system has baseline security aspects in place, such as supporting Active Directory, supporting multi-factor authentication (MFA), being FIPS compliant, SSL and so on…granularity granting access to different parts of the project is a big piece to the security puzzle and shouldn’t be overlooked. To this end, let’s put netTerrain’s granularity to the test: in this blog (and corresponding video), we’ll create a user that’s part of a group that has different role levels (depending on which part of the project they’ll be accessing).
1. Create a New Group & Assign a Default Role
First, we’ll head over to the admin console and create a group. We’ll call the new group “Group_10”. In netTerrain there are eight different role levels and assign the baseline default role level for this group “Editor”.
After you create a new group, choose the default role
Because we assigned the default role level “Editor”, this group will, initially, have editor-level access to every part of the project.
2. Assign a User to the Group
Next, let’s assign a user, call it “User10”, and assign the password (the rules for password creation, number of characters, types of characters, and failed logins can be configured in the netTerrain server or they can be inherited from Active Directory if applicable).
Add a new user to the group
3. Assign Role Exceptions to the Group
Now that the user is set, we can assign some exceptions to this group: all of the users that are part of this group will inherit those exceptions (but you can do this on a per-user level as well). We’ll grant read-only access to everything in our project except for the networks themselves, which are going to, at the top level, inherit the editor role.
It’s easy to specify exceptions and restrict permissions
We’ll specify we want this group/user to have read-only access to the network room GN office and no access to everything else.
Did it work?
4. Putting It All Together
I’ll log in as User10 and head over to the physical view. As this is a new user, a learning wizard pops up to help with onboarding. Great. Now, if I click an object…any object at all…it’s disabled for editing. As User10, I actually can’t edit or insert any objects. If I click on objects, I also can’t really delete them. If I go to the networks, where User10 does have editor permissions, and head over to the layer 3 IP/MPLS, my insert buttons are enabled as well as the properties when I click on an object. This is exactly what we wanted to achieve. Additionally, some of the Clouds we saw previously have now disappeared because, as User10, I don’t have access to them. Mission accomplished.
In sum, to ensure that the proper stakeholders access each part of the project with proper permission levels, you can take advantage of exceptions in netTerrain when you’re the administrator assigning permissions to users to ensure that, at a diagram level, all the users have the right permissions. This is valid for all of those different role levels down to even the device level. Hopefully, this provides a good summary of how netTerrain manages exceptions to minimize the risk of data breaches or data corruption in a DCIM/network documentation project.