Public Cloud's Single Biggest Failure

[AppDefects]

IMHO Cloud Service Providers (CSPs) keep their public platforms reasonably secure. That much I'm sure we can all agree on, otherwise we would not be doing business with them. What continues to cause concern  though is that organizations still suffer from Cloud data breaches that could easily be prevented by CSPs if they had implemented a continuous monitoring program for a customer.

Sure there is that subterranean partner network where you can add on a la carte security services, but over the last 10 years there has been a systemic erosion of CSP responsibility. With the rise and bland acceptance of CSP Shared Responsibility Models we have all learned that our assets in the Cloud are always at risk.

CSPs are very clear - it is a customer problem - hire cloud security professionals to fix your problems. They are not our problems. Have fun because if you get breached you can't sue us (Na Na Na Na Boo Boo). We have been drinking the Kool-Aid long enough, maybe too long to turn back. In 2021, when you are negotiating your services contract with your favorite CSP. Call their bluff on security claims. Do not accept the Shared Responsibility Model go to another CSP that will secure your data, audit your infrastructure, and build in continuous monitoring.

[Beads]

This has been my primary complaint since AWS launched way back when. Back then I would simply ask the salesperson trying to convince me to move my systems to the cloud: 'Who stands up in court with me when, not if, you fail?' Crickets.

Nough said.

- b/eads

[JKWiniger]

I mean unless you are a major client that would bring in significant money to AWS, Azure or whoever how likely are they to budge on anything? I like other can and have seen the problems but not know an answer.

John-

[Caute_cautim]

@AppDefects, @Beads How many people would actually understand their Shared Responsibilities, or even read them and just simply accept them as is?

Any one have a comprehensive list of threats and risks within AWS environments?

Some of them include:   If the VPC is compromised, it is then possible for someone to point the VPC at someone's else's S3 bucket etc.

Regards

Caute_Cautim

[Beads]

Most won't until called into court and wondering why they are there - alone.

- b/eads

[Caute_cautim]

@Beads   I agree, lets hope we can convince a few more people to be sensible in 2021.   AWS for instance do have a Shared Responsibility Model, perhaps people will read it and understand it and realise the implications.

We wish.....

Regards

Caute_cautim

[Caute_cautim]

@AppDefects @Beads @JKWiniger Here is another interesting situation I experienced recently with AWS, during an engagement.  The Banks Audit team, one would expect to set out exactly the interval period for audits to be conducted, and exactly what controls need to be confirmed and audited within the Shared Responsibility Model in this case AWS.

So AWS Config provides a cloud native set of tools, that you can configure i.e. NIST SP800-53 R4, along with CoBit, ISO 27001:2013 and 27002 and Center for Internet Security (CIS) baselines.

From an auditors perspective would you a) trust the shared responsibility model b) use the cloud native tools for audit purposes i.e. developed by AWS for instance.  c)  If you did use the Cloud providers native tools, would they be objective, independent and provide evidential information sufficient for auditors to state this environment has been configured to relevant and approved controls? 

Or would you opt for independent security compliance tools and assessments?

Yours people?

Regards

Caute_Cautim

[JKWiniger]

@Caute_cautim It's an interesting question. Cloud providers are required to perform their own audits in order to be certified so it would stand to reason that they would be on top of this. If they where to loose certification it would have a larger impact on them opposed to just one customer. With this in mind I think I would trust their tools unless / until there is some reason or evidence not to. While it is true that the cloud is all about a zero trust model we do need to put some trust in our providers, just like we do in our admins. Sure there have been cases where this has not worked out but I see that more as the exception than the rule.

I am interested to see what others think about this and if reason will be given that will change my mind.

John-

[Caute_cautim]

@JKWinigerIt has becoming increasingly obvious, that when an organisation like AWS, Google or many others, conduct self audits such as through Cloud Security Alliance (CSA) this is not sufficient.  Yes, I hear you that they have been audited independently via SOC2 for instance and they have paid their dues to get this conducted and remediated etc.

But when for instance, a company has stated to a third party provider, that they will manage their entire AWS or other cloud providers environment, on their behalf - then the Shared Responsibility Model takes a different perspective.  The Third party is responsible for ensuring that the approved controls regardless of the facilities and statements that the Provider states, have to be verified, independently, objectively, to show no bias, and that there is sufficient evidence, that the third party has configured the environment and associated accordingly via an independent Cloud Security Posture Management (CSPM) and associated reporting capability.

I am stating do not depend on the cloud providers own tools to do this - I am seeing an increase in auditors wanting verification, which is idependent of the cloud providers statements, or statements of verification along with sufficient evidence to indicate they are operating they environment in accordance with the agreed contract.

One must do ones due diligence and not depend entirely on the cloud providers statements alone. 

I am also stating, do not depend on the cloud providers Shared Responsibility Model alone, independently verify it, map out the controls for instance against NIST SP800-53 and make your own realisation of exactly the cloud provider is offering or not actually doing and what they will do, or not if the proverbial hits the fan.

This exercise is "eye opening" alone.  

Regards

Caute_Cautim

[JKWiniger]

@Caute_cautim From my understanding, there are many aspect of a cloud provider that we would not be allowed to access or audit and are supposed to be ok with the fact that they are SOC2 certified. Yes, we can audit what we have access to using whatever means we wish, but what about what we do not have access to? Is there a way to do this that I have not heard of?

Thanks,

John-