cloudsecurityalliance / csa-guidance Goto Github PK

This may come down to writing style, voice and tone of the document. Since this is a work in progress I understand the need to get the thoughts on the page, but it seems like there is a lot of Parenthesis is this document so far. You can, in just about all cases, still get the same info and point across but solely in a "regular" (ha!) sentence. Parenthesis are something that are best used sparingly.

For example:
The customer manages the database either via the API or web console~~(and web console)~~, and then accesses it either through normal database network protocols or again, via the API.

In PaaS the cloud consumer only sees the platform, not the underlying infrastructure. In our example, the database expands or contracts (or contracts) as needed based on utilization,.....

Just an observation especially since most see parenthesis as less important content or having less emphasis, and there is a good number in the document so far. If what is being said in these parenthesis are important then treat it as such, if not so important, then candidate for pruning.

line 7: "It is a technology, a collection of technologies, an operational model, a business model, and more."
I would propose to add "a development model" before "operational model" to make a reference to the devops associated trend.

line 187: about the metastructure. I would propose to make a note on network HSM.

line 213: I would propose to add something about the "nested cloud". Like, "the roles are even more hard to define when some nested technology is considered (eg. https://www.ravellosystems.com/)".

line 221: I would propose to go beyond "document". For instance mentioning that the cloud provider should also provide some API auditing capabilities to enable the cloud consumer to perform security analysis, resource change tracking, and compliance auditing. May be another place is more relevant than line 221?

Regards

Logical model is introduced here newly, not in the guidance 3.0.
I understand the concept of the Logical Models, but I do not know which domain refers to this model. Guidance 3.0 uses the NIST model and almost all domains refer to the model.
Could you tell me why the Logical Model is needed in the Guidance?

The arrow head of the responsibility diagram should be both sided. The waight of responsibility may become heavier on provider side or consumer side depending on choice of service model.

and if so, what about

• timelines?
• migration for current holders, trainers?
• revised learning objectives?

Domain 12, IAM: There is a lot of focus on Cloud-based storage of User accounts vs federation of user accounts – but not machine authentication/authorization/entitlements. Add this content and give special focus to managing machine authorization and entitlements. Consider Microservices authentication/authorization strategies in a cloud environment (OAuth, Federation, PKI).

The idea of Infrastructure - Metastructure - Applistructure - Infostructure stacking is new and good. The diagram here give some sense. The order of scripts re the four structure is wrong. The order of Applistructure and Infostructure should be reversed.

The term 'Cloud Consumer' is ambiguous. It seems that it is the same as "Cloud Customer". If you use "Cloud Consumer", the definition of "Cloud Consumer" should be described.

1.3.2 Operating in the Cloud
"Traditional Security" and "Data Center Operations" have disappered from domain titles. These domains used to refer to the physical and operational security of data center facilities and operations. The domain with title "Infrastructure Security" looks to cover these topics, but the description does not refer anything about such topics.
APAC set up an initiative of Cloud Data Center Security Working Group in view of importance of data center physical and operational security. These topics should be covered somewhere in relevant domain.

Ties in with my earlier comment on Domain 1. I think we need to start some considerations in the serverless space. This domain may be a good place to start!

Couple of comments on this Domain.

i. It would be good to consider the connectivity between enterprises and clouds here, e.g. ExpressRoute and DirectConnect. Don't need product names but consideration of direct connectivity vs Internet VPN would be worthwhile as well as the security implications for both cloud and on-prem environments.
ii. Malware scanning would also be worth further consideration - how do you keep the environment clean?
iii. Patch Management would be a good inclusion here - cloud lets you do stuff differently :)
iv. Operations. How does cloud impact upon your management toolsets?

Main feedback - would this be a good domain to consider some of the more DevOps type issues around deployment?

It is difficult to understand the 'Trusted' and 'untrusted'. I think 'known' and 'unknown' may be better.

Introduction - there is a paragraph starting with "Specific areas covered include". Should cross-border data transfers be addressed as well? There is a mention about issues relating to moving data into cloud computing, but nothing relating to cross-border data transfers. For example, the transfer of personal data from the EU to a country outside the EU, such as the United States (Privacy Shield). I am happy to prepare and add such a section if there is an interest.

Overview - the section General Legal Issues - in the paragraph beginning with "The EU's requirements", there is a sentence in brackets: "(There is also a new accompanying Directive that must be given effect within each member state by May 6, 2018.)" Why is this in brackets - should this be a footnote instead? The sentence is also not clear since there is no indication on what the accompanying directive does or says. I propose to replace that sentence with the following:
A Directive was also issued in relation to the processing of personal information relating to individuals by authorities for the prevention, investigation, detection or prosecution of crimes, and this Directive must be implemented by each EU member state by May 6, 2018.

