Why We Build for Practitioners First

Author
Impart Security
Published on
April 16, 2024
Read time
5
Impart Security
April 16, 2024
5
min


When I worked in the networking industry, it was not unusual for security revenue to comprise less than 25% of revenue for most large enterprise customers, with the remaining 75% of revenue coming from networking / bandwidth charges.  From a vendor standpoint, security was viewed as an afterthought or a bolt-on product to the core networking business.  From a customer standpoint, what this meant was that the CTO was the ultimate budget owner and decision maker for critical security technology, rather than the CISO, which caused the experience of the security professional to be under valued in the decision making process, and often resulted in security teams getting saddled with subpar products, hidden from sight with a low price tag.


In the face of these market incentives, it is too often the case that mediocre security products end up becoming the de-facto standard, and security practitioners just accept as fact that entire product categories are difficult to use and a poor experience.  We saw this very clearly in the WAF market where the majority of WAFs were based on a free open source list of regex rules that were brittle, noisy, and difficult to manage.  This is still the case in the majority of the WAF market today.


Refocusing on the experience of the security practitioner is something that requires a deep empathy and respect for the role.  Unless you truly understand and empathize with the frustrations of a security professional trying to do their job while saddled with subpar tools, there is no obvious incentive to build a tool that makes their lives better.  The dominant incentives are to focus on the decision makers and budget owners, and to check all of their boxes for the lowest possible price.


Before Impart Security, I led the product management team at Signal Sciences which reimagined the Web Application Firewall experience.  Our  approach was to focus on delivering an amazing Web Application Firewall experience to users and practitioners, instead of focusing on buyers looking for a checkbox.  By focusing on this approach, we were able to build such a strong following among security practitioners that we were the highest rated WAF on Gartner Peer Insights, and ultimately resulted in a successful exit to Fastly for $750M.  This blog post is the first in a series that unpacks some of the biggest lessons learned about the overall security experience that we are now bringing to the API Security space at Impart Security.


Security Experience is More than UX

Traditional security products are built without the practitioner in mind and lack an appreciation for the end to end experience of the user.  The best example of this is a traditional networking equipment (i.e. a router, or a switch) with access control lists.  Can the firewall provide security?  Absolutely.  However, setting that firewall up and maintaining those lists is a huge operational burden and creates a nightmare for security teams.


Emilio Escobar, the CISO of Datadog, captures this idea well in a recent blog post:

One thing that I believe has been completely ignored by most (usually the biggest vendors) products is the cognitive load that they introduce to their users. Perhaps it is the result of a judgement call that dictates that solving security problems is the only priority so they have the luxury to ignore all else — which seems to be the case. When taking a step back and looking at these products from a neutral standpoint, you will see that the user experience is horrible.

As obvious as this point might sound, this perspective is still not something that is widely appreciated or understood outside of the security community.  I was speaking to a senior executive at a well known technology company recently, who felt that the most important feature of their security tooling was  latency and processing efficiency.  While this might make sense for a CTO who is hyper focused on performance or availability, this perspective doesn’t make sense for a security practitioner who has actually had to go through the experience of setting up and running a successful security program at scale.


Fundamental technology assumptions and priorities have far ranging implications into the overall quality of the downstream security experience that no amount of product design, UX, or UI work is going to overcome.  If you believe that your most important security priority is to make decisions with as little latency as possible while maintaining maximum efficiency, then the security tools that you build are going to be optimized for speed and cost but not optimized for intelligence or usability.  Running analytics at runtime? Too slow.  Machine learning?  Too much CPU.  Maintaining state? Too much memory.


The solution to this problem isn’t coming up with a new UX with the most modern web frameworks, or a mobile app so that users can use their phone.  A compelling solution requires a re-imagining  of the entire security experience from the ground up, thinking through every touchpoint that a security practitioner has with their tooling, and reducing the friction, overhead, and cognitive load from each touchpoint to such a degree that the overall experience leaves users delighted.


Continuous Investment in Experience

Great security companies continuously invest in practitioner experience.  This doesn’t mean that we’ve gone out and hired dozens of product designers - but rather it means that we’ve structured our company and our priorities in such a way that we always think of the practitioner experience first.  Everything we do is tied back to a key element of the practitioner experience because we want to make sure we are always adding value to the practitioner.  


What follows here is a brief survey of how we think about that experience, which I’ll deep dive in future blog posts.


It Starts with Deployment

The first and most important step for any security product is getting it set up.  Without this, it doesn’t matter what else the product can do or what novel technology it is built on.  Having an easy and fast deployment might sound easy, but it’s not.  There are many hidden challenges such as operational support, legacy infrastructure and applications, and data privacy that are complete showstoppers for security tools, so keeping the deployment experience fresh and easy is an area of critical strategic importance that requires ongoing investment and value delivery.


Opinionated Detection

Security tools also need to be able to detect threats.  Like deployment, this sounds obvious, however most security tools are plagued with meaningless noise and alerts that make it impossible for engineers or security teams to actually know where to get started.  In addition, because most security products weren’t built by experienced practitioners, they lack an opinionated point of view on what is important, and require additional investigation and digging before users can start to understand exactly what is going on.  The detection experience needs to be opinionated, informed, and helpful instead of overwhelming and full of visually appealing charts that add little value.


Closed Loop Defenses

According to Edgescan’s 2022 Vulnerability Statistics Report, it takes an average of 57.5 days for the average critical security vulnerability to get resolved.  In practical terms, what this means is that it isn’t enough for security tools to provide information about vulnerabilities - they need to actually resolve the vulnerabilities without requiring manual action to be effective.  Having an amazing defense experience means that practitioners need more from their tools than alerts, reports, or notifications to their SIEM.  They need a full closed loop system, including enforcement actions like the ability to block attackers from attacking.


A Deeper Dive

In future posts, I’ll dive deeper into each of these experiences (Deployment, Detection, and Defense) and the unique approaches we take at Impart to deliver user delight for each of them.  I’m truly excited at all of the pain we’re taking out of the existing API security problem space and am myself continuously motivated by the feedback that we get from our beta customers.


Want to see for yourself?  Join our beta program or  stay tuned for more updates!

Subscribe to newsletter

Want to learn more about API security? Subscribe to our newsletter for updates.

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

See why security loves us