For all our financial services clients, Software-as-a-Service is a prominent delivery model for third party applications and data. SaaS has been in use since before it was given that name and its adoption is steadily increasing. Solid research suggests that the average enterprise uses >1,000 distinct cloud services and our own work suggests that even for heavily regulated entities, the numbers are still high.
Stay current on your favourite topics
So what? As long as each implementation is known, goes through a governance process and is secure why would this be a problem? SaaS deployments tend to have snowflake integrations with decentralized management which makes on-boarding difficult and increases risk. We would argue that many corporate IT strategies do not give sufficient consideration to SaaS when it comes to risk management and data governance and that firms are semi-consciously ambling towards long term problems. It is time for a ‘managed SaaS’ model to be adopted across the industry to deal with this.
Data strategies are generally pointing towards the ability to exploit advances in data analytics and AI technologies to interrogate data right across an organization to help improve the customer experience, identify business opportunities and manage risk, or even directly monetize the data itself. So access to all of your data (e.g. all transaction related data or customer related data) is fundamental.
SaaS usage represents a balkanization of data. Not only is it not in the corporate network, but it is often held in proprietary databases that cannot be easily interrogated and data extraction can be costly, slow or difficult (due to access rights, size and custom, non-standard extraction interfaces). Some firms are starting to consider backing out of SaaS-based CRM usage (e.g. through SalesForce and Microsoft Dynamics), partly for these reasons.
Secondly, while it’s commonplace to have processes and tooling in place to stop the unauthorized transfer of sensitive data to SaaS services, it’s less common to be monitoring the SaaS data repositories directly to ensure its compliance and integrity e.g. through manual entry of personally identifiable information and who has access to that.
> Risk Management
Regulated entities know well that they cannot outsource their accountability for risk management when they outsource components of their IT estate. Regulators around the globe make this clear through technology risk management guidelines including FFIEC Appendix J (United States), FCA Guidance 16/5 (UK) and MAS Outsourcing Guidelines July 2016 (Singapore). Traditionally, Infrastructure groups have carried much of the burden for the implementation of controls to satisfy these types of regulations but most infrastructure groups have very little involvement with SaaS, certainly where it is for business use. This leaves the question of who is filling the void and which risks are not being managed effectively.
> Exit Management
As Cloud regulation evolves, an emerging theme is the ability for clients to reverse their workloads and data out of specific cloud services. This is referred to as ‘Exit Management’ by the FCA in Guidance 16/5 and specifically calls for financial institutions to test this ability, much as they would be expected to rehearse disaster recovery scenarios. A recent example of this enforcement was related to derivatives clearing in a scenario where it is extremely complex to provide an equivalent service elsewhere.
As these clauses mature and are more widely enforced, the business model for certain types of SaaS usage will come under greater scrutiny.
> Concentration Risk
While regulators are consciously allowing adoption of many cloud services for material workloads, there comes a point where the number of systemically important firms concentrated onto the same industry platforms becomes a problem which can be avoided and which regulators can see coming. While the industry has many choke points of concentration risk which are hard to avoid (consider colo data centres housing matching engines) it is easier to avoid the economic chaos resulting from the shutdown (e.g. through malicious action) of services like Office 365. The burden may need to shift to the SaaS providers to provide fully redundant separation of services between groups of clients to reduce the risk but it will come with a cost premium.
SaaS deployments tend to be snowflake, point-solutions in terms of integration and security. Regulated firms, particularly in financial services, generally have very strong security departments with robust approaches to access control and threat protection but the SaaS vendors themselves vary widely in their capabilities particularly with the complexity of limiting access from approved devices or geographic locations. While vendors like Microsoft, Workday, SalesForce and Box have been prepared to work extensively with regulators and financial institutions, others do not have the capabilities or motivation to reach the necessary levels of security and risk management.
> Cloud hierarchies
The practical complexities of managing risk through multiple layers of cloud providers is non-linear. It is common for smaller SaaS providers to build their services on top of industry PaaS platforms for obvious scalability benefits. And it is also common for PaaS platforms to be provided on top of other IaaS providers. Consider a SaaS service using Heroku PaaS services, which in turn are built on AWS IaaS services, which are in turn hosted in, say, an Equinix Data Centre. Some of the more sophisticated security and risk management professionals we work with see this as too complex a hierarchy to deal with right now. Regulators have always asked for supply chain transparency and are starting to cotton on to these complexities specifically for cloud e.g. FCA Guidance 16/5 specifically calls these hierarchies out.
Stay current on your favourite topics
When does SaaS become PaaS?
If you walk into an enterprise council governing cloud usage for a regulated firm and ask for an application deployment onto public cloud PaaS services, you will face enormous scrutiny and for most firms, the answer will be ‘no’. And yet we already allow SaaS usage with vendors that have incredibly rich PaaS platforms (e.g. Salesforce, Dynamics or Workday). Once SaaS is allowed, it is complex to police the customization that subsequently happens and gauge when that customization turns into code deployment and should effectively be classified as PaaS usage with all the extra controls that requires.
Saas is a great enabler and offers businesses rich functionality at a fraction of the time and cost to build internally as well as providing consistency with counterparties and for talent moving between firms. But decisions governing SaaS usage need to take greater account of evolving regulations and internal data strategies. The current hands-off, decentralized approach to SaaS management needs to be challenged, as inconvenient as that may be.
We recommend looking at introducing central management in three phases:
> Security brokerage
Firms have been deploying CASB solutions for discovery and should consider moving to a more consistent model for standardized security on-boarding and management including:
- Access & entitlements management
- DMZ integration patterns
- Classified trust boundaries
- Encryption management
- Monitoring, analytics and threat prevention
- Auditing, usage reporting and logging management
It should be noted that CASB tools aren’t the only route to security brokerage and they can potentially exacerbate the administration of controls such as entitlements.
Firms should consider a common operational framework for deployment and orchestration including:
- API abstraction for common operational components
- Centralized monitoring and event management including underlying hierarchies (e.g. AWS or Azure core services) and user experience monitoring
- Service discovery, asset management, provisioning and deployment processes and tooling
- SLA management
> Service brokerage
The ultimate stage of maturity would be to offer a fully integrated SaaS framework to enable internal developers including:
- A framework covering inbound and outbound flows
- Data management and portability
- Deployment patterns