Next paragraph, the sentence "From the perspective of non-EU corporations, one major difference between the Directives and the Regulation is in how the new Regulation is enforced." The Regulation is not yet enforced, it will only come into effect on May 25, 2018. The sentence should therefore be in the future, as follows: "... how the new Regulation will be enforced".

Next paragraph starting with "From the perspective of non-EU corporations", the sentence "European data privacy was enforced outside the EU under the terms of individual national laws, as well as treaties with the EU. This includes agreements like EU - US Safe Harbor or its replacement, the EU - US Privacy Shield" is inaccurate. Under the current Directive, organizations are in scope if they are located within the EU or make use of (automated) equipment located within the EU. However, if there is a transfer of data from the EU to a country outside the EU, there needs to be an "adequacy decision" by the EU commission stating that such country offers an adequate level of protection of personal data due to its domestic law or the international commitments it has entered into. This is why the Safe Harbor or Privacy Shield was put in place.

The same paragraph states "under the new DPR, EU law is directly binding on any corporation that processes the data of EU citizens, regardless of whether they have any European presence. It remains to be seen what the efficacy of this enforcement regime will be." The new DPR actually goes further than that, since it applies to all organizations offering goods or services to EU citizens, but also to organizations that monitor (online) behavior of EU citizens, in so far as the behavior takes place in the EU.

Paragraph starting with "Beyond these well-known examples, the United States has a huge number of smaller laws", at the ending of the paragraph, since the topic is on the FTC's power to regulate "unfair trade practices", I propose to add at the end a sentence such as the following:
"Since 2002 and the Eli Lilly settlement, the FTC has brought more than 50 data security enforcement actions pursuant to section 5 of the FTC Act."

Just below, I propose to add a brand new paragraph which would be this:
"There is an increasing focus by government agencies on data protection and security issues. For example, in March 2016, the Consumer Financial Protection Bureau (“CFPB”) released a consent order entered between it and Dwolla, a company providing an online money transfer and payment processing platform to consumers. According to the CFPB's consent order, the company made false representations concerning its data security practices and engaged in deceptive acts and practices in connection with the offering of consumer financial products or services. The company was ordered to pay a $100,000 penalty and fix its security practices."

In the paragraph starting with "Alternately, the company may have entered into contracts (such as service agreements)", just under the chart, there is a sentence "| | Prohibition against cross border transfers | ". Shouldn't this be a new paragraph? Also, it should be "cross-border" and not "cross border".

I propose to add a new paragraph at the ending of the section on "Prohibition against cross-border transfers", like this:
"The development of cloud-based services raises a number of issues due to the nature of cloud technology, where data flows from one country to the other due primarily to load balancing and auto provisioning considerations. In the Microsoft Corporation v. United States of America ruling (2d Cir. 2016), the US Department of Justice sought to obtain from Microsoft all emails and private information associated with a certain account hosted by Microsoft on its web-based Outlook platform. The account's emails were stored on a server located in Ireland, one of many data centers held by Microsoft around the world. The court found that US law (in particular, the US Stored Communications Act) "does not authorize courts to issue and enforce against US-based service providers warrants for the seizure of customer e-mail content that is stored exclusively on foreign servers."

I think "account and session recoding" should be "account and session recording"

Minor nitpick, and I do not know if the current images are meant to be final or placeholders, but the current quality of images (ex: Images/1.1.2-1.png ) is currently quite low and shows a lot of artefacts, as if they were JPEGs before being converted to PNG...

"In addition, account and session recoding should be implemented to drive up accountability and visibility for privileged users." ***Recording

In 1.1.2.1, 4th bullet, it has "This allows the to more closely...".
It should be "This allows them to more closely...".

In 1.1.3.1, 3rd paragraph, it has 'depoyment".
it should be 'deployment'.

in 1.1.3.1, 4th paragraph, it has 'abstration'.
It should be 'abstraction'.

In 1.2.1, it has "What does the consumer need need to do?".
It should be "What doe the consumer need to do?".

In 1.2.2, it has "FDIS 27017".
It should be '27071' because 27017 has already be published.

The course mentions you need to have, for the CCSK Plus class, already subscribed to Amazon EC2 and followed the pre-class setup instructions.

It would be super helpful also to have those instructions/steps here.

Dubai is one of the 7 emirates that make up the country of the UAE and is not a country in its own right

The Three Lines of Defence (Defense :)) model is a popular Governance model and it seems well-suited to the cloud approach in terms of it's descriptions of those who operate controls, an oversight function and independent audit. The Governance section at the moment seems quite heavily focussed on contractual issues rather than Governance per se and it would benefit from further consideration of governance models.

