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?

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)

Function-as-a-Service (FaaS)

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).

Infrastructure-as-a-Service (IaaS)

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.

Platform-as-a-Service (PaaS)

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.

Software-as-a-Service (SaaS)

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

“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

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.)


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.”

I concur.

Mythbustin’ — law enforcement data capture etc

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

I was asked to review the guidance many moons ago while it was early draft and my thoughts haven’t changed much since:

  1. the guidance is great 😙
  2. NCSC is great — 👋
  3. 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
  4. the guidance is a ‘sniff test’ and not a risk assessment or anything beyond ‘the surface’ — but thats also OK because of guidance scope
  5. ‘Security’ people are not always ‘Data Protection’ people, nor ‘risk’ people (proportionally engage risk on behalf of the organisation)
  6. the usual organisational member is usually unable to decipher the legalese presentation of SaaS T&Cs etc by themselves
  7. 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.

You might find other exciting posts in my Medium profile. I’m on Twitter as @JoelGSamuel.

The thin blue line between technology and everything else. joelgsamuel.com