Business Strategy Services

What Problem do Too Many SaaS Providers Have in Common? Many SaaS security providers have a history of treating important safety and security features as something to upsell. This raises the important question of whether a software vendor has a moral responsibility for the secure operation of their solution. In this article, we explore the implications of treating important security and safety features as an upsell, using Boeing as a test case of where this can go wrong. The Case of Boeing and the Aviation Industry The case against Boeing is emblematic of a more systemic issue across the aviation industry, and many other industries. The public became aware of this issue 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 article , the crash could have been avoided if the pilots had access to two safety features that were sold by Boeing as optional extras. According to the incident reports, at the root of the incident were the angle-of-attack sensors. These mechanical sensors operate in a similar fashion to a weathervane 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 after having been installed incorrectly — as was believed to be the case for the Lion Air aircraft . The system that led to the aircraft’s demise, which identifies the risk of the aircraft stalling, only listened to one of the sensors. A difference in the signal being sent by the two sensors was not recognised by the anti-stall system; and the instruments that would have alerted the pilots to the conflicting signals were upsell items. This wasn’t a fancy, nice-to-have bell or whistle 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. Boeing has now addressed the issue, and the anti-stall system listens to both sensors, responding safely in the event of conflicting signals. It should also be noted that the investigation identified pilot error and deficiencies in the training that contributed to the disasters (and this will be relevant to our points regarding many SaaS product decisions as well). The SaaS Parallels Cloud-delivered Software as a Service (SaaS) 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. However, the benefits 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 of 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 do not are unlikely to last long in the marketplace. But just like 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 that 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. It is their responsibility to make sure they choose a long and random string drawn from upper case, lower case, numerical, and special characters (if allowed). It is also their responsibility to ensure that they do not ever use the same password for multiple applications or services. But, we know that compromised credentials is a common failure mode. Just because it is the user’s responsibility to mitigate this risk, this doesn’t mean that system developers do not also have some mutual responsibility to make it easier 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 thinly. 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. 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 bells and whistles 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. It is equivalent to a bank only using the CSC code on a card to secure transactions for customers who pay for their premium banking services, because, after all, it is the customer’s responsibility to protect their card details. Conclusion What we have described here is not universal, and probably is not even representative of the majority of SaaS providers. But, when you are reviewing a new service, we urge you to take a closer look at what security your provider is charging extra for. If low cost, high value security controls are being upsold, then you may want to consider what other security good practices are not being considered essential. For more information about our cyber security consulting services and Secure by Design principles in action, please contact Tom Burton, Partner for Cyber Security, using the form below.

Peter Drucker wrote in his book The Practice of Management (1954) that ‘it is the customer who determines what a business is’. This sentiment still firmly holds true today, as consumers increasingly expect personalised shopping experiences from aspirational businesses that desire to have a positive impact on the community, country, or world in some way. Across this series of articles, Daniel Fitzsimmons explores the role of customer-centricity as a mechanism to support the delivery of superior customer experience and business profitability. Following from the first article in this series, in which Daniel covered the basics of customer centricity and initial ways to implement it into your organisation, this article applies these premises to the development of actionable customer satisfaction. Purposeful Value Creation Purposeful value creation involves the increased alignment of an organisation to a broader societal cause to secure a positive association with potential customers. As ethical consumption becomes increasingly important to consumers, brands must be increasingly sensitive to not only profit generation, but also the nature of the profit being generated. A customer-centric business purpose statement helps to project a company’s motives to prospective customers, and provides an impetus or bias with which to engage with your products or services. However, failure to fulfil a stated purpose can negatively impact brand equity, share prices, and future revenue generation, highlighting the need to embed purpose messaging within the fabric of the organisation. Purposeful value creation represents a key informant to customer journey mapping, consumer touchpoint messaging, and the identification of what matters to potential clients. Through increased alignment to customer values, you are better positioned to define the customer journey through your organisation, and secure future access to the customer’s wallet. Customer Journey Mapping Sales funnel formulation and market targeting typically focuses resources and efforts on ‘top of funnel’ customer acquisition and the development of velocity around transaction creation. When considering customer-centricity, greater focus needs to be given to Post Purchase Management, and securing customer loyalty through an improved customer experience. Post Purchase Management supports the creation of brand equity, reputation, and future opportunities. Effective customer journey mapping requires the identification of market segments, target consumers, and product positioning. Once you have identified targets, it becomes easier to map the offline-online interactions of target customers and how best to engage with each distinct customer persona, amplifying or quietening their voices as they contribute to business success. Customer Satisfaction Customer satisfaction and the creation of customer enjoyment should be at the forefront of your organisation’s culture. However, it necessitates a mechanism to collect and codify customer feedback related to the delivery of goods and services. Various mechanisms exist to support customer satisfaction identification, including: Kano’s model for customer delight Net Promoter Score Measures, ie. the likelihood to which you would recommend a service Customer Effort Score, identifying the friction associated with engaging with a product or service ACSI Measures, which address a) Overall satisfaction, b) Expectancy disconfirmation, and c) Performance versus the ideal product or service. While it is impossible to pick just one ideal method, and organisations will need to select a solution which best supports their insight creation process, we can confidently recommend the use of CSAT surveys as critical to customer-centricity and the provision of critical insights into products and services on offer. Conclusion When cultivating a customer-centric organisation, all ventures and operations should be directed towards the goal of customer satisfaction; inversely, you can be assured that your business is successfully customer-centric when you observe increased customer satisfaction. In this article, I have covered how best to integrate this goal into your business plan, ensuring it follows the same steps as your customer’s journey. In the next and final article in this series, I take these basics and outline ways in which technology can be leveraged to amplify these goals.

