Usability in Security Products
by Mahesh Babu, on May 06, 2020
Usability ensures more deployment of a security tool, adoption by those the security tool is trying to protect and usage by the security teams administering the tool. This, in turn, ensures more of the estate is protected. Usability, therefore, has three key components - (1) ease of deployment, (2) low adoption friction and (3) ease of use. There have been multiple proof points in the security industry of a more usable product (with less mature protection capabilities) disrupting a market.
For example, the Signal Sciences disrupted the Web Application Firewall (WAF) market even though their protection rules were not as robust as incumbent vendors for three reasons. First, they were much easier to deploy in cloud environments because of their simple agent / module based approach and their robust integrations with DevOps tools.
Second, their interface mirrored those of a legacy WAF vendor which made it easier to use for customers transitioning from one of those legacy solutions. In addition, their rules were easy to setup and customize which meant customers could get to protection parity with legacy solutions quickly, even if Signal Sciences did not provide parity out of the box.
Finally, they were a low friction solution that got buy in from developers and DevOps teams because of their robust set of out of box integrations with the tools that developers / DevOps teams were already using. This implied that the teams (developers, DevOps) that owned the assets (web applications) that Signal Sciences were trying to protect did not have to change their day to day process or slow down to accommodate better security.
The reason why the security market has not traditionally taken usability serious is because usability, coverage and protection are seen as trade-offs in product development. The key question most security product teams or entrepreneurs ask ourselves is:
We’re in the security business and customers are counting on us to defend their assets. Given limited resources, do I (1) keep making our defenses better or (2) extend our defenses to cover more ground or (3) make our defenses easy to setup and consume”?
As security practitioners, we always default to option 1 first and get pushed to option 2 by our advanced, flywheel customers next. However, we tend to miss the majority of the market that has nothing and needs a solution that is “a little worse, a lot easier to deploy and use and doesn’t disrupt the business.”