[CNSWP v2] Different Framing to the Cloud Native Security Whitepaper

[apmarshall]

Description: What's your idea?

I would describe myself as a relative novice to the actual implementation of cloud-native security, but I have a strong background in writing, editing, and communications. I read the whitepaper with great interest, and I am wondering if there is a better way to frame it so as to draw out more clearly what distinguishes Cloud Native security from "traditional" security. I've written a short article/sample executive summary illustrating what I have in mind. It's just meant to be a conversation opener: as I said, I am a relative novice at the implementation of this, so while I pulled out the things that seem most "distinguishing" about Cloud Native Security to me, I'm sure there are better minds who will have more informed views on this than I do. In even more brief form, here's the outline of what I put together:

• Cloud Native essentially refers to applications which are (a) designed to run in highly dynamic/elastic environments and are (b) composed of "loosely coupled" services (ie, microservices) which can scale up and down with that environment.
• Cloud Native security therefore has to apply the traditional principles of cybersecurity to this sort of "ephemeral environment." The two most distinguishing principles of this are: (1) the perimeter is the application itself, not the network perimeter, and (2) security concerns have to be applied at every level of the stack.
• To implement security following these principles, Cloud Native security must: (1) "shift left", (2) implement "agile" monitoring tools, and (3) operate in a "zero trust" model.

The first two points are sort of the preamble and the third point there provides the outline for the reframing.

Impact: Describe your hopes for how this would reduce risk for the cloud native ecosystem. Who will this help? How will it help them?

I think there are two main advantages to this reframing:

(1) It more clearly illuminates what is "unique" about Cloud Native Security vs. "traditional" security. One of the weaknesses of the current structure, from my perspective as a reader, is that there are several sections which outline security recommendations that sound to me like exactly what one would do in a traditional security environment (least privilege for user/service accounts, separation of concerns, etc). In some cases it's clear that this is "different" because, for example, the separate concerns are running as separate containers. But in other cases it's unclear that there is a difference between what is being recommended in the whitepaper and what would be the standard practice in a non-cloud environment. This reframing is designed to really put the emphasis on what is different/distinguishing about a cloud native approach.

(2) It reduces some redundancy from the current whitepaper. I appreciate the logic of the lifecycle approach to structuring the paper, and think there should be some sort of lifecycle outline in the whitepaper. But in several instances there are very repetitive sections from one stage of the lifecycle to another. If the lifecyle outline is either framed within the concept of "shifting left" or treated more as an "appendix", this repetition may be reduced.

Scope: How much effort will this take? ok to provide a range of options if or "not yet determined"

Not yet determined. I'm happy to take a stab at a rewrite if people would like a first draft, but I don't want to dive into that if there's no appetite for it.

Additional Info:

See attached files for illustration of my proposal in a shortened/executive summary-type form.
Cloud Native Security Executive Summary.pdf
Cloud Native Security Executive Summary.txt

EDIT:

Related to #747

[PushkarJ]

@apmarshall thank you for the detailed suggestion :) We plan to incorporate and discuss all kinds of feedback from members like you in future versions of whitepaper. It is currently being tracked as a larger retrospective effort here: #480 . Personally, I will take an in depth look at your proposal soon and look forward to discussing this with you as well as the whitepaper authors.

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[PushkarJ]

@apmarshall sorry for the delay. Just reviewed your proposal attached. It seems like we may be able to refactor some content of the paper to explain how cloud native security can be looked at for organizations moving from traditional -> cloud native security model.

If memory serves right, @achetal01 and @TheFoxAtWork did the most work on the executive summary and this clarity although can be sprinkled all across the paper, I think clarifying that in exec. summary will help quite a bit.

As a logical next step before closing the issue is to make sure when we start re-drafting the paper, we can get you involved and use your awesome skills to ensure this perspective is covered in adequate measure without increasing the overall length of the paper. Thoughts?

[apmarshall]

I'm happy to pitch in whatever way I can based on the consensus of the group when we look at what the survey data tell us.

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[TheFoxAtWork]

@apmarshall @PushkarJ is this issue still outstanding given the survey results?

[apmarshall]

Not as far as I’m concerned.

…

On Aug 25, 2021, 11:55 -0400, Emily Fox ***@***.***>, wrote: @apmarshall @PushkarJ is this issue still outstanding given the survey results? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[TheFoxAtWork]

@PushkarJ @apmarshall I recommend this issue be linked with the Cloud Native Security Whitepaper v2 issue. #747 and folded into the scoping/planning of that effort to better align. Pushkar would you agree?

[PushkarJ]

Yes +1 Just linked it

[TheFoxAtWork]

@apmarshall should this issue be closed as it will become in scope for Whitepaper v2? if so, @Pushakr can we update the other issue with these?

[apmarshall]

Sounds good to me.

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[PushkarJ]

@apmarshall do you have bandwidth to pick this up as part of whitepaper v2 effort? Parent issue is : #747

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[PushkarJ]

I have tried my best to take the essence of this suggestion into v2 of the paper. You can view it here: https://docs.google.com/document/d/1fftLBt3XjDzyYQisEKH3TZXL1QnT_cHIbBnFtW98UOs/edit

Any and all feedback is welcome. Since the review process can be tracked via #747, closing this issue.