Putting the security in SaaS
Michael (a freelance cybersecurity consultant) wrote about an article about ‘Security concerns with platforms and services in the cloud’ which I summarily agree with but have thoughts on.
This isn’t a rebuttal of his post but perhaps of an expansion but also my views (which aren’t a million miles away). Hat-tip for him reviewing this article before publication.
Michael runs a weekly cyber roundup newsletter (great for those — like me — who lack to always stay up to date with recent events within a reasonable period of time) — https://tinyletter.com/CyberWeekly/.
So, what are the XaaSes?
Lets go alphabetically, we’ll get onto order of preference in a wee while.
For simplicity, I will focus on the XaaSes that get a lot of attention in the cybersecurity space as opposed to Data-as-a-Service (DaaS) such as GOV.UK Registers or a UK postcode / address lookup service or Desktop-as-a-Service (DaaS) such as AWS WorkSpaces or Microsoft Azure Remote Desktop Services.
In-line I will also discuss where the shared responsibility (the delineation between your responsibilities for security, configuration et al versus the supplier’s). The responsibility lines move quite a lot so to save character count the common denominators are:
- obey the T&Cs
- obey any copyright, license agreements etc
- keep credentials that have been issued to you safe
- obey non-disclosure agreements, if they apply
- pay for what you use
- respond to instructions issued via a security bulletin etc from the vendor
- not doing anything to damage the vendor or the platform
- your data, your problem — supplier will only be a Data Processor for your tenancy data (likely Data Controller for your account data, such as username’s and billing)
FaaS is serverless computing. FaaS allows you to develop code and have someone else runs it when you want them to — entirely mitigating the need to run a container, operating system etc.
Lambda from Amazon Web Services (AWS) is a nice example.
Shared responsibility line: you have to write the code, debug it etc and ensure it is appropriate to be run by the provider and think about requirements like temporary or persistent data stores given your application stops running and underlying resources are recycled once your application ends. The provider usually takes care of routing and secrets management for you (or provides mechanisms for you to easily consume that within your FaaS code).
SaaS is effectively renting of virtual compute resources (CPU, RAM, storage) without having to house (power, cool, network) them yourself, worry about cooling or pay the upfront capital expenditure to get the kit in the first place.
AWS EC2, Azure Virtual Machines, Alibaba Elastic Compute Service (and so on) are all prime examples.
Shared responsibility line: you have to pick the operating system, your resources (and ensure they are sufficient for your needs) and manage the entire operating system and any consequences — patching, upgrades, configurations, services you run, applications you run etc.
‘Immutable infrastructure’ is on the rise (replace not patch-in-place) but either way you have to solve that problem.
Various IaaS providers provide tooling to help with some of the commodity things such as via AWS’ EC2 Systems Manager and maintained base images.
‘PaaS’ can mean slightly difference things but in essence it is above the IaaS layer (so you generally don’t need to worry about patching etc just your application code/artefacts) but not SaaS as you’re running your own applications.
CloudFoundry is a good PaaS example as you provide it with application code and configuration, it will create the relevant application and IaaS stack and simply run your application for you — potentially managing databases, backups, HTTPS and load balancing for you.
Kubernetes is another PaaS, as it can help you with secrets management (etc) in addition to the traditional containerised compute problem.
Shared responsibility line: you have to provide suitable application code and minimal viable configuration that the corresponding PaaS platform needs to understand your application and provide the surrounding services, as applicable.
Unless you’re running the PaaS yourself: you’re only responsible for the security of the application not the security of the platform/infrastructure — the responsiblity for the Confidentiality, Integrity and Availability triad is heavily skewed towards the PaaS provider.
The SaaS model is consuming an application itself from the vendor (typically via a web browser or thin application) and you’re responsible for very little unless the SaaS is complex and lets you change a bunch of things about how you use it.
Shared responsibility line: just the common denominators — subject to the complexity of the SaaS as then you’re responsible for configuring to your requirements — that could range from interconnectivity through to security.
An aside: XaaS terminology doesn’t really work but they are what we have
IaaS, PaaS and SaaS (et al) by themselves are things most people in this space understand but can often become buckets of “I suppose its this” or “it isn’t those so its probably this”.
“If it isn’t IaaS or PaaS its probably SaaS” — maybe?
SaaS and FaaS aren’t actually comparable because they are entirely different paradigms (a venn diagram would show little overlap) — the vendor does pretty much all it versus you developing your own code.
As per Michael’s article: SaaS can be large productivity suites such as Microsoft’s Office 365 or Google’s G-Suite versus smaller SaaS like MailChimp, Trello.com, Slack or TrackSeries.TV and in my opinion that is too wide of a definition to be useful but heyho.
Order of priority — time to prefer
This order of preference is based on only two things: simplicity and security.
Simplicity: in general control is great but you have to do stuff which may be cost/time/effort — we’re discussing commodity SaaS here so you should be leveraging that and not customising when you don’t need to.
Security: increased options and complexity offers room for benefit or error — you can tighten or loosen security controls based on your risk appetite but you have to pay attention and not inadvertently decrease security by misunderstanding how the options work or forgetting to set an option.
1st preference (joint): FaaS
1st preference (joint): SaaS
2nd preference: PaaS
3rd preference: IaaS
As described above, FaaS and SaaS are so very different but aren’t distant cousins when only discussing simplicity and security.
(I will likely reflect later — probably after taking some flack — that putting SaaS and FaaS next to each other was not a great idea.)
Not a line by line of Michael’s post but picking out some things that made me think.
It depends which ‘security concerns’
“Security concerns don’t change very much based on whether you are using a platform, or infrastructure or just services. They change based on the maturity of the solution and the maturity of the organisation you are using.”
As highlighted above, I think the change in shared responsibility means you probably have more to do which likely means you have more security-related things to do — but security functionality or capability (and the utilisation of the same) is not the same as vendor-based supply chain risks.
I would argue the supply chain risks broadly speaking remain the same between IaaS, PaaS and SaaS/FaaS as the biggest burden is always personal/sensitive data security and in all XaaS scenarios discussed here the vendor can see your data if they really wanted to — you have to trust the vendor to some degree and this is where security shouldn’t say “no” it should say “we should take some proportional, understood and manageable risks in order to achieve overall benefit via functionality and time/cost savings”.
Security-related topics can come with a heavy dose of “It Depends” given context but you need to consider whether your ‘security requirements’ are over-egged and if you’re being special for the sake of it.
“To use an example, Amazon is a multi billion dollar company, and has a set of robust and audited security processes in place. Honest Bob’s Cloud is not, and probably does not.”
Mythbustin’ — law enforcement data capture etc
I agree with Michael’s views here (also weighed in my 2c during his drafting) — overall, the probability of such occurrences are also very low.
While perceived law enforcement over-extension is often an important issue it is key to weigh proportional risk and probability when making XaaS decisions as encryption data is good (do it) but attempting to encrypt data to keep it away from law enforcement acting under a warrant is cause for serious reflection.
The difference in diligence
Michael’s article links out to guidance from the UK National Cyber Security Centre (NCSC) on assessing vendor SaaS security.
I was asked to review the guidance many moons ago while it was early draft and my thoughts haven’t changed much since:
- the guidance is great 😙
- NCSC is great — 👋
- the guidance scope doesn’t consider data protection, records/information management etc at all or in sufficient depth — but thats OK, that isn’t what guidance scope is
- the guidance is a ‘sniff test’ and not a risk assessment or anything beyond ‘the surface’ — but thats also OK because of guidance scope
- ‘Security’ people are not always ‘Data Protection’ people, nor ‘risk’ people (proportionally engage risk on behalf of the organisation)
- the usual organisational member is usually unable to decipher the legalese presentation of SaaS T&Cs etc by themselves
- in many organisations, usual members are not allowed to sign-up the organisation to legal agreements (they in theory aren’t allowed to accept the T&Cs as the organisation)
I agree that questions about data-centre locations etc do not always need to be asked but this is where context comes in — if you’re worried about personal data or intellectual property because those are things are important in the thing you’re trying to do then you should ask many more questions than the SaaS security guidance suggests and are likely to be asking questions which may be considered ‘old’ — where are your data-centres, where are your staff, what levels of access do your staff have to my data etc.
One day soon I will write about “What I mean when I say cybersecurity” and cover some of the inter-related and equally valuable personas that organisations need for security in cyber space.
… but for now: thats all folks.