Would you feel comfortable flying in an aeroplane designed by engineers who only considered what might go wrong after they had built it? ‘Secure by Design’ (SbD) is not a technology, it is a set of principles to be adopted to improve business risk and resilience. It has strong similarity to conventional engineering practices, and it will save money by reducing wasteful rework. The critical first step is to understand the risks that the solution will be exposed to. Like Failure Mode Analysis in conventional engineering, these inherent risks form an essential part of the solution requirements. The design can then be a collaborative and iterative exercise of review and enhancement to meet the security requirements. Effort spent defining requirements before design and implementation is widely recognised to save time and money. The situation is no different with security requirements, but there are wider benefits as well, compared to addressing security late in the lifecycle: Security controls applied after design and implementation are more likely to restrict functionality, undermining overall user satisfaction and the return on investment Early engagement reduces the risk of budgets overruns, or having to accept inadequate security if you can’t secure the budget A well-documented set of risks, security controls and design decisions can then follow the solution through implementation and into operations, enabling future change to understand past rationale Above all else, late identification of risk and security requirements causes wasteful rework of the solution, which will cost time and money The key to success is defining the system scope correctly. If the scope is too great and encompasses a number of separate systems, then the benefits are eroded and the exercise becomes more akin to a homogenous enterprise risk assessment. If the scope is too small, the number of systems becomes unwieldy and unsustainable to assess and manage. It is not a Technology, and it is not New Despite what you might believe from some of the cyber tech product sheets, SbD is not a technology (for that matter, Zero Trust, which we see as a valuable component of SbD practice, is not a technology either). It is a philosophy or strategy, a set of principles that bring efficiency, consistency, and discipline to cyber risk management. You may find tools that help you to adopt these principles, and the practice requires a sound understanding of technology, but above all SbD is a human endeavour. Like many other buzzwords in the security community, SbD is frequently presented as something rather mystical, requiring specialist knowledge and attracting a new set of standards and vocabulary. We don’t hold with this concept; in our view, it ‘does exactly what it says on the tin’. It is about ensuring the system’s very design enforces security and mitigates risk rather than relying on sticking plasters applied after implementation. Whether those design features are preventative controls, controls to detect and respond to issues, or any other category, they will have been defined and tuned to the specific risks and characteristics of the solution in advance (and managed through life). The concept is not new. The benefits of early security engagement have been known for some time. But sadly, this has been frequently ignored. As the cyber security industry matures, and the frequency and impact of cyber attacks on businesses increases, the call for this discipline has been increasing. Governments are starting to mandate it in the standards and security governance of technology programmes. The Similarities between Digital and Conventional Engineering Most engineering lifecycles, not just those related to digital solutions, recognise the importance of spending adequate time defining the requirements. At the start of the programme, the level of uncertainty will be at its greatest. The purpose of Requirements Engineering is to reduce that uncertainty so that design and implementation can proceed with direction and to minimise the number of ‘wrong turns’ that have to be unwound. If you do not reduce uncertainty as early as possible, the problems grow as they move downstream, and solving them then becomes a disheartening exercise in ‘pushing water uphill’. Let us imagine that we want someone to build us a house. We would go to our local house building company and commission the job; if they get started immediately, the chances of the end result being anything like what we originally wanted would be almost zero. Where do we want our home located? How many bedrooms, bathrooms, and living rooms? What architectural style? What about the fixtures and fittings? We will identify everything wrong once the sub-optimal, ill-thought-out building is completed for our inspection. Putting those right at this stage will cost orders of magnitude more than they would have with an effective design phase. Worse, there will be many issues that we cannot put right without starting again, and, therefore, we will be left operating in a flawed and compromised solution. Where do we Start? So, how do we identify the security requirements for the design? What is Requirements Engineering in a security context? The security requirements are defined by the risks that the solution will be exposed to. One of the most important SbD principles emphases this by stating that you must ‘adopt a risk-driven approach’. These risks and your organisation’s appetite to accept risk determine the requirements for controls; or, to put it another way, the controls are required to mitigate the risk to a level that it is within your organisation’s appetite. Again, there are similarities with conventional engineering. Understanding the risks that the design must treat is similar to identifying the Failure Modes of an aircraft or other system. The risks need to be articulated so that all stakeholders can understand them, including by the non-technical and non-security communities. Getting all stakeholders to sign off on these inherent risks is crucial to ensure that everyone recognises the constraints the solution will be confined by. If you do not have a sound understanding of the risks before work starts on the design, let alone the implementation, then you are lacking an essential part of the solution requirements. Review, Collaborate, and Iterate Once you have the security requirements, you can feed them into the design process similar to functional requirements. Selecting appropriate controls to meet the requirements will undoubtedly require some specialist expertise. However, this is similar to the requirement for technical architects to be familiar with the technologies employed in the solution stack. This design process should be iterative. Requirements change, frequently due to learning in one iteration providing feedback into the next. The security requirements may influence the architectural approach to fulfil the functional requirements. Occasionally, a complete rethink may be required to adjust the functional requirements to meet the security constraints while also meeting the business needs. However, like the house-building analogy above, this time spent optimising the design will be significantly less than the time, cost, and disruption caused if security is addressed later in the lifecycle. Each iteration takes the proposed design, reviews the inherent risks to identify any that can be retired or if new ones have been created, assesses the residual risk given the existing security controls, and identifies additional security controls to reduce the residual risk to an acceptable level. Done collaboratively, this can introduce fast feedback into the design process, and, over time, the technical architects will become more familiar with security issues and their resolutions. Zero Trust’s Role in the Exercise, and Scope Definition Zero Trust is another trending buzzword frequently camouflaged with mystique, or hijacked as a ‘feature’ on product sheets. My view on Zero Trust is similar to my view on SbD: it should be easy to understand, and ‘does exactly what it says on the tin’. In design and in operations, we start from the baseline that nothing is trusted. Whether it is digital identities, devices, applications, or services, we can only trust them once we have an objective and explicit reason to trust them. We use the principle of Zero Trust extensively when applying SbD. By having no implicit trust in any identity, device, or service, we can decide on the minimum level of trust we need to enforce and the maximum level of trust that the entity can offer. If the maximum trust on offer is less than the minimum trust we need, then there is a design decision to be made about how we close the gap. It may be necessary to reduce functionality in order to reduce the required minimum. Or, we may need to put in place other compensatory controls to reduce the risk in other ways. Defining an appropriate scope of the system is key to success. If you set the scope too large, then everything is inside the ‘circle of trust’, and SbD becomes a homogenous exercise in enterprise security. If you set the scope too small then you will drown under the sheer quantity of projects to manage. The World is not a Greenfield Site, and Security is not a Fire-and-Forget Weapon The world is not a greenfield site, and there will be challenges retrofitting a SbD approach to the broad portfolio of legacy solutions. There is no simple or quick solution to this, it will be a case of progressively revisiting each project’s architecture and identifying the changes that will make it secure by design. But, risk can help us here too. Some projects or services will be sufficiently low-risk so that they can be tolerated until they are retired (so long as they are not trusted by any other more important system). The SbD approach lends itself well to a progressive rollout. SbD will limit the negative impact that a legacy system can have on a target system, because nothing outside of a project’s scope is implicitly trusted. You can only aim for a perfect world by progressively taking steps to make it a better world. In this article, we explain why risk management needs to be addressed at the design phase of projects. This does not mean that we believe this is the end of the journey. Security and risk management still needs to be managed in operations as new threats change the risk profile, or change is applied to a system. But with the foundations laid early in the lifecycle, the task of management through life becomes easier. The documentation generated by SbD should provide clear traceability between risks and controls. When a project is reviewed in life, the rationale behind previous decisions can be clearly understood, enabling change to be an informed process. Summary This article outlines why I believe applying the principles of Secure by Design avoids issues getting into operations, and saves time and money. If what I have described already seems obvious, then that is positive. However, from my experience, too many projects do not consider security to be an essential component of design. I believe that this is a missed opportunity, and, when applied correctly, it delivers solutions that are more secure and easier to manage.