Perimeter
2/8/2012
02:41 PM
Commentary
Commentary
Commentary
50%
50%

I'm Sorry I Called Your Baby Ugly ... But It Is

Your product's user interface may not be as appealing as you might think -- and it might just be jeopardizing its adoption

I like to use technology that is intuitive, solves a problem, and is a "fit" for me. On the other hand, I also like technology that is aesthetically pleasing. Some vendors have managed to deliver on my requirements, which is why I own several Apple products, buy the same brand of suit, and rarely drink domestic beer. But when it comes to security products -- namely the user interface (UI) of security monitoring products -- I am often disappointed and left wanting.

I speak to numerous vendors across different product sectors on a daily basis, so sometimes my disappointment in their UIs squeaks past my gritted teeth. I do my best to provide constructive criticism based on what I hear from customers, friends, and similar vendors, but the receiving vendor often takes offense. I understand. I called its "baby" ugly. Unlike an ugly baby whose appearance is usually beyond the control of its parents, security UIs can be made better.

Why make a UI more aesthetically pleasing? Well, for one thing, if a user can form a connection with the product, then he'll likely learn it quicker. We, as humans, tend to gravitate toward things we like and distance ourselves from those we don’t. If a provided interface is off-putting, how do you think that might impact the user’s learning curve and subsequent adoption?

Another reason is that many security monitoring products have become indistinguishable. I often say that you could take any SIEM vendor’s product marketing materials, strip any mention of its company or product name, and customers would have an extremely hard time assigning the correct company name to the associated materials. Since security monitoring vendors have done little to differentiate themselves, choosing instead to battle for competitive parity, why not innovate the often touted "single pane of glass?" Perhaps it's time to change the way we force users to interact with products.

I mentioned in my previous blog post -- "Where's My 'Minority Report' Dashboard?" -- that ever since I first saw the movie Minority Report, I’ve been waiting on the edge of my seat for a SIEM vendor to emulate the UI employed by Tom Cruise to solve crimes. I’m not saying that a UI of this nature would make a SIEM product more technologically capable than its closest competitor, but it would almost certainly add a bit of shine and differentiation in a product sector that’s quickly approaching commoditization.

Revamping a UI is not only an expensive undertaking, what with customer requirements gathering, design, development, and testing cycles, but it may also be considered a distraction from a vendor’s technical road map. So how do we balance some "UI bodywork beautification" without drastically impacting other core deliverables? Nearly every security product vendor leverages computer and, sometimes, electrical or mechanical engineering students in a work placement or cooperative education capacity. Not only does this provide inexpensive labor for menial tasks within the organization, but it may also serve to entice the student to come back to the company upon graduation -- providing a semi-trained resource already indoctrinated in the company's culture and processes. What I have yet to see, however, is a company bringing in design students to help overhaul, or even iteratively update, its UI. Sure, you could likely go to Starbucks, throw a rock, and hit five people capable of redesigning your product’s UI, but why not use students who are hungry to prove themselves in the real world? I assure you that the cost savings would likely be dramatic.

A balance between utility and aesthetics can be found, but vendors need to take a step back from their babies and objectively ask the question, “Is my baby ugly?” They also need to ask their customers, partners, friends, family (especially school-aged children), and strangers they meet at airports or in elevators what they might do to improve the UI of their product. They might be surprised to learn that they do, in fact, have an ugly baby.

Andrew Hay is senior analyst with The 451 Group's Enterprise Security Practice and is an author of three network security books. Follow him on Twitter: http://twitter.com/andrewsmhay.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

CVE-2014-8711
Published: 2014-11-22
Multiple integer overflows in epan/dissectors/packet-amqp.c in the AMQP dissector in Wireshark 1.10.x before 1.10.11 and 1.12.x before 1.12.2 allow remote attackers to cause a denial of service (application crash) via a crafted amqp_0_10 PDU in a packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?