Security and the Security Tool GUI

Not aimed at any specific vendor, because there are so many that have issues with their GUIs for their tools, I might just have to rage against all of them. It drives me up the wall to see tool after tool with a security flaw in it. I’m a security professional: I should be using tools that are secure themselves, right?

First rant is for java. I remember attending one session at a security conference where the presenter, a pen tester, asked the open question, “why are so many people using outdated, vulnerable versions of java?” The response? The latest java versions were incompatible with the tools we engineers have to use. Many of us have to create schemes in which we balance multiple java versions on one device or have devices dedicated to a particular java version.

I know that vendors want their development teams to be just-in-time mobile scrums of yak shavers, which means there likely aren’t any developers tasked with keeping the GUI up to date with the current java version. Or, if such creatures exist, they are woefully under-somethinged, thereby preventing a timely release of that GUI. Under-budgeted, under-staffed, under-skilled, under-somethinged.

And it’s not like switching to a web interface is any guarantee of successful security. Developers are still dropping the f-bomb on all us engineers: Flash. They are blissfully unaware that some browsers won’t even allow flash content to display. Yes, I do confess I really like colorful displays that make the most of my massive monitors, but I feel oh so guilty about enjoying them when I know that it’s a flash plugin delivering that content to my one pane of glass.

And who would have thought that the browser wars were alive and well and living in security vendors’ dev teams? We recently got slammed with an issue resulting from using one particular browser to edit a table in a product. The issue? Complete wipe of the database.

When we connected, there were no warning notifications that, if we were to continue, we would risk destroying all our information. The product let us in and allowed us to shoot ourselves in the foot with a rocket launcher. Adding to the irony was that the browser we used was supported in all previous versions of the product, but had been discontinued with this incremental upgrade, with no fanfare about it.

Even more irony was that if we had used the one supported browser, we would not have been able to edit the field that we edited because it would not display in that browser without configuring some other settings to allow it to display…

And then there’s the simple matter of https certificates. Now, quite a few vendors actually make this a doable thing for their products. But then there are others that leave us using just their self-signed certificate, with little or no facility to import another commercial certificate so that we don’t have to click through security errors… or get shut out entirely by untrusting browsers.

And before any switch jockeys out there say that it serves me right for not using the CLI, let me point out that security tools do offer some configuration functions, but are more useful for their ability to analyze data. Graphically. As in, allowing us to make connections by seeing the data in a usable format. If said switch jockey wants to insist on the CLI, he is free to view Netflow data for 5000+ switches via a console session any time he so desires. As for me and my teammates, we will choose the GUI.

But please, security vendors, don’t leave us cringing every time we do so because we know the product is wide open AND it has no hope of being fixed anytime soon. Please give us something that we can always be using with confidence, even if it means we have to wait a week or two for the patch to be released – at least we’ll know it’s being released.

Source: Peerlyst