Cyber Blog -

Towards ‘Good Enough’ Product Security

Jouni HiltunenLast weekend, as I was logging in to my online bank to pay a bill or two, I saw an unusual notification in the webpage that said their customer service is drowning in support requests. Soon I noticed the reason: the login process was renewed and included an additional two-phase authentication or, in other words, compliance happened. That was the day when the new Payment Service Directive (PSD2) came into full effect. Yet another directive was invented to make people’s lives harder. Wasn’t the old security good enough?

The hard part is determining what is good enough

This all reminded me of a paper I read back in the day [1]. It bluntly presents a basic guideline, albeit a tautology (but which is often forgotten in the flood of branded vulnerabilities, new attack types and all the fuzz that “puts everybody at risk”) that good enough is good enough. However, the hard part is determining what is good enough. Contradicting security incentives among business and security people with varying assumptions of end user expectations create a complex mess. An example of this is password rotation which may be a compliance requirement but also an intrusive, yet unproven, security benefit.

Don’t you tell me what is my weakest link

As a product security enthusiast I started to wonder that if the PSD2 was a necessary security improvement why it was implemented in the last day required by the directive. An ancient axiom of cyber security states that security is as strong as the weakest link. Surely, the bank knows the best what is their product’s weakest link. Unfortunately, sometimes the security improvements will not address the weakest link because of business and technical reasons. Let’s take the human factor as an example.

Human factor as a scapegoat

Often we hear that the people are the weakest link. This proposition is an easy way to evade responsibility. However, people could be sometimes taken out of the equation or the systems could be designed in a way that prevents user errors or make them less probable. Organizing proactive trainings and providing concise and understandable security policies, operational doctrines, secure guidelines and best practices are another way of making the errors less probable. After these things are in order, then we have a sound reason to claim that humans are the weakest link (but it might be that is not the case anymore).

Taking business-driven security into account

The corporate security advocates business-driven security strategy that aligns IT security landscape with the company’s vision, goals, and business strategies. In the product security side this has to be taken into account by designing products that support that strategy. However, just like in compliance, there is no one-size-fits-all option. One way to measure the fit is through product value proposition which is simply the benefits minus costs. The benefits could be, just like in any other type of product, reduced work, increased performance and higher quality, for instance. These benefits could be more or less universal.

My threat model is not your threat model

However, security product’s benefits are also weighed in context of risk management. Its main goal is to reduce likelihood or impact of an identified risk while security products are one of the main tools to achieve that goal. It is notoriously hard to define the risk factors unambiguously, let alone price them. Let’s take threat model as an example. It is part of the risk assessment which defines supposed attacker’s capabilities and behavior, attack vectors and the assets desired by an attacker. However, my threat model is not your threat model.

Preparing for the unknown

How to come up with a product that tackles the business-driven and risk management uncertainties? Configurability with an ability to change the security posture on-demand and to fit the product in your threat model seems like a reasonable solution. It could also help to balance security with usability and intrusiveness of the security features. Configurability could enable future-proof security as new threats arrive and the old threat actors get new capabilities. Product design and business model should also support product’s life-time security-wise, for example, taking account updatability against known vulnerabilities, timely availability of security patches and mitigations against unknown threats.

Security as an enabler

Fortunately, sometimes the security product’s benefits could be unbeatable. This is the case if new use cases are made possible. One of those is mobile working which is enabled by security products that provide a trusted platform and secure network connectivity. Another one is an ability to use one device to handle information with different security levels that otherwise would require multiple devices. Some of the use cases could be achieved through paradigm changes. Traditionally, it has been game over security-wise if the adversary gets physical access to your device but this risk must be revalued when physical anti-tampering mechanisms and side-channel attack protections are in place. On the other hand, product security certifications are security enablers when it comes to handling national classified information.

Sometimes we all need a little push

The new two-phase authentication in my online bank was a hindrance, but at the end of the day, the compliance made my life little easier. I have started to use modern technology in a secure mobile platform that has made my banking experience better and improved my security posture. I just needed a little push to realize what was good for me, just like an athlete who has to break his faulty technique and settle for lower performance for a while until he masters the superior technique and breaks the records. Maybe also we, as a security community, need a little push to make greater effort to bring business, security and regulators together to bring solutions that are good enough.

Jouni Hiltunen, Security Product Manager, Bittium, www.bittium.com

[1] Sandhu, R; “Good-enough security”; IEEE Internet Computing January 2003; Vol.7(1); pp.66-68.