I was reading some other discussion here about how default passwords are handled, and it reminded me of some UI features/bugs/gotchas/bad design that may contribute to creating insecurity. Even if the intent was all good and the features are there, these could cause a situation where you inadvertently misconfigure something.
Instead of bashing the usual suspects, this time I have an example from Avigilon Control Center, 5.4.x if I remember correctly.
We had multiple sites with many servers in each, and cameras were grouped with folders. The thing that surprised me was that if you create a new user group, this group will by default get permission to every device. So you better fix that before adding users to the group. If you are not using folders, you will click on each and every camera to uncheck them if I recall correctly, because there wasn't an "unselect all" button, and even using folders it's very inconvenient. We had about a thousand cameras in the system, imagine the joy with just a single site. There were also some problems with Ranks apparently getting corrupted somehow, only showing '4294967295' (ie. 232-1) for everything. Fixing such issues in a big system is very tedious.
Also, any camera that is added is by default accessible to everyone until you deliberately uncheck the permission from every group, manually. If you have a hundred groups, there's a minimum of a few hundred clicks to sort it out. Very easy to forget too and I thought this 'feature' in particular was a crazy design choice from Avigilon.
A third one, when arranging things in Site View editor, the UI is a bit buggy so that it's very easy to accidentally drag a device around without even noticing. At one point you may just wonder why a certain camera is outside a folder, or inside a wrong one, possibly also visible to the wrong person. Not good.
These are hopefully fixed in later versions, I don't know. I sent feedback and suggestions about these a few years ago to Avigilon, so I may also remember some details wrong, but this is just a small selection of those anyway. There were also fun ways to accidentally mess up your entire Site after updating from 4 to 5, by clicking okay on an uninformative dialog that ACC shows and asks if data should be converted. My wrist still hurts when thinking about fixing it.
Please share if you know some similar gotchas about software/hardware that are useful to know to avoid accidents.
Hazardous User Interfaces
I don't know if this example quite fits as 'hazardous' when it is more just terrible security, but there is a pretty simple way to force yourself into Lenel OnGuard as system administrator just by manually resetting the password to 'null' in the underlying/unsecured SQL database. This is a security issue with SQL that extends to OnGuard.
I tested this several times during our test of OnGuard and can confirm it works and is very easy to do.
It is so easy, integrator Convergint published it as a 'tech tip' for their people to use during system takeovers.
I am not familiar with OnGuard, but doesn't that assume that you have access to SQL Server in the first place? That is, I assume they are expecting you to lock down SQL Server to make the system secure.
...4294967295...
AKA - The current known maximum number of sides in a odd-sided regular polygon that can be drawn with straightedge and compass.
So I've read the above post several times and wondered how to respond to it. At first I thought this could be somebody intentionally trying to deflect the attention from those usual suspects which have been hugging the headlines but I'll won't go that road :-)
I think I'll keep it simple by stating that every major software 'leap' will unfortunately go hand in hand with a bug or two no matter how much beta and field testing is done. ACC4 to ACC5 was a really big step up with the usual gremlins which in later releases were all dealt with, as I suppose is what you experienced with ACC 5.4.x. Although the latter were more feature related than bugs. As ACC is ever evolving, ACC 6 has been released earlier this year which was another major release, features are constantly approved to accommodate as many (end) users and the vast majority of especially end users find it a very user friendly VMS. Keep sharing your feedback with AVIGILON as feedback good or bad is crucial for any manufacturer.
The reason I distanced Avigilon from usual suspects is that I actually think Avigilon's software is pretty decent overall. Still, during the years I contacted Avigilon support many times as our environment itself was complex enough to surface many bugs/inefficiencies in the UI. Many tickets, couple of hundred emails back and forth, mostly me explaining in massive detail what the problem was (always took hours to type the initial emails).
ACC was at that point at least (5.4) not the best in handling a huge number of cameras via the UI. Avigilon actually flew a guy over to us just to listen to my complaints and make notes (I think there were at least 25+ relevant items on that list). That's good customer service.
I still have the emails but I'll just trust your confidence that those issues may now have been fixed. I didn't intend this thread for bashing manufacturers anyway, but instead point out UI flaws that may cause accidents, regardless of the maker.
It sounds like your 'environment' was a really good live test of the ACC platform at that moment in time. When 5.4.x was introduced there were many systems out there consisting of 1000 cameras or more, some running ACC4 still and many changed to ACC5 when it was first introduced. I appreciate that not all transitions will be hassle free as stated in my previous reply. I still find 'hazardous' quite strong based on the actual facts you disclosed. I am confident that much of what you experienced, if not all, has been dealt with but I'm sure more posts will follow if this isn't the case.
What VMS are you currently using or would you use if a similar size system came up?
I don't currently work with camera surveillance, but should I ever do that again, I'd need to take a look at the current versions of the ones that can handle the scale. Avigilon very likely would be one of them. As I said, I consider it a pretty decent piece of software overall, and way beyond the other Big and Obscure VMS we were using alongside it, in almost every way. Our environment was very complex, heterogenous and geographically wide, with sites ranging from schools to particle accelerators and nearly a hundred different models of cameras installed at any time. Yes, it was a very challenging "live test" that understandably can't be tested in a lab setting in a realistic way.
But let's not turn this thread into "why Avigilon isn't bad" but instead share things that can accidentally cause problems.
Regarding my interpretation of 'hazardous', I'll just paste a portion of a support ticket from three years ago, so you can consider what I meant by messing up and exposing an entire Site with a single click and whether this is business as usual. This is not for bashing Avigilon but to keep on topic with the thread, but perhaps more detail is fine here, as this is an actual thing that happened and inspired me to start this thread in the first place:
Issue 1: Permissions for newly added devices and Folders *!!!!*
Consider the scenario: you have a server with no Site View defined (ie. all devices at "root") and you connect the server to a Site as a child. Every group gets access to all newly added cameras because they appear at the root of the Site. If I add a single camera to a Site, I could perhaps make a Folder "New cameras" or so to which only the admins have permission and point to it when adding the camera, but this is fundamentally backwards: no standard user should get any access to anything added to the Site by default unless the newly added server defined these permissions and the users that get them. This is serious because the admin must remember to check permissions for *every group* after a server is added, and failing to do so could - technically - lead to lawsuits in addition to embarrassment. It's a lot of clicking also.
This is mostly problematic when the added server has already been populated, as is the case with upgrading the version from 4 to 5 and connecting the sites together. Otherwise it just requires being very careful. One way to work around this would be to create a Site View to the server first, before connecting it to the parent Site, but as I said before, software like this should work on the principle of least privilege. We already have a dozen hierarchies we need to keep track of when admining this environment (Avigilon is but one of many) and things like this hurt our confidence toward the software and require us to double-triple-check everything.
*REAL WORLD EXAMPLE* Just as I was about to send this mail s**t hit the fan because of this issue (and other issues): my colleague was upgrading his other client machine (with an ACC4 Site View defined with his own layout for organizing the cameras into floors etc.). The upgrade asked apparently if data should be converted to the new version (I didn't see the dialog myself) and assuming it was just client settings he clicked OK. Well, his settings were integrated *site-wide* and suddenly there were roughly two copies of every building there (Folders), one with permissions set like they were supposed to, and these 'new' ones that were *allowed for every group*. Fortunately we noticed immediately what happened and I managed to fix it by first (tediously) removing permissions from all groups and then (tediously) rearranging the Site View so that the extra Folders were gone and only the ones with proper permissions were in place. The layout is now different since I didn't have time to move *every camera**one by one* to where it was before, as my colleague had a layout that broke out buildings into floor subfolders and every camera that was inside those was 'stolen' from the Folders I had there previously, so if I want that back I'll need to do a lot of clicking and dragging, once again. Now I just moved the subfolders within the folders that used to be there and had properly assigned permissions and then removed the empty Folders.
It is completely unacceptable to allow such to happen! If we hadn't noticed right away what happened - which is also easy to miss as the Site View allows two Folders with the same name to exist! - all of the cameras would have been exposed to pretty much all users of the site (around 25 accounts that are perhaps used by a hundred people) until perhaps tomorrow when we would have noticed it - and all the users would have had an interesting evening documenting all of our security with their phone cameras and we would be in trouble. We can only *hope* users didn't look too carefully at their device lists while this happened. While we generally trust our users to not do bad things, such might have been too tempting for some. In an enterprise environment this can wreak havoc and I urge you to fix this quickly so such can't happen, it is a frightening trap and at the worst needs only one careless click. There also is no 'undo' for it.
And I stress that if a client program asks something about converting settings, it is perfectly reasonable for a user to click OK, the way it operates now should require at least a couple of confirmation screens in bright red prompting if the user actually does want to mess up their whole site, with clear indication how serious an operation it potentially is. In ACC4 Site View was a local thing, you cannot just convert that into an ACC5 Site View on a whim as it will affect everyone!
There's an infinite amount of such issues in software in general, I could also tell in length about motion detection / recording issues with VMS UIs but I'd rather hear about others' experiences of these kind of issues, or similar ones with hardware for example (bad installation instructions resulting in fire or something).
(around 25 accounts that are perhaps used by a hundred people)
Do you consider this hazardous as well?
Not in this case, as these were typically workstations that were monitored by several people (portiers, night guards of whatever security company was contracted) at different times, and typically just kept logged in to keep an eye on in their (closed) spaces dedicated for the purpose. Typically an account or several was created per building.
Creating personal accounts for all of them would have been unfeasible to manage practically in this case.
A single account in the (Avigilon) system often represented several actual users. There were other ways to know who the real person using it was, if needed.
Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.