Security Is Part of Every Critical User Journey

How else would you make sure that product security decisions serve your customers?

Phil Vachon

"As a user, I am giving you my personal information to deliver some value to me, so pretty please don't let it get into the hands of anyone who will do something bad with it." — A real conversation taking place in every user's mind (paraphrased)

How often do you find yourself holding a breach-notification letter in your hands or clearing breach-notification emails from your spam folder? Who sent you the most recent such letter? Perhaps it was from a bank you used many years ago, or a SaaS (software as a service) product you used for a hot second before the company was acquired and the product was shut down. Or maybe it was from an outsourced HR data management company that had an oopsie with a legacy file-transfer product at the edge of its infrastructure. Perhaps it was your accountant, who kept your tax returns around on an unpatched computer for a decade until it was ravaged by ransomware. Or maybe it's a major credit-reporting agency where your credit-card provider reports your payment history.

No matter what the scenario, you're always left wondering, "Why was my personal information treated without due care?" Or worse, you're left holding the bag because a third-party vendor—one you didn't even know existed or were unaware was somehow involved in delivering value to you—lost track of your data. You didn't even have a choice, and someone else made a decision on your behalf without proper due diligence. (I will not talk about vendor risk management. I will not talk about vendor risk management. I will not ah, to heck with it.)

In modern product management, the user's journey through a product is always front and center. Users should choose a product because they derive value from it—which is to say it should solve a meaningful problem for them in a way that also delivers dollars to their bottom line. User journeys get translated to user flows: figuring out a delightful happy path and helping users get to the right results if they hit a sharp edge. When translating user journeys into flows, people quote Nielsen's 10 usability heuristics (nngroup.com) to each other as though they are warding off bad user-experience demons. User experience has come a long way since the early days of the web, and practices for giving users well-trodden happy paths, as well as insights and transparency when dealing with edge cases, are simply table stakes. This allows engineers to focus on delivering the best possible user experience to achieve great user outcomes.

Some engineering and product domains have even evolved scientific approaches to this problem. For example, HMIs (human-machine interfaces) for plant processes are highly studied for the risk they pose to quality, cost, and even loss of human life. (For a more in-depth review, see the examples of the Bhopal, India, disaster (nih.gov) and the Therac-25 radiation therapy machine (sunnyday.mit.edu).) Some industries have strict standards that define user experience and visual experience. Because of the risks involved, how machines can let operators down is a well-studied field in these domains.

Why hasn't information security taken the same leap? Across industry, technology and business leaders alike (jpmorgan.com) see the risk and challenges of other businesses—often smaller than themselves and with different stakes—holding on to their customer and business-critical data. Technical implementation details often blind us to solving meaningful security problems, and product teams quickly forget what security really means to a customer. It's time to change this approach and make security integral to each and every user journey—but especially your critical user journeys.

Critical User Journey?

User journeys are one of many tools that product managers use to define how to ensure that a product delivers value to clients. Value is realized in a number of different ways, ranging from moving the needle on revenue to improving efficiency or decreasing costs. How each product achieves these goals is unique.

From user journeys, engineering and product-delivery teams distill technical architectures and software designs, UX designers develop delightful user flows, and operations-and-performance teams define SLOs (service-level objectives) that keep the product robust and reliable. It's only pragmatic to focus on the surfaces that users regularly interact with to derive full value from a product.

Critical user journeys (product management jargon evolves and emerges as rapidly as new JavaScript front-end frameworks) are defined as those that deliver the most business value to you and your customer. Being able to checkout using an online commerce platform is a clear example: A customer can't buy your products nor can you generate revenue unless customers are able to take their shopping cart to that crucial next step. Critical user journeys can be thought of as tasks your users must always complete successfully when they interact with your product. What a way to keep yourself focused on the user's needs!

In contrast, security is treated as a principle applied by engineering teams during system design. Many companies wrap this in an aphorism: "Security is everyone's job," for example. Could they possibly be any more vague as to the concrete security outcomes engineering teams will actually need to deliver?

Worse still, this makes no statement about what customers might expect in terms of security outcomes. Many product teams treat security requirements as a burden inflicted on them by regulators who have stepped in to represent customers' best interests. Security thus becomes a checkbox control that meets only the "letter of the law" dictated by a regulatory requirement without much thought as to what the regulation was actually meant to achieve.

