Brief at the Start
Go straight to the full length version
Fundamental safety and security should not be an optional extra; secure by design should apply to the design as a whole, and not just the premium service.
There were many factors that contributed to the disastrous crashes of Lion Air and Ethiopian Airlines 737 Max in 2018 and 2019. However, the absence of two safety features that could have alerted the pilots to some conflicting information but were sold by Boeing as optional extras is unlikely to have helped. The fact that relatively low cost features that have no purpose other than safety were being offered as upsell items presents serious moral questions to the aviation industry.
While the consequences resulting from the compromise of a cloud based application are incomparable to the disastrous loss of life from these crashes, there appear to be strong similarities in product security decisions taken by many SaaS vendors to those taken by Boeing. Security features that do not contribute to the applications core offering, and that are relatively low cost to implement and operate, in too many cases are only enabled in the premium service offering.
The controls such as Multi-Factor Authentication (MFA or 2FA) and federated Single Sign On (SSO) may address user rather than vendor risks. But they address a widely recognised “failure mode”, are cheap to implement and even cheaper to operate. We would therefore argue that when implemented they should be an essential component of the solution’s overall security design, and not a nice-to-have. To use them as leverage to upsell more expensive services suggests that the vendors have run out of innovative value add features and have had to resort to using security as a means of increasing revenue. This presents similar moral questions to the tech industry.
This practice is not universal, and probably doesn’t represent the majority. But if when selecting a service you find that what you believe should be essential security features are now optional extras, you should probably consider what else as been excluded from the design.
Get the Full Version
The case against Boeing
Arguably it may not just a case against Boeing, but might have been a more systemic issue across the aviation industry. Its just that the public became aware of it under tragic circumstances when the Lion Air and Ethiopian Air Boeing 737 Max airliners crashed in 2018 and 2019 respectively. According to the widely quoted New York Times article1, the crash might have been averted if the pilots had two safety features that were sold by Boeing as optional extras2.
At the root of the incident according to the incident reports were the angle-of-attack sensors. These mechanical sensors operate in a similar fashion to a weather vane to measure whether the aircraft’s nose is pointing above or below the direction of airflow. Being mechanical they may be prone to malfunction, perhaps jamming or having been installed incorrectly as was believed to be the case for the Lion Air aircraft3. The system that led to the aircrafts’ demise, which identifies the risk of the aircraft stalling, was only listened to one of them. A difference in the signal being sent by the two sensors would not be recognised by the anti-stall system, and the instruments that would have alerted the pilots to the conflicting signals were upsell items.
I’m not an aviation safety expert, so can only go on the information in the public domain and some layman’s engineering thinking. The aircraft had two angle-of-attack sensors because there was the reasonable possibility that one might give inaccurate or misleading indications4. By having two the aircraft had some redundancy designed in to mitigate a known failure mode. As a result of this design decision, you would have thought that any system relying on this angle of attack measurement (whether automated, or pilot initiated) would make use of this redundancy. This wasn’t a fancy, nice-to-have whistle or bell that makes the flight more comfortable, efficient or profitable. It is an underlying safety feature of the aircraft. If there was no safety requirement for the redundancy of two sensors it is difficult to see why there would ever be more than one.
In fairness to Boeing, it is understood that they have now addressed this issue and the anti-stall system now listens to both sensors, responding safely in the event of conflicting signals. It should also be noted that investigations identified pilot error and deficiencies in the training that contributed to the disasters (and this is relevant to my point regarding many SaaS product decisions as well).
The SaaS Parallels
Cloud delivered Software as a Service has revolutionised the tech industry, and catalysed a phenomenal level of innovation and growth. It has enabled new software capabilities to be brought to market faster than ever before, and facilitated the ability to reach a scale with costs defrayed across multiple customers that would have been unimaginable 30 years ago. But the benefit of being able to access a service from anywhere, at any time, by anyone also presents significant risks. The “anyone” can be a malicious party operating outside the reach of law enforcement or extradition. As a result there are clear commercial responsibilities placed on SaaS providers to secure their infrastructure from attack; and those that don’t are unlikely to last long in the market place.
Taking due care and applying due diligence to ensure the platform itself is adequately secured from a direct attack is clearly the vendor’s responsibility.
But what about… security that can reduce their customers’ risk?
But just like in the aviation industry, there are different flavours of security, and different perceptions of what is considered essential. Taking due care and applying due diligence to ensure the platform itself is adequately secured from a direct attack is clearly the vendor’s responsibility. But what about those elements of security that relate to risk owned by their customers?
One key element of customer risk relates to the security of a user’s password. These credentials are a user’s responsibility after all. It is their responsibility to make sure they choose a really long and random string drawn from upper case, lower case, numerical and special characters. It is also their responsibility to ensure they don’t ever use the same password for multiple different applications or services.
But we know that compromised credentials is a common failure mode5. Just because it is the user’s responsibility to mitigate this risk doesn’t mean system developers don’t have some mutual responsibility to make it easy for the user to exercise that responsibility. Controls have been developed specifically for that purpose. The most obvious ones are Multi Factor Authentication (MFA, or 2FA) and Single Sign On (SSO). With MFA, we improve the security of the credentials by also verifying that the user is in possession of their trusted device before we trust them at sign in. With SSO, we minimise the number of credentials and accounts to manage by federating with a single corporate account; we can then concentrate our effort to secure that corporate account rather than spreading our resources thinly6. Both are relatively easily implemented these days, particularly in the case of SSO where the OAuth protocols are widely offered by Identity Providers. Once implemented both are essentially free to operate, particularly if MFA uses an Authenticator app rather than SMS text messages.
It is almost as though they have run out of innovative whistles and bells that their clients would value in their core product
SaaS providers recognise that this security is important, and they will frequently implement MFA and SSO controls into their applications to meet that customer demand. But too frequently we see them only offered as part of the more expensive subscription options. This element of security is not enhancing the vendor’s core proposition; it is not making their offering more functional, better looking, or more efficient for their users. It is just making it more secure. And therefore to treat it as an item to upsell comes across as price gouging rather than the responsible application of good security practice. It is almost as though these vendors have run out of innovative whistles and bells that their clients would value in their core product, so they have had to resort to undermining the security of their cheaper options in order to encourage their customers to pay for their more expensive ones.
You can find a list of those SaaS providers who charge their customers a premium for the privilege of protecting themselves with SSO at https://sso.tax/.
It’s like a bank only using the CSC code on a card to secure transactions for customer’s who pay for their premium banking services, because, after all, it is the customer’s responsibility to protect their card details.
Summary
What I describe is not universal, and probably is not even representative of the majority. But when you are reviewing a new service we would urge you to take a closer look at what security they are charging extra for. If low cost, high value security controls are being upsold then you might want to consider what other security good practice is not being considered as essential.
- New York Times, 21 Mar 2019 – “Doomed Boeing Jets Lacked 2 Safety Features That Company Sold Only as Extras” ↩︎
- References 2 and 3 suggest that one was intended to be standard, but through oversight was only operational when the other optional features had been purchased. ↩︎
- Fear of Landing – “Lion Air flight 610 and the AOA Disagree alert” ↩︎
- Wisner Baum – “Boeing 737 Max 8 Crash Lawsuits” ↩︎
- See the Chapter 2 of our series on Cyber Security for Non-Security Professionals to see why Persona Trust is so important ↩︎
- There is no silver bullet, and poorly governed SSO does come with risks as we outline in our article here: Why you should be very cautious before choosing to “Sign in with” ↩︎
