Factoring security into your digital product strategy.

Whether we know it or not, we readily offer up where we are, where we’re going, and where we’ve been. We share biometrics, health, and financial information with ease. We trust the technology companies that use this data to give us better services. At least, until there’s a clear reason not to.

On the product side, this collection of data and the need to safeguard it carries a heavy responsibility. For product owners and engineering teams, a clearly defined and managed approach to data security has never been more critical. Not only to avoid litigation and class action lawsuits, but to be a trusted organization to consumers, making security a clear priority. Digital product operators must be the custodian, not simply the landlord of consumer data.

In the US, federal and state laws exist to enforce how businesses manage data and report breaches. States like California have set the precedent for data security regulations for businesses engaging the public. In New York, laws are more specifically focused on the financial services industry to combat the exposure of personal financial data. More generally, certain industries have defined regulations and requirements – PCI compliance in commerce, HIPAA compliance in healthcare – each setting the standards for the secure operation of digital products and services that collect, store, and transmit personal data.

Unfortunately for digital product operators who’s core services rely on the collection of personal data, the risk of a security breach has never been higher. This risk is only escalated by the complexity of today’s digital ecosystem that meshes together third party services through APIs, enabling data to flow through a myriad of platforms, in the quest to provide a seamless end user experience.

While we’re not a cyber security firm, we are responsible for factoring security into the planning and development of our end-to-end product engagements. This includes our web and mobile product work for clients in financial services, healthcare, and e-commerce. In all cases, we work in collaboration with our clients to ensure our data management and security approach is aligned with their own. For zero-to-1 product work, this generally means developing the security plan as part of product architecture.

Through our experience, we’ve come to see how security requirements directly impact our approach to technical planning and engineering, and the scale of testing required to ensure compliance. Building digital products in healthcare for example means allocating resources necessary to set up the right third party services that meet the range of HIPAA requirements, and these services come with far greater costs than usual.

If your team is planning the architecture for a new digital product, or you’re actively working on increased data security across your digital ecosystem, below are some areas of consideration we hope will help inform your process.

First, secure by default.

The simplest form of security and authentication is the password. We configure passwords with minimum length rules, expected occurrences of numbers of special characters, and often include banned words like “password”. We also use tools to check if a password has been part of a data leak. This means we ensure that a user's password is not already compromised.

Once a user is logged in, we must make sure they only have access to the data they are supposed to. This is where an Access Control List comes in. This “list” is a set of rules per dataset, or even sometimes on the database tables, that outlines if that user is allowed to read, write, update, or delete data. For example, an administrator might be allowed to update app settings, but a regular user cannot. Or a marketer can create a blog post but only the site administrator can publish it live.

A popular philosophy to apply to your data access rules is called the “principle of least privilege”. This means no user or role in the system should have more access than they need to. When we are building from scratch, this means we start with all users having no access and scale up access as needed.

Even with great security practices, it can be difficult to fully stop any bad actor. What you can do though, is log suspicious activity. For example, we might want to know if a low-privileged user is trying to access the admin dashboard. Maybe a single attempt was in error. But continued access attempts might flag the need to investigate the account and take further action.

Let the tools do the work.

It’s never been easier to build high-quality digital products. The tools we have access to today allow a higher degree of efficiency and effectiveness. One of these tools is linting which automates code review for errors or flaws. The linting configuration is set up to find logic flaws. The best part is that you can add new rules for the linter to check for. We always add rules for security concerns.

There are also static analysis tools and auditing tools that look at the code logic and tell you when something is wrong. Perhaps you are sending unsanitized input to a database call. This can easily lead to a bad actor sending commands to your database and receiving access to your data.

Even the most simple code can have bugs in it. It is never a bad idea to write tests for your code. Not only can you make sure it is working as planned, but you can be secure in knowing that it will keep working the same way even as you add, change, or remove other parts of the code. Think of it as programmatic documentation.

These checks and validation can all be automated so that before you deploy this code, you can be sure it has been checked over for potential issues.

Lastly, you can lean on a third party to review your work. Of course you trust your own team, but you don't know what you don't know. It can be difficult for everyone to keep up with what the latest vulnerabilities are and how to mitigate them, and this is potentially where a third party can add value.

Lean into community conventions.

Of course you don't need to go it alone. There are a ton of community resources to help you navigate these complicated fields. There are many guidelines out there to help you create user interfaces and experiences that follow security best practices. Whether you are using a framework or installing a new plugin/package, be sure to check that there is a statement about security or at least evidence that the authors care about security and have made it a priority.

Know your enemy.

One of the phrases you may come across in your security journey is “security through obscurity”. Maybe great positioning for a cool hidden speakeasy, but terrible for the digital space. Do not rely on esoteric solutions to protect your data. When in doubt, log, log, log. Logging is part of HIPAA because although you may hope to never experience a breach, if one does happen, you can trace the issue through your logs and patch the vulnerability.

Good security, compromised experience.

Sadly, sometimes strong security means a compromise to the user experience.

To protect an account from compromise, authenticated sessions lock out a user that fails to correctly log in within a set period of time (say 30 minutes) or within a specific number of attempts (say 5). While this method certainly adds security, it can also frustrate users that may have otherwise forgotten or had difficulty entering their password.

By now, most people are familiar with two factor authentication or 2FA, often implemented in banking and social media apps. Unfortunately this security method can take many forms from app to app. Some use SMS, some use Email, some use third party “authenticator” apps, and others use biometrics. This lack of standardization means users need to take different steps with each app to accomplish the same goal and that can cause confusion and frustration.

Another critical UX security precaution is user validation tied to making specific account changes. For example, changing the email address connected to an account often requires the user to re-enter their password. While this might feel redundant to the user, this security method ensures that critical account information can’t be modified by someone who simply gained account access in passing. It verifies that the user attempting to change account information is in fact the account owner.

When in doubt, you can always escalate to humans. Within an app our team at Engine completed recently, locked out users are sent an email informing them that they have been locked out. We also send a notification to the product admin team to allow them to take care of it.

Getting security right.

Given the above considerations – and by no means is this a conclusive list – factoring security into your product architecture is no simple task. It requires both planning across both the engineering and UX side, along with a thorough understanding of the tools, existing best practices, and standard methods.

Managing data security is a challenge even for the biggest technology companies, with most facing security threats on a regular basis. Thankfully for those building at a smaller scale, there’s a trove of information available, helping us understand how to take the right precautions when building apps and services to ensure we’re protected.

If digital product security is on your roadmap, or you’re looking to audit your current security performance, reach out to us. We’d love to share our thoughts and experience guiding startup and enterprise clients through the technical architecture and implementation process.