By including security outcomes as part of your user journeys, you can show real controls that map to measurable user outcomes and protect against worst-case scenarios. This helps your engineering teams, too, by making it crystal clear where they need to invest in security controls so as to align with your users' needs.

Shifting Your Mindset from Technical Details to User Outcomes

When describing security controls and features of a product, engineers and security architects speak in security jargon. Data is encrypted using a specific algorithm, with keys stored in some particular key management system. Certificates are issued for no longer than some number of days. Keys must be of a minimum particular length. Passwords must be at least so long, with so many special characters, and are stored using certain memory- and CPU-complex algorithms. While these are all useful details for implementers (and perhaps auditors), what does it mean in practical terms to your end users?

These measures all add value. Storing your cryptographic keys in the right way—separated from the data they protect in an authenticated key-management system—raises the bar for an attacker to smash and grab your data. A comprehensive suite of IT security controls across your corporate estate that ensures identity and access management are well handled will keep customers comfortable in the knowledge that privileged access to your product is ring-fenced and limited to only the right people. But again, these are just capabilities that can lead to a desired user outcome.

Worse, sometimes your choice of security tools does not map to your customers' actual security concerns. Including required security outcomes in your critical user journey will help maintain a sober view of which security features are critical for your end users, while also helping you avoid the tendency to apply buzzword-compliant techniques.

Users Can Be Their Own Worst Enemy, Too

Drunken cofounders of SaaS startups have asked me honestly, "How does a security feature get me to my next funding round?" Depending on how glib I'm feeling, I'll usually turn the question back on them: "What will your next funding round be if your customer data is in a malicious third-party's hands?"

The race to the bottom to add features and functionality means that security capabilities get deprioritized, and products, at best, get a thin veneer of data protection and access control. On average, the data is unprotected in the back end, and, at worst, it's living in an Internet-facing object store. Sadly, the latter occurs often, because as you race to add features, there's no security salve you can smear on your product to pay down the security debt you are accruing.

Again, if you're trying to get to your next funding round (or even to ensure you can make your next payroll), that debt might be a necessary evil. Without including security outcomes in your user journeys, however, you might simply be taking on more debt than you can ever pay down. Worse, you might be securing the wrong things, leaving what your customers most value wide open for attackers—and, by extension, making their customers vulnerable to attack.

Unfortunately, this tension is only exacerbated by the very users who have high expectations about how you're securing their data. Exciting whiz-bang features keep users engaged. Their productivity increases by using your product, which only gains in stickiness as a consequence. But, if you are slow to iterate and add new features, competitors will pop up and eat your lunch. By including security outcomes in your critical user journeys, you can make the right tradeoffs as you iterate, securing what matters most to your users while continuing to find new ways to deliver value.

If security is a part of every critical user journey, this also needs to extend to each aspect of your culture, from product design and development through to sales and marketing. As you delay delivering features to ensure good security architecture and client-data protection, remind your customers that you're also focused on protecting their data by building features correctly. Not all users will place a high value on security features at any point in time, so this could be a tough sell. Individual users might be less bothered by this kind of risk, but good messaging around security will set you apart from your competition in business-to-business settings.

Put It into Motion

Next time you're working on a new product or feature or the next time you're yawning your way through a product development meeting, raise your hand and propose that security outcomes and risks be defined at each step along critical user journeys. Whether you're building an integration between enterprise systems, a user-facing application, or a platform meant to save your customers complexity and money, putting security at the forefront of the product team's challenge will be transformative.

Be user-driven and ask your customers what their expectations might be, and define concrete tools to achieve these outcomes. Don't cargo-cult security practices that don't help your customers achieve their needs. Make this a meaningful mission, and be sober about the real value you're providing your customers.

As a user, you too would want your data, credentials, and/or access to sensitive information and systems to be protected from unauthorized attackers. State it, track it. Then let's deliver some real user outcomes.

Phil Vachon (@pvachonnyc on Twitter) is the head of infrastructure in the CTO's office at Bloomberg. In this role, he leads a department of architects, engineers, and product managers in developing secure, scalable, and reliable infrastructure technologies. In prior roles at Bloomberg, Vachon built secure embedded biometric systems as well as hardware security modules, among other things. Previously, he cofounded and was CTO of a startup that sold a high-speed packet capture and analytics platform. Earlier in his career he worked extensively on synthetic aperture radar data processing and analysis as well as carrier router data plane engineering.

Originally published in Queue vol. 23, no. 3—
Comment on this article in the ACM Digital Library