This post was originally published by the Cloud Security Alliance.
SaaS (Software as a Service) is the most common cloud service model.
According to the Shared Responsibility Model, "The consumer does not manage or control the underlying cloud infrastructure".
As customers, this leaves us with very little control over services managed by remote service providers, as compared to the amount of control we have over IaaS (Infrastructure as a Service), where we control the operating system and anything inside it (applications, configuration, etc.)
The fact that many modern applications are offered as a SaaS, has many benefits such as:
- (Almost) zero maintenance (we are still in charge of authorization)
- (Almost) zero requirements to deal with availability or performance issues (depending on business requirements and the maturity of the SaaS vendor)
- (Almost) zero requirement to deal with security and compliance (at the end of the day, we are still responsible for complying with laws and regulations and we still have obligations to our customers and employees, depending on the data classification we are about to store in the cloud)
- The minimum requirement to handle licensing (depending on the SaaS pricing offers)
- As customers, we can consume a service and focus on our business (instead of infrastructure and application maintenance)
While there are many benefits of switching from maintaining servers to consuming (SaaS) applications, there are many security challenges we need to be aware of and risks to control.
In this blog post, I will review some of the security challenges facing SaaS applications.
Identity and Access Management
We may not control the underlining infrastructure, but as customers, we are still in charge of configuring proper authentication and authorization for our customers (internal or external).
As customers, we would like to take advantage of our current identities and leverage a federation mechanism to allow our end-users to log in once and through SSO to be able to access the SaaS application, all using standard protocols such as SAML, OAuth, or OpenID Connect.
Once the authentication phase is done, we need to take care of access permissions, following the role description/requirement.
We must always follow the principle of least privilege.
We should never accept a SaaS application that does not support granular role-based access control.
While working with SaaS applications, we need to make sure we can audit who had access to our data and what actions have been done.
The final phase is to make sure access is granted by business needs – once an employee no longer needs access to a SaaS application, we must revoke the access immediately.
Data Protection
Once we are using SaaS applications, we need to understand we no longer have "physical" control over our data – whether it is employee's data, customers' data, intellectual property, or any other type of data.
Once data is stored and processed by an external party, there is always a chance for a data breach, that may lead to data leakage, data tampering, encryption by ransomware, and more.
If we are planning to store sensitive data (PII's, financial, healthcare, etc.) in the cloud, we must understand how data is being protected.
We must make sure data is encrypted both in transit and at rest (including backups, logs, etc.) and at any given time, access to data by anyone (from our employees, SaaS vendor employees, or even third-party companies), must be authenticated, authorized, and audited.
Misconfiguration
The most common vulnerability is misconfiguration.
The easiest way is for an employee with administrative privileges to make a configuration mistake and grant someone unnecessary access permissions, make data publicly available, forget to turn encryption at rest on (depending on specific SaaS applications), and more.
Some SaaS applications allow you to set configuration control using CASB (Cloud Access Security Brokers) or SSPM (SaaS Security Posture Management).
The problem is the lack of standardization in the SaaS industry.
There is no standard for allowing central configuration management using APIs.
If you are using common SaaS applications such as Office 365, Dropbox, SalesForce, or any other common SaaS application, you may be able to find many third-party security solutions that will allow you to mitigate misconfiguration.
Otherwise, if you are working with a small start-up vendor or with an immature SaaS vendor, your only options are a good legal contract (defining the obligations of the SaaS vendor), demand for certifications (such as SOC2 Type II reports) and accepting the risk (depending on the business risk tolerance).
Insecure API's
Many SaaS applications allow you to connect using APIs (from audit logs to configuration management).
Regardless of the data classification, you must always make sure your SaaS vendor's APIs support the following:
- All APIs require authentication and perform a back-end authorization process
- All traffic to the API is encrypted in transit
- All-access to API is audited (for further analysis)
- If the SaaS application allows traffic initiation through API back to your organization, make sure you enforce input validation to avoid inserting malicious code into your internal systems
I recommend you never rely on third-party SaaS vendors – always coordinate penetration testing on exposed APIs to mitigate the risk of insecure APIs.
Third-Party Access
Some SaaS vendors allow (or rely on) third-party vendor access.
When conducting due diligence with SaaS vendors, make sure to check if it allows any third-party vendor access to customers' data and how is data protected.
Also, make sure the contract specifies if data is transferred to third-party vendors, who are they and for which purpose.
Make sure everything is written in the contract with the SaaS vendor and that the SaaS vendor must notify you of any change regarding data access or transfer to third-party vendors.
Patch Management and System Vulnerabilities
Since we are only consumers of a managed service, we have no control or visibility to infrastructure or application layers.
Everything is made of software and software is vulnerable by design.
We may be able to coordinate vulnerability scanning or even short-term penetration testing with the SaaS vendor (depending on the SaaS vendor maturity), but we are still dependent on the transparency of the SaaS vendor and this is a risk we need to accept (depending on the business risk tolerance).
Lack of SaaS Vendor Transparency
This is very important.
Mature SaaS vendors will make sure we are up to date with information such as breach notifications, outages, and scheduled maintenance (at least when everybody on the Internet talks about critical software vulnerabilities requiring immediate patching, and assuming downtime is required).
As part of vendor transparency, I would expect the legal contract to force the SaaS vendor to keep us up to date with data breach incidents or potential unauthorized access to customers' data.
Since in most cases, we do not have a real way to audit SaaS vendors' security controls, I recommend working only with mature vendors who can provide proof of their maturity level (such as SOC 2 Type II reports every year) and coordinate your assessments on the SaaS vendor.
Mature SaaS vendors will allow us access to audit logs, to query who has access to our data and what actions have been done with the data.
Regulatory Compliance
Regardless of the cloud service model, we are always responsible for our data and we must always comply with laws and regulations, wherever our customers reside or wherever our SaaS vendor stores our data.
Mature SaaS vendors allow us to comply with data residency and make sure data does not leave a specific country or region.
Compliance goes for the entire lifecycle of our data – from upload/store, process, data backup or retention, to finally data destruction.
Make sure the legal contract specifies data residency and the vendor's obligations regarding compliance.
From a customer's point of view, make sure you get legal advice on how to comply with all relevant laws and regulations.
Summary
In this blog post, I have reviewed some of the most common security challenges working with SaaS applications.
SaaS applications have many benefits (from a customer point of view), but they also contain security risks that we need to be aware of and manage regularly.
About the Author
Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.
Eyal is an AWS Community Builder since 2020.
You can connect with him on Twitter.
Opinions are his own and not the views of his employer.
Top comments (0)