Gateway Port config locking

We discuss security on all products that connect to our network quite regularly. Unfortunately, it isn't as easy as user levels within GCE, or more appropriately current products like Net3 Concert. This would actually require the user levels and protection in each end device. If it is done within the software, anyone could easily download a new installer and have access to everything. It is something we hope to consider in the future, but as you might expect it's not a trivial task. I am quite glad to see some request for it, as this helps validate the need so we can prioritize to potential work.

+1 for security features. I, too, have run into the same scenarios occasionally, and the frequency of those seem to be increasing.

+1.  Consultants ask for this all the time.

+1 For that also.... I completely agree that there should be user levels!

Not only for security reasons, but there is one Net2 node in the system I used to work on that, on a config change request, would black out the houselights and work lights.

A simple way to lock its config and exclude that node from the "Send config to all" menu would have been great.

-Todd

bpalmer said:

We discuss security on all products that connect to our network quite regularly. Unfortunately, it isn't as easy as user levels within GCE, or more appropriately current products like Net3 Concert. This would actually require the user levels and protection in each end device. If it is done within the software, anyone could easily download a new installer and have access to everything. It is something we hope to consider in the future, but as you might expect it's not a trivial task. I am quite glad to see some request for it, as this helps validate the need so we can prioritize to potential work.

Well, would it be possible to possibly make such a device "invisible" or "read only" as a profile choice via the config software?  Once that config is uploaded to the device it disappears or becomes non-editable in the software.  Typically I have these devices in an equipment rack, or a dedicated enclosure near the fixtures being controlled.  If it able to be invisible to the config software, or perhaps could have it's visibility or read only status turned on or off at the front panel, similar to resetting the IP or changing from Net2 to Net3  This would at least make it a bit more challenging to those who may want to change the system through either ignorance or maliciousness.    The more I write this, the read only status as a mode that can be engaged via config software, but can only be disengaged at the device itself does appeal to me more.

While a port by port option for read only status would be nice, read only as a whole device option would meet my immediate concerns.

As much as we would all like our network "works of art" to be locked down like fort knox.  I'm not convinced that in the heat of troubleshooting or system rescue that this level of security would be 1) beneficial or 2) helpful.  I know plenty of end users that have access to all of the same codes to root access as the ETC service techs.  I guess I see it this way, if someone wants to disrupt the system, how much work do you want to have to put into rescuing the system?  Its like computers, you can protect the system all you want until someone gets their hands on the box.  At which point you can reformat the drive and all the blessed security is null.

You can only idiot proof something until they make a better idiot.

Glenn

I completely agree on if someone wants to disrupt a system they will.  I see this less as a problem in this instance.  I see security as not to make something tamper proof, but to make it harder for someone to accidentally change a working config without intentionally doing so.  The pass-code doesn't have to be complex.  In fact it could be the same pass-code as it is to configure network settings.

I have a huge concern with network security at present. I work at a university with 2 venues currently networked up, multiple dimmer racks, consoles, access points and remotes, architectural control processors and Net3 gateways.

At present, there's nothing to stop one of our inquisitive students downloading a copy of concert, plugging into my network and changing device configurations.

There needs to be some default read-only access level or a way of making devices un-discoverable on the network.

I've a friend in a receiving venue and he's already had issues with a touring show coming in and changing his venue network configurations without permission.

Concert is a great tool, but in the wrong hands can be disastrous to a venue.

My venues would also benefit from some ability to "restrict" gateway config changes, particularly for architectural fixtures/controllers. In my case, it's just to prevent authorized users from accidentally changing the wrong config (You would think naming a gateway "TH AMX - DO NOT CHANGE" would do it)

The ideas mentioned above, the protected IP fields in GCE, read-only status disabled through the faceplate, or something like adding ":RO" to the end of a gateway name and having all copies of GCE acknowledge that, until the name was changed or the protected IP password was entered, would really help.

As a last resort, would moving the gateways to a different address space cause significant issues? For instance, putting architectural gateways on 192.168.1.0, assuming it's a typical flat unrouted, non-igmp ETC network?

Thanks

In that kind of network the sACN levels will traverse between subnets, but configuration and feedback will not.

So assuming there's no requirement for RDM feedback from those Gateways, this will work.

It will make the views in GCE a little confusing though, as it will be able to detect that the Gateways in the other subnet exist, but won't be able to connect to them to download their current config, so will display the 'factory default' settings instead of their real ones.