November 3, 2019

Why Risk It? Data Breaches and Product Design

product design data breach

Type

    Topics

      Industry

        Nearly every bit of information exists on a server somewhere today. This sensitive data is crucial for the day-to-day operations of every modern business. But because the internet is still relatively immature from the standpoint of security, it has become statistically inevitable that a company that stores data will suffer a data breach at some point (yes, that includes you).

        Dmitri Alperovitch, Vice President of Threat Research at McAfee, has an oft-quoted statement among cybersecurity experts:

        “There are only two types of companies—those that know that their data has been compromised, and those that don’t know.”

        So if you know that your data will be compromised, what can you do to mitigate the damage?

        Understand how your data is vulnerable.

        We like to think that these data breaches we hear about are performed by some seedy hacker in a basement who has the technological know-how to break into any database.

        But that’s rarely the case.

        The most common situations tend to stem from the mismanagement of data by the host. This includes abusing regular user interfaces, mismanaging secret keys, or simple phishing scams among many other causes.

        And no matter how hard we try, these problems will always exist. We will always need to have a key to the vault and at any point, someone could drop it.

        Be proactive in planning for data breaches.

        Consider security early in your product design.

        This fantastic series of information security articles written by Tanya Janca demonstrates, step-by-step, how you can make security considerations earlier in your product development life cycle, using methods that regular engineers (read: non-cybersecurity-experts) can easily accomplish. The earlier you enforce security, the less expensive (both cost and effort) it is to apply the practices.

        To steal her metaphor: it’s much easier to design and build a bathroom in a new house when you’ve planned for it from the beginning, rather than having to rip things out to retrofit one in when the build is nearly completed.

        Scrutinize collection and assume your data will escape.

        Every data point you collect from your user puts them at additional risk. Our job as builders is to protect those users.

        Consider what the core function of your product is, the really special and beneficial thing that your product does. And really look deeply at every piece of data you collect in your application.

        Then ask yourself a few questions about each of those pieces:

        • Is this data point we’re collecting actually required to do that core function?
        • Am I collecting this data point for the benefit of our business, or for the benefit of the user? (Your answer should always be user, unless you’re performing a fixed-scope research project)
        • Will my users be negatively affected when this data escapes?

        The objective here is to design your product using the method of Minimum Required Data — the absolute least data you need to make your product deliver its core value.

        Limit the scope of your research

        We often need to collect data for purposes of user or market research. That’s a regular practice in business, but you shouldn’t let this be an excuse to put your users at risk. When researching, be sure to limit the scope of your work to the smallest possible. This means a few things:

        Formulate a Hypothesis, and make it extremely clear how you will validate it. Make sure you define what areas you will and will not touch, and time-box your research.

        Scrutinize The Collection, making sure you are only collecting the data you need to validate your hypothesis. For example, it is extremely rare that you would ever actually need to associate a user’s real name with research data.

        Limit the number of points that the data can touch. Every touchpoint is a place that data can be read, and extracted. This should be a regular practice for all of your data collection, not just in cases of research.

        Communication, Transparency, and Trust

        The most important thing you can do from here is to communicate early and often with your users. Tell them what data you collect, why you collect it, and how you intend to protect it. When you improve your product or security, tell your users about it, there is no shame in strengthening an area where you were previously weak. And when you suffer a breach, help your users by communicating the best path forward.

        These practices of transparency will build trust with your users and ultimately strengthen your product and its reputation.

        We can help!

        At Method, we help companies strategize how to effectively build digital products, collect data, and develop an experience that helps users perform their job as quickly, easily, and safely as possible. Talk to us if you’d like us to teach you how to do this for your product!