Domain 11, Data Security and Encryption – add material on HSM usage (ex: AWS CloudHSM, etc.). Consider discussing (1) Use of HSMs in separate data centers, (2) Use of HSMs in multi-cloud scenarios, and (3) Use of HSMs in a cloud-based Microservices environment.

Line 92 explanation of SPI should be Services, Platform and Infrastructure instead of Application infrastructure and Platform.

Line 187 Meta structure and management planes is good, but there is an element of abstraction woven in there which provides isolation along with Virtualization. Also there is the benefit of abstraction from hardware failure at the application layer which provides infinite availability from an end user perspective along with elasticity. That is another key difference between Virtual hosting and Cloud environments- the abstraction layer.

On the whole the concept of tenant isolation for IaaS, PaaS and SaaS should be mentioned somewhere in this chapter as that is critical from a security standpoint and how that is achieved by different layers and different patterns for the same.

In reality most SaaS solutions are not REAL Cloud Services, they are virtually hosted applications provided as services, that includes even services like Office 365..which is a hosted service and not a Cloud service with actual elasticity...at the app /services layer.

Another concept which didn't come thru is Cloud Broker services, and they may or may not be Cloudy e.g. IAM brokers, Vulnerability management broker services etc.

There was some mention of Provider Chaining but the concept didn't come thru as that brings up concerns for Security and Integrations end to end for an Enterprise.

For Shared security and Operations model may be there can be a Matrix which shows the divide of responsibilities or at least some examples of the same for IaaS, PaaS and SaaS ( SaaS is the easiest obviously)

For hybrid Cloud enterprises there are some key challenges which should be highlighted (Maybe) or referenced somehow to another paper. There can be multiple permutations of hybrid Cloud Enterprises as well.

Another concept that can be referenced in this paper is: Inter Cloud and what that means for a Hybrid Cloud Enterprise Architecture.

Containerization even though may be addressed somewhere else, but a mention of the technology in the architectural concept may be nice to have in this section (but either way will work) as long as it is referenced here and details can be provided else where in the overall Guidance.

Thanks
Aradhna

Domain 11 talks about Data security from a risk and control perspective. May be good to point out how that is linked to Domain 5 Data governance, where the lifecycle model gives us some clues as to what controls can be relevant in which phase.

There seems to be a use case for overlay networks that span multiple regions, or even IaaS providers. Technology includes ZeroTier and I know VMware has stuff like this somewhere in their SDDC offering.

Hi,

I think this intro chapter should not only mention IaaS, Paas and SaaS, but also SECaaS - especially snce it has its own chapter latzer on.

What do you think?

It appears that there are no domains 4 (this was previously "Compliance and Audit Management" in version 3) and 8 (previously, "Data Center Operations").

Have not seen a clear place where this point has landed. Part legal and part management plane.

The original v3 point was that bandwidth limitations create a bottleneck when moving large amounts of data (data lakes and so on). In reality I have experienced bigger issues with rate limiting of API's that you might use for this transfer. AAMOF an API that is not rate limited is a risk in itself.

Case in point, a 10Gig transfer taking a week.

The URL for NIST 800-145 has changed to http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

Realise this is in outline phase so just some suggested areas for consideration

i. use of cloud-based code repositories. I've had a number of clients who go to great lengths to secure their cloud infrastructures and then host all of their Infrastructure as Code on cloud-based code repositories secured via username and password!

ii. patching/fixing of consumer code. Seen a number of clients going down the PaaS route assume that they've handed off patch management completely... consumers need to patch their own code.

iii. security of deployment pipelines is key - authentication and authorisation of those that can deploy, how the pipelines retrieve crypto credentials etc when spinning up instances etc. can be messy.

Could we also talk about service/application identities as well as human actors? How do your different services authenticate to each other in a microservices environment? How are service identities created and managed? Similarly for their entitlements...

Linking to the files replacing spaces with %20 so the URLs end up looking like this: https://github.com/cloudsecurityalliance/CSA-Guidance/blob/master/Domain%204-%20Compliance%20and%20Audit%20Management.md.

The arrow in the picture is one direction, but it does not show any meaning.
The arrow should be two direction for both the most customer and the most provider.

Three suggestions:

1. The architecture section would benefit from some consideration of Serverless aka Function as a Service. Whilst you could view it as an evolution of PaaS, I'd suggest that there are enough architectural differences for it to merit separate consideration. If nothing else, a mention of Serverless as a direction of travel would be worthwhile here.

2. Is it worthwhile considering the impact on wider organisational capabilities of your cloud architecture? The chosen architecture can have some interesting implications for wider business functions including operations (big differences between IaaS vs SaaS for example) and development teams as well as non-technical domains such as Procurement and Compliance. I've seen a few organisations struggle with procurement when trying to adopt cloud. Procurement teams need to understand the security requirements they should be using to compare and contrast cloud providers for best fit. It's a change in mindset from telling providers what they need to do. In some organisations I've worked with I've seen Procurement and Compliance driving their organisations towards private cloud. [Not that I'd recommend private cloud in general...]. This content would fit in your steps towards the end of the section - 1.2.2.1.

3. Relating to the above, it may be worth expanding on how a wider cloud strategy drives your cloud security architecture - e.g. public vs private vs hybrid, single provider vs multi-cloud, cloud-agnostic vs cloud-specific (i.e. lock-in vs making the most of a single provider's capabilities) etc. At the moment architecture sounds quite self-contained but in reality you'd want a generic way to tie the architecture to the wider strategy (or at least business context :))

I realise this domain is in outline form at the moment :)

A move towards cloud services can offer an opportunity to re-visit data ownership and governance. It's a good chance to adopt a defined information architecture and away from the fractured, heavily duplicated and poor quality data repositories you find in many enterprises. Perhaps worth exploring this as a side benefit of wider transformation relating to cloud adoption in this Domain?

Domain 10, Application Security: Include a recommendation for considering the use of IAST in a testing environment during a CICD Pipeline. Focus more on Continuous Security via DevOps, intelligent pipeline design, and using automated provisioning for creating temporary testing environments.

notes on CSA guidance v4 update D1

line 76 I like the buildup in de explanation of the 5 characteristics. It is a good sequence from an instructional perspective.

line 136
https://raw.githubusercontent.com/cloudsecurityalliance/CSA-Guidance/master/Images/1.1.3.1-1.png

In training I find this picture a bit confusing. The main points presumably are that compute and storage are separate pools (for most IaaS providers), that each have a management and orchestration layer as well as having a combined (consumer facing) management layer on top of that.
From a semantical perspective, the picture combines layering of functionality with networking thrown in. I propose to delete the networking aspect.
You would then need to adapt the 2 subsequent paragraphs to talk about the orchestration layer instead of the controller.

line 156. see comment at line 136

line 179. "metastructure" , "infostructure", and "applistructure" are neologisms that have confusing and contradictory meanings. Best to avoid.

line 211 good picture.

line 234. Good addition to version 3.

line 294
This part of the domain structure reflects a much needed update to some of the old-school thinking.

What happened to "interoperability and portability"? It does not look like it is included anymore.

The guidance and technical background write-ups are solid across the domains, but my general compliant is that most of the recommendations at the end of each domain for Cloud Customers use language such as “Understand,” “Examine,” “Evaluate,” etc. This doesn’t translate very well into requirements for an organization.

I’ve listed a quick breakdown of my recommendations about this for some of the domains:

• Domain 7, Infrastructure Security does a better job of identifying requirements, etc. but doesn’t go into depth. For instance, there isn’t much on Software Defined networking and strategies for securing it. Azure, for example, allows communication between machines located on separate subnets, so subnetting must be used in conjunction with other controls. I don’t believe this is the case with AWS. To address this, instead of saying “understand what the provider gives you,” list out strategies and implementation requirements for different scenarios.
• Domain 8 – Virtualization and Containers gives a nice list at the end for “Cloud providers should” and “Cloud consumers should” – but doesn’t go very in-depth.
• Domain 9 - Intrusion Detection and Response – at least break this up into “Cloud Providers should” vs. “Cloud consumers should.” In my opinion, it should be more in depth than this.
  • Same goes for Domain 3, Legal issues, contracts, and electronic discovery. Focus more on what customers can do to enable forensics, other than “understanding” things, etc. Think: potential requirements for aggregating logs, time stamps, preserving integrity of machine images, data in storage, etc.

The guidance is heavily focussed towards public cloud and the need to rely upon independent certifications and attestations - and quite rightly so.

However, I think the guidance would benefit from noting that the situation can be different when it comes to private cloud - as such a cloud is single tenant by nature then there is more scope to negotiate more traditional rights to audit. Worth mentioning as this (right to audit) is one of the factors that has driven some organisations towards private cloud.

On the Management Plane front, it would be worthwhile considering how the management plane must enforce separation in a multi-tenant environment and reference to how this separation can be assured.

On the business continuity front, I think a reference to Chaos Engineering (e.g. the Netflix Simian Army) would be worthwhile as it shows how the cloud model can help organisations to build more resilient solutions overall.

On the SaaS side of things, it's worthwhile noting that whilst you may be able to keep copies of your data for recovery purposes you are still stuffed from a continuity perspective without an application able to process that data! Just having the data is insufficient to be comfortable you have continuity. Kind of similar for PaaS depending upon how portable your code is.