simplified readme with high level goals and link to guide

README.md

@@ -4,8 +4,8 @@ Working Group Proposal: Secure Access for Everyone (SAFE)
 ## Objective
 
 Secure Access for Everyone (SAFE) Working Group facilitates collaboration
-to discover and produce resources which enable secure access, policy control 
-and safety for operators, administrators, developers, and end-users across 
+to discover and produce resources which enable secure access, policy control
+and safety for operators, administrators, developers, and end-users across
 the cloud native ecosystem.
 
 ## Background
@@ -51,7 +51,7 @@ for both cloud and traditional infrastructure.
 ## Members
 
 * Dan Shaw ([@dshaw](https://github.com/dshaw)), PayPal [chair]
-* Sarah Allen ([@ultrasaurus](https://github.com/ultrasaurus)), Google [chair]
+* Sarah Allen ([@ultrasaurus](https://github.com/ultrasaurus)), [chair]
 * Jeyappragash JJ ([@pragashj](https://github.com/pragashj)), Tetrate.io [chair]
 * Devarajan P Ramaswamy ([@deva](https://github.com/deva26)), PADME
 * Kamil Pawlowski ([@kbpawlowski](https://github.com/kbpawlowski))
@@ -83,6 +83,10 @@ for both cloud and traditional infrastructure.
 * John Morello ([@morellonet](https://github.com/morellonet)), Twistlock
 * Alban Crequy ([@alban](https://github.com/alban)), Kinvolk
 * Michael Schubert ([@schu](https://github.com/schu)), Kinvolk
+* Andrei Manea ([@andrei_821](https://github.com/andrei821)), CloudHero
+* Justin Cappos ([@JustinCappos](https://github.com/JustinCappos)), New York University
+* Santiago Torres-Arias ([@SantiagoTorres](https://github.com/SantiagoTorres)), New York University
+* Brandon Lum ([@lumjjb](https://github.com/lumjjb)), IBM
 * JOIN OUR MEETINGS REGULARLY, THEN ADD YOURSELF VIA PULL REQUEST
 
 ## Related Groups
@@ -92,30 +96,64 @@ for both cloud and traditional infrastructure.
 * [Kubernetes SIG-Auth](https://github.com/kubernetes/community/tree/master/sig-auth)
 * [NIST Big Data WG](https://bigdatawg.nist.gov/)
 
+## Communications
+
+Anyone is welcome to join our open discussions of WG projects and share news related to the group's mission and charter. Much of the work of the group happens outside of WG meetings and we encourage project teams to share progress updates or post questions in these channels:
+
+* [Email list](https://groups.google.com/forum/#!forum/cloud-native-security)
+* [CNCF Slack](https://slack.cncf.io/) #safe-wg channel
+
 ## Meeting Time
 
 The SAFE group meets every Friday at 11:00am PT (USA Pacific):
 
-Join: https://zoom.us/j/709980684
+Join: https://zoom.us/j/665428022
 
 Or iPhone one-tap:
-* US: +16699006833,,709980684# or +16468769923,,709980684#
+* US: +16699006833,,665428022# or +16468769923,,665428022#
 
 Or Telephone:
-* US: +1 669 900 6833 or +1 646 876 9923, Meeting ID: 709-980-684
+* US: +1 669 900 6833 or +1 646 876 9923, Meeting ID: 665-428-022
 * International numbers available: https://zoom.us/zoomconference?m=r-YGNTQJzZphTlO4LYkdhAt4oIQpwl2g
 
 ## In Person Meetings
 
-Please let us know if you are going and if you are interested in attending (or helping to organize!) an in-person meetup (via the linked github issue):
-* KubeCon + CloudNativeCon, Shanghai, Nov 14-15, 2018 - [issue#28](https://github.com/cn-security/safe/issues/28)
-* KubeCon + CloudNativeCon, North America, Dec 11-13, 2018 - [issue#29](https://github.com/cn-security/safe/issues/29)
+Please let us know if you are going and if you are interested in attending (or helping to organize!) an in-person meetup. Create a [github issue](https://github.com/cn-security/safe/issues/new) for an event and add to list
+below:
+
+* KubeCon + CloudNativeCon, Barcelona, Spain, May 20 – 23, 2019 - [issue#127]
+* KubeCon + CloudNativeCon, San Diego, CA - Nov 18 – 21, 2019 - [issue#128]
 
 Past
+* KubeCon + CloudNativeCon, North America, Dec 11-13, 2018 - [issue#29](https://github.com/cn-security/safe/issues/29)
+* KubeCon + CloudNativeCon, Shanghai, Nov 14-15, 2018 - [issue#28](https://github.com/cn-security/safe/issues/28)
 * [KubeConEU](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/) May 2-4, 2018 in Copenhagen, Denmark ([notes](safe_kubecon.md))
 
 ## Meeting Minutes
 
+* [2018-04-12 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - OPA with SAFE Presentation Framework
+* [2018-04-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-04-05 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Google Open Source Project Onboarding
+* [2018-04-04 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-29 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Revised presentation framework with in-toto (OPA, Kamus, TOC invited) 
+* [2018-03-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - SAFE Whitepaper Working Session
+* [2018-03-15 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-07 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-03-07 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-03-01 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-02-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-21 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-02-15 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-02-01 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-01-31 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
+* [2018-01-25 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
+* [2018-01-24 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
 * [2018-01-18 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
 * [2018-01-17 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session
 * [2018-01-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)

assessments/README.md

@@ -0,0 +1,46 @@
+# Security Assessments
+
+## Goals
+The [security assessment process](guide) is designed to accelerate the adoption
+of cloud native technologies, based on the following goals and assumptions:
+
+### 1) Reduce risk across the ecosystem
+
+The primary goal is to reduce the risk from malicious attacks and accidental breaches of privacy. This process supports that goal in two ways:
+
+   * Clear and consistent process for communication increases detection &
+   reduces time to resolve known or suspected vulnerability issues
+   * A collaborative evaluation process increases domain expertise
+   within each participating project.
+
+### 2) Accelerate adoption of cloud native technologies
+
+Security reviews are a necessary, yet time consuming process, where each
+company, organization and project must perform its own reviews to ensure
+that it meets its unique commitments to its own users and stakeholders.
+In open source, simply finding security-related information can be a very
+time consuming part of the the process. The process is designed to enable improved discovery of security information & streamlined security reviews in multiple ways:
+
+   * Consistent documentation reduces review time
+   * Established baseline of security-relevant information reduces Q&A
+   * Clear rubric for security profile enables organizations to align their
+   risk profile with project’s risk profile and effectively allocate resources
+   (for review and needed project contribution)
+   * Structured metadata allows for navigation, grouping and cross-linking
+
+We expect that this process will raise awareness of how specific open source
+projects affect the security of a cloud native system; however, separate
+activities may be needed to achieve that purpose using materials generated by
+the assessements.
+
+## Outcome
+
+Each project assessment will:
+1. ensure a clear description of the project's design goals with respect to
+security
+2. uncover design flaws and document known limitations
+3. document next steps toward increasing security of the project itself and/or
+increasing the applications of the project toward increasing security of the
+cloud native ecosystem
+
+

assessments/guide/README.md

@@ -0,0 +1,55 @@
+The SAFE WG has been ask to provide the CNCF’s TOC with effective
+information about the security of different projects.  The purpose of this
+document is to outline the procedure by which a project should be evaluated.
+
+The project assessment process is intended to be a collaborative process for
+the benefit of the project and the community, where the primary content is
+generated by the [project lead](project-lead.md) and revised based on feedback
+from [security reviewers](security-reviewer.md) and other members of the
+working group (WG).
+
+Due to the nature and timeframe for the analysis, *this review is not meant
+to subsume the need for a professional security audit of the code*.  Audits
+of implementation vulnerabilities and similar issues at that level are not
+intended to be covered by this assessment.  The purpose of this effort is to
+uncover design flaws and to obtain a clear articulation of what the project's
+design goals and security properties are intended to be.
+
+
+## Steps
+
+1. Create tracking issue
+   * Issue may be a request from TOC liason or project itself
+2. Project provides self-assessment
+   * [project lead](project-lead.md) responds to the issue with draft document (see [outline](outline.md))
+   * issue assigned to lead [security reviewer](security-reviewer.md) who
+   will recruit a second reviewer, if one not already assigned, and facilitate
+   the process
+3. Inital review
+   * Upon request by the project, security reviewer may do an inital review to
+   verify completeness, ask for clarifications and provide quick feedback
+   * Project posts their document to the group mailing list, allowing at least
+   one week for review before presenting to the WG
+4. Presentation
+   * Project lead presents to WG
+   * This will be recorded as part of standard WG process
+5. Final assessment
+   * Reviewers provide final feedback with recommendations
+   * Either project lead or reviewers may request further WG discussion
+   * Project lead prepares a PR to /assessments/project-docs/project-name/
+
+## Additional Process Notes
+
+Iteration is expected; however, we expect quick turnaround (at most a week).
+In rare cases unrelated issues can unexpectedly interrupt the process and
+it may be appropriate to address specific concerns rather than continuing with
+the assessment. We encourage open communication between project lead and s
+ecurity reviewers:
+
+* At any time, the project lead may request additional time to respond
+  to feedback from security reviewers
+* Project lead or lead security reviewer may pause the process where a delay
+  of over a week cannot be accomodated by the review team. Simply close
+  the github issue with a note to SIG co-chairs.
+
+

assessments/guide/outline.md

@@ -0,0 +1,55 @@
+# Outline
+
+First of all, the burden is primarily on the proposing project to
+demonstrate it is secure in a manner that is understandable to the broader
+community.  The [reviewers](security-reviewer.md) will help to assess and probe the design.
+
+The proposing project must provide a written document that describes the
+project and its security.  The document must contain the following
+information, at a minimum.
+
+* Goal. The intended goal of the projects including the security guarantees
+the project is meant to provide (e.g., Flibble only allows parties with an
+authorization key to change data it stores)
+* Non-goals.  Non-goals that a reasonable reader of the project’s literature
+could believe may be in scope (e.g., Flibble does not intend to stop a
+party with a key from storing an arbitrarily large amount of data, possibly
+incurring financial cost or overwhelming the servers)
+* Scenarios.  The scenarios in which the project is expected to be used.
+This must be specific enough to provide context for analysis.  (e.g.,
+Flibble can be used in any cloud environment.  Three diverse examples are
+as follows.  First, when a Flibble server is used by legacy servers as a
+database for salted password hashes.  Second, a Flibble cloudlet may be run
+on virtualized fog hardware near smartphone users.  Third, a Flibble
+distributed service may serve as a backend for a Notary image registry.)
+* Expected attacker capabilities.  A description of likely capabilities that
+the attacker has in these scenarios should be described.  Both assumptions
+about the strength and limitations of attackers should be described.
+(e.g., We assume that an attacker may be able to exploit implementation
+errors in some set of the servers to take control of them.  However, we
+assume the attacker cannot break AES or SHA256.)
+* Design.  A description of the system design that discusses how it works.
+This is especially critical for any mechanisms that relate to the security
+of the system.
+* Operation.  A description of the operational aspects of the system, such as
+how keys are likely to be managed and stored.
+* Attacker motivations.  A discussion about the likely goals of an attacker.
+This likely relates closely to the impact of different attacks in the
+scenarios.  (e.g., In the password hash case, the attacker wants to expose
+those hashes on the Flibble server.  However, a Flibble cloudlet attacker
+may find it more interesting to bring down the service.)
+* Security degradation.  A discussion about the resulting security when
+various attacks are launched.  Note, that no system is secure in all
+scenarios, hence it is expected that this will include areas where attacks
+compromise all meaningful security.  (e.g., If an attacker is able to
+compromise the “master” Flibble server, they may read, write, or delete any
+content stored on any system)
+* Attack risk.  A rough estimation of the risk posed by different attacks.
+(e.g., The master Flibble server only communicates with Flibble servers
+using a minimalistic API that is formally verified and written in Rust.)
+* Software.  A link to the software’s repository.
+* Development pipeline.  A description of the testing and review processes
+that the software undergoes as it is developed and built.
+* CII Best Practices.  A brief discussion of where the project is at with
+respect to CII best practices and what it would need to achieve the badge.
+

assessments/guide/project-lead.md

@@ -0,0 +1,13 @@
+# Project Lead
+
+In the context of the security assessment, the "project lead" should be
+someone on the security team for the project. For new or smaller projects
+without an established security team, this could be a project maintainer
+or they may delegate to a regular contributor who has an interest in security.
+
+## Expected time / effort
+
+The level of effort for the team providing the information is expected to
+be around 80 hours of work.  Note, that projects that have already
+performed a security analysis internally are expected to have much lower
+requirements.

assessments/guide/security-reviewer.md

@@ -0,0 +1,31 @@
+# Security Reviewers
+
+Reviewers will try to understand the
+system and probe its security.  Specifically design level issues are meant
+to be addressed as well as high level problems with the project’s setup and
+operation. This is meant to provide an independent analysis and estimation
+of the above information.  The goal is to ask questions to understand if
+there are hidden assumptions, underestimated risk, or design issues that
+harm the security of the project.  It may be useful to reach out to
+community members to understand the answers to some questions, especially
+involving deployment scenarios and the impact of attacks.
+
+## Qualifications
+
+Unless approved by the SIG chairs, at least one of the reviewers will
+have previously performed a SAFE WG audit.  (Exemptions are expected to be
+granted bootstrap the process but only in extreme cases later on.)  In
+general, a reviewer should have performed security audits for diverse
+organizations.  The ideal reviewer should also have been the recipient
+of security audits for a software project they manage.  Note that it is
+encouraged to have participation (shadowing) from participants that are not
+yet qualified to help them gain the necessary skills to be a reviewer
+in the future.
+
+## Time and effort
+
+The level of effort for the reviewers is expected to be 10 hours.
+Despite the fact that there may be some back and forth to get clarification
+on a few points, it is expected analysis can usually be concluded in a few
+weeks.  This will primarily involve carefully reading the written
+document and analyzing the security assertions and assumptions.

landscape/categories.md

@@ -15,7 +15,7 @@ sub-categories. The remaining text is a description of each sub-category.
     - Tools that facilitate automated security testing in pipelines;
     eg for functional security tests of authn and authz,
       tests of known potential weaknesses or misconfigurations
-  - _Piplines_
+  - _Pipelines_
     - Tools that ensure a secure pipeline or workflow, for example,
     as applied to devops (CI/CD), supply chain, etc.