"Technology consumers don't give a jumping jack about security", a secure design expert once said to me. And you know what? He's right, at least partly.
Increasingly, tech-savvy consumers are interested in how their data is stored and protected. Still, the vast majority of consumers are primarily concerned about being able to use the SaaS or software platform features that inspired their purchase. That's completely understandable. The danger though is that software leaders, in their haste to scale usability often forget to - or may not even know how - to design strong and usable security. You can ask the likes of Equifax (lost $1.7 Billion due to data theft ); the startup, Codespaces (which went out of business after a hack due to insecure AWS and Code pipeline config), and even LinkedIn some years ago (lost over $4 Million due to insecure password storage).
Recently, I had the opportunity to talk with Sam Greengard and Dark Reading about secure design and usability. You can find the thought-provoking articles Sam wrote on Embracing Secure Design here... Security Isn't a Pretty Picture and Constructing a More Secure Framework. Inspired by my time with Sam, I want to outline a few core principles for designing usable security.
Principle 1: Implement Secure Defaults
The default state of any software system should be secure. This means that, by default, when a user accesses the system, the security controls in place are enough to provide the required level of data confidentiality, integrity, and availability for that environment, business, and its users... without the user having to "turn on security". It may be necessary to allow users to increase their security, but the baseline configuration should be secure.
Some basic examples of this are... passwords should be salted and hashed when stored in a database to make password theft super harder even if that database is compromised; or access of a browser to the computer's webcam should be off by default, except the user explicitly grants access.
Principle 2: Display Targeted Risk Information for Security Configuration Options
Yes, we should implement secure defaults into software solutions. Yet, most creatives understand that with system configuration, one configuration rarely caters to all users or customers. This means that for our software to be broadly deployable, it is necessary to support various security configurations... which may have varying levels of security strength.
As mentioned before, the regular user choosing amongst security options or security configurations is usually not well versed in the security implications of a particular configuration. Thus, this principle strongly suggests that every selectable security configuration should be accompanied by a targeted message or help notice that outlines the security benefits or risks of that configuration.
For instance, a SaaS platform may allow users to enable Multi-factor authentication, via one-time codes generated by the platform and delivered via SMS to their mobile number or via codes generated via Authentication apps like Google, Microsoft, or Duo Authenticator. The security risks or benefits of either choice can be displayed alongside those options or as a user makes a choice and before they save that choice.
Principle 3: Provide Buckets of Security Configuration Options with Different Security Levels
To reduce complexity for our users, we can create buckets of security configuration options that they can choose from. A crude example will be buckets of high, medium, and low security. The selection of any of those buckets should lead to the automatic selection of certain options applicable to the chosen level of security.
This principle works in tandem with Principle 2 since it would require that any bucket's security benefits or risks are clearly articulated. It should also be possible for users to do any of the following: select security configuration options manually, select a security level that automatically selects associated security configuration options, or combine the selection of a security level with manual modification of auto-selected configuration options.
Principle 4: Store Secrets in a Way That Significantly Hinders Compromise
In conjunction with Principle 1, this principle emphasizes that secure storage and management of secrets should occur out of the box, with little interference required by the system user. Examples of secrets are cryptographic keys, digital certificates, passwords, etc.
Additionally, I believe that secret management is so difficult to do well that it is best to leave as little as possible in the hands of the user, be it a regular user or a system administrator.
Principle 5: Monitor Circumvention of Security Controls
A study by IEEE “Circumvention of Security: Good Users Do Bad Things.” shows that regular, “good” users often circumvent security controls. The referenced resource describes different scenarios of security circumvention, as well as the reasons that necessitated circumvention. It shows that, as was mentioned in the previous section, the primary reason for security circumvention is that security is impeding necessary workflow, making life difficult for those who need to use the system.
Technology makers usually build in telemetry that enables them to monitor preferably anonymously— statistics regarding user behavior, as well as overall system behavior and health. However, this principle recommends that system monitoring should also cover the usage, lack of usage, or circumvention of security controls. The data produced will help to create security controls that better fit the needs of users in that business and environment.
Principle 6: Enable Active Authorization That Requires Consent of the Grantor
This principle applies to permissions authorization for users and apps or systems. And a good example, similar to the browser and camera example in Principle 1, is what we see in Android and IOS mobile operating systems today... any mobile app must explicitly request permission to read or send Text Messages.
The Cause of Usable Security Belongs to All of Us
We have gone through six principles that help you address the security usability challenges. We do not frame those six principles as an exhaustive list, but rather as a foundation that provides you with the necessary insight and starter fuel required to build usable security.
The Secure Design Workshop for SaaS Startups
Are you interested in learning how to put these principles to work in your product and your software architecture? We've just launched a uniquely practical Secure Design Workshop for innovative SaaS startups - this could be startup businesses or startups within established businesses. In a 3-hour focus session, Resilient's experts come alongside your team to analyze your product and architecture, identify critical assets, reveal attacker profiles and their attack points, and finally... identify secure and usable mitigations.