“This work is, as I said, improvisation, so we use whoever’s around, if we can trust them.”
― Alan Furst, “Mission to Paris”
In Part I of this article series, I wrote about why product teams should be concerned about security, simple security heuristics, and the importance of preparation and empathy.
In this final installment, I will cover risk profiles, threat models, friction, usability testing, and common security challenges for product owners.
Understanding risk profiles and threat models
If you spend time in digital security circles, you’ve probably heard phrases like “risk profiles” and “threat models.” Words like these sound very important and intimidating. They are important, but don’t be intimidated — these concepts are actually easy to understand.
In a financial context, the term “risk profile” often refers to an individual’s willingness to make speculative decisions with their assets. In a security context, it means a person’s exposure to potential risks or threats. We determine this exposure not just by personal characteristics but also by situational context.
Increased risk profile: an example
Let’s say Pat is a product manager for a company that sells its products online. The company’s customers are wealthy and not particularly tech-savvy. Earlier this year, Pat decided not to put advanced security measures around the site’s credit card processing. So, the customer risk profile is a combination of these factors:
- Their wealth and lack of technical sophistication (personal characteristics that increase their attractiveness as a target for digital thieves)
- The online store without the latest credit card processing safeguards (situational context of an infrastructure weakness that attracts those same thieves)
The combination of these factors led to an increased risk profile. As a result, several customers got their credit card and personal identification stolen last week. Which is now why the CEO wants to see Pat in her office this morning.
Pacing the floor outside her office, Pat might be tempted to consider arguing that the company’s customers are to blame, being too rich and too digitally stupid to be aware of the dangers of online shopping. This line of reasoning is known as the fundamental attribution error, a fancy term for the greater propensity to blame the victim than the situation context.
We humans are psychologically hard-wired to do this. It probably won’t be a tactic for Pat, though. The CEO will point out that thieves used a formjacking attack method invisible to customers. It was invisible to Pat as well, not because she didn’t put security measures in place, but because she had a larger failure of imagination around threat modeling.
Prioritizing Vulnerabilities
Threat modeling is a method for prioritizing potential threats to a system and identifying existing vulnerabilities inherent in that system. As a computer science discipline, it has been around for decades, predating cybersecurity and the internet. There are various methodologies extant: Microsoft’s STRIDE, PASTA, Trike, and VAST to name a few. Most of them incredibly analytic, systematic, and so process-driven they would easily drive any Scrum master, Lean Startup practitioner, or fan of the “move fast and break things” school of software development into a pit of rage, despair, and insanity. A software product manager doesn’t have to be an expert in all of them, or even one of them, but definitely must be familiar with the concept and some common-sense approaches to minimizing weaknesses in and threats to the product.
One easy, common-sense, threat modeling approach is to engage in a simple thought/whiteboard exercise. Ask yourself the question, “What potentially bad things could bad luck or bad people do to my product?” Document the answer. Document possible responses or solutions. Rinse and repeat. This is known as the black-hat use case.
Friction is your friend
In product management circles, friction has definitely gotten a bad rap lately. Friction is bad. PMs must banish all friction. All product interactions must be effortless, high-peak, flow experiences. Using the product should be a frictionless joy, like a thinner you sliding down a waterslide in Utopia under a shower of $100 bills in an otherwise sunny cloudless sky. Yuck.
Like a digital Dear Abby, I am here to tell you: Friction, when appropriately applied in the right context, is your friend.
In our daily life, we experience different levels of friction that are tailored to the context and situation. Think about the experience of walking into a restaurant versus into a school, versus into an airport terminal. Users expect some level of friction if the context warrants it. Users get frustrated when those profiles and models are misapplied. We accept body scanners at an airport, but not in front of an Arby’s. Product managers need to understand their customers’ mental models and risk profiles. Then they need to add friction sparingly, appropriately, and intentionally (depending on the context) to keep users safe from harm.
The importance of usability testing
Security-minded professionals will speak frequently about QA or “pen” (penetration) testing. But I cannot stress enough the importance of usability testing, particularly formal usability testing under lab conditions. This process can really help your team gather risk profile and threat model data, plus potential product vulnerabilities. To truly understand the product, the product manager has to know how and where it fails, where it is robust and where it is brittle, and where its paths closely align with user goals and task flow, and where they are widely off the mark. Strong, safe products align their security goals to their user goals. Usability testing is a worthwhile investment, one that any product team should consider.
Frequent security challenges for product teams
Here are some common challenges that product teams face in the security space:
- Security is often seen as an engineering (the discipline), as opposed to a multidisciplinary, problem. So engineering (the department) ends up owning the solution, cultivating a priesthood of security developers, who create engineering-centric solutions that may be out of sync with user and company goals.
- The perfect is not the enemy of the good. Do not panic or throw up your hands if your company does not have a threat modeling methodology and a CISO, a bevy of security engineers, and an intimidating roster of technologies and acronyms. Just starting to think about how your product team can improve product security is good. So start today.
- Beware the boy-crying-wolf/false alarm effect. The more warning flags appear in the product, the less users will heed them.
- Do not apply a security solution to a management problem. For if you do …
- … Beware of “shadow IT” and the and the informal methods users do to sidestep official processes. When users see security as an obstacle, they get good at evading or cheating the system. (Cue sound of Netflix startup screen …)
Two last bits of advice
If your company does have a security team, get to know them! They are probably not as scary as they appear at first glance. Products get stronger when different teams collaborate, and security is no exception.
Remember that security extends beyond the product. Think about how you are protecting customers (and their data), not just inside the product, but outside it as well. Familiarize yourself with compliance standards like CCPA, GDPR, HIPAA, and SOC2. Encourage good security practices not only across the organization but within your own team as well. Fortune favors the prepared mind, and the prepared product.
