For the last two years, my keynotes have included sections where I discuss the balance between security, privacy and convenience.
There are always trade-offs between these three when developing products and services, with convenience often prevailing as the key requirement. The recent proliferation of activity trackers and voice-activated home automation devices is just one example of this in the world of connected devices, where little thought is given to how the security and privacy of the information being collected can be abused and/or misused.
For over 20 years, I’ve tried to understand why users of services and products are not holding implementers of products and services accountable for this imbalance. The TL;DR summary of what I’ve found: convenience is always the top priority; in most circumstances, implementing proper security and privacy functionality is hard; and you have plenty of people pointing out problems but few who help provide knowledge of how to fix the issues or, more importantly, to provide transparency and informative information on a product or service’s default behaviour.
Every time I’ve taught a security workshop to network operators who typically also had security-related operational oversight, I started with the fundamentals of implementing good cryptography and giving advice on what questions to ask vendors:
- How do you implement randomness in your cryptographic implementations?
- Which encryption algorithms do you support?
- What modes do you use in your cryptographic implementation (ECB, CBC, OFB, CFB, and so forth)?
- What is your default key length?
- How are keys exchanged and renewed?
It’s a snoozer to most and no one usually cares about these details. The network operators, like their end-users, just want a convenient means to configure a secure solution with the least amount of work. Yet we are constantly reminded what a paradox this is.
An example of this is SSL/TLS, a popular technology used to secure websites.
SSL/TLS implementations in browsers started using several default trusted root certificates and along with other interoperable defaults, became a simple way to deploy cryptographically protected communication. It just worked and became a far more attractive technology than IPsec, where you had to understand the technology to configure it correctly.
However, the need to understand the implementation details of SSL/TLS became apparent when there were several high-profile and serious flaws discovered in widely-used implementations.
In 2014 there were two serious SSL/TLS implementation bugs, Heartbleed and Poodle, which enabled malicious actors to compromise seemingly protected communications. Many websites that were trusted to be secure due to being protected via SSL/TLS were not. Malicious actors could potentially get access to confidential data such as passwords and credit card information.
Almost overnight, many security professionals needed to understand more about the underlying cryptographic fundamentals of the SSL and TLS protocols to determine the attacks they were susceptible to, what upgrades needed to be made and what default configurations needed to be changed.
There are many product and service choices made for convenience including:
- People automatically appearing as contacts in a new application to make it easier to connect with them.
- Creating a new account using your Facebook or LinkedIn credentials rather than creating a new username/password combination.
- Video is automatically turned on to enable you to see each other during online communication.
- Information is automatically sent to a manufacturer or third party for analyzing and improving services.
- A device automatically connects to an open Wi-Fi without needing a password so you have immediate Internet connectivity.
From a security perspective, these defaults are insecure given that malicious actors can easily manipulate such functionality to cause harm. Instead, we need to exert control over communication and have accountability for any misbehaviour.
Taking back control of privacy and security
This requires careful thought on how to instantiate fundamental functionality of authentication, authorization, access control, integrity, confidentiality and auditing. At the very least there should be considerations for how to handle the following:
- How are individuals, devices or applications authenticated, that is to say what credentials are used to assert identity?
- What are these individuals, devices or applications allowed to do once authenticated?
- How would you control access to specific data or services?
- How do you assure the integrity of communication and ensure the sender and recipient are who they profess to be and that no one has modified any data in transit?
- How does it comply with confidentiality policies, where only the intended parties can see the data?
- What information do you track for auditing purposes to detect and provide attribution for any accidental or deliberate abuse?
Then there are aspects of privacy to consider, where there are nuances related to human rights and freedom of expression. Anonymity and hiding of one’s identity have been a privacy requirement in instances where online communications and access to information can put lives on the line. Also, who has the right to access any data? And should all data access be only allowed with specific permissions to do so?
A key aspect to balancing trade-offs between convenience, security and privacy is to articulate and understand the trade-offs. This is especially important for end-users who would have a harder time enumerating the varying considerations.
Trusting online communications and understanding the true risks is critical. What may be easy for a healthy person to use may be nearly impossible for the elderly or disabled. The requirements are also vastly different for convenience, privacy and security depending on who uses a specific Internet-enabled tool or product.
And, sadly, the malicious users or criminals who take advantage of a crisis are the primary culprits of raising fear, uncertainty and doubt of many usable online tools and services.
The following table is a simplified requirement matrix that might be useful to start some discussions for organizations new to ubiquitously using online tools or to vendors building new online tools and services:
Preserving privacy and securing online communications needs to be appropriately balanced with convenience. In an upcoming post, I’ll delve more deeply into what I call blind trust and how we all can take responsibility for increasing trust and safety in our digital worlds.
Read: Blind trust
Merike Kaeo has over 25 years of experience in pioneering core Internet technology deployments and leading strategic digital security transformations.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Excellent article. Non -IT security experts with risk management oversight can easily relate with this to ensure they are able to deliver on the risk considerations of all IT